The Slate Programming Language
slatelanguage.org
slatelanguage.org
Main regrets: - Starting with multiple delegation from Self; we migrated to Traits a la Squeak and Perl6 but it was pretty late in the project. - Hewing too closely to Smalltalk syntax, instead of ditching the lexical awkwardness for keyword syntax and more conventional but unambiguous lexical patterns. - Image-based bootstrapping was useful, but too monolithic. I wanted to make it have a symbolic graph linker to stitch together images from modules. That would have kept the project flexible enough to keep going.
As it is, I'm disillusioned with the open source and software research fields, and working on startups to accumulate my own funds to run a project like this without being subject to the rhetorical whims of a diseased culture. Hah!
You may as well AMA.
Actually, what hope is there in capturing the imagination of the mainstream? Seems like they're so used to having languages forced down their throat by corporate entities that our brightest hope lies in children.
Not the author (obviously) but I think it already has -- Clojure has gone mainstream.
Homoiconicity is overrated; Atomo and Atomy represented better where I wanted to go, which is to adapt notation to the problem, even have it be flexibly remapped and recombined per modular scope.
And then I threw it away as a learning exercise. It was a few years of skills building before I really tried to make a language project. Slate had a few incarnations which were quite different from what it currently presents as.
I feel that. I have no problem with images in theory, but history has made me flinch at them.
> As it is, I'm disillusioned with the open source and software research fields
That's a shame. Open source is very diverse... I hope you have better experiences in the future.
> You may as well AMA.
Awesome. What do you think of Io? — http://iolanguage.org/
I'm asking because I rarely ever hear PL people talk about Io.
I'm also curious, was there a coherent design goal or philosophy behind Slate? Alan Kay is very clear about his values, I have a handle on what Io is about, and so on. All I'm getting from Slate is "better than Smalltalk" but is there something more specific to it?
Slate had some design goals, but a lot of the goal was general, like "how much can we fit into Smalltalk and still have that core idea be recognizable and coherent?" Multimethods, prototypes, macros, optionals, etc. were all just a part of that.
We did spend a lot of the project's focus on how heavily we could leverage multimethods to clarify and collapse code. Slate probably uses multimethods better than any language I know of, although I admire what Julia does with it within the Matlab/R compatibility constraints.
Mainly, we wanted to take operating systems and meld them with computer languages. The TUNES project says a lot of what I think about that (with a good deal of ideological distortion and handwaving, but that's group editing for you).
Honestly, I checked Alan Kay's philosophical reading list, and its depth in phenomenology and developmental psychology was stuff I covered in college. While he belongs to another generation, I'm keenly following the ideas of the FoNC project and hope to deliver something that takes that to an everyday context broadly.
The problem I have in practice is images are so often lacking, or they start you off with an alien universe full of preconceptions rather than just a collection of tools. This isn't an inherent problem, but it seems to show up half the time or more.
I want to like images, but I think what I really want is a system that has a fully functional base state with a good image that can be (and usually is) loaded at startup. I guess that might get in your way if you're worried about optimal performance.
Smalltalk lexical style makes certain kinds of notational customizations difficult to compose. I want multiple kinds of brackets that could get used for DSLs. Slate did manage to make prefixes and suffixes customizable and make much more into operators than Smalltalk allowed, at least.
But we did have extreme whitespace sensitivity between tokens so "3+4" was a single token. That was our fault, even if it enabled many interesting notations.
There's an idea from Fortress (I think?) of squeezing out spaces to express tighter grouping -- that at least struck me as promising.
I've only read a few pages of the Slate site so far but it's brought back fond memories of image based systems I played with in the 80s.
(I've done a total of about 5 years worth of professional programming over the last 30 years, primarily assembler and BCPL in the 80s and some Pascal and Perl in the 90s; I've played with many langs -- lisp, snobol, the toy smalltalkish systems Smalltalk/V and Actor, etc. -- in the late 80s; I'm currently a Perl 6 "enthusiast" -- my periodic HN search for "perl6" caught your mention of it.)
If you have little to no idea what NQP [1] is, then my question is:
What are the characteristics that a language/compiler/runtime/library have to have to adequately support an image based approach? I'm imagining OO; source code as objects; running code as objects; object serialization; incremental compilation; etc. I know I should research this myself (and will, now you've rekindled my interest) but I think your off-the-cuff answer will be an interesting and valuable start for me and perhaps others.
Or, in the unlikely event that you DO know what NQP is, then my question is:
Is it reasonable to think about building an image based system using the NQP toolchain?
Thank you offering AMA. :)
Really, an image is just a heap snapshot with roundtrip serialization possibilities. You want to be able to serialize all the operational data structures, so the model of data has to sort of respect a certain abstraction layer. One consideration is whether the image has to be portable; word-size of 32 or 64 bits, or under endianness. This has strong implications about what kind of code you can keep in the image.
You also would want hooks for startup and shutdown if you expect to be able to snapshot a heap and then restart it under a debugger, say, and get the runtime circumstances that are relevant, like open sockets and files, dynamic-linked libraries, and so on.
I am now really curious about building an image-based edition of Rakudo Perl 6. I'm going to ask about this on #perl6 and reply here if anything comes of it.
Thanks again. May the eggnog season serve you well.
I've been playing with Smalltalk recently, and it's really interesting as an environment. It has a number of RAD tools built in - the flexible Morphic GUI from which you can quickly create your interface and middle-click to debug any given morph, the image system allowing you to store state without explicitly dealing with a database, and being able to develop from the same environment that your code runs in, allowing quick turn-around in adding and testing features - and I'm wondering why it's not used more often for line-of-business applications.
Good to see this still ticking. Though these days I'm more interested in static typed languages, this is still very cool.
And Atomy: http://vito.github.io/atomy/
Both of these, I feel, are interesting small offshoots that explore more in a pattern-matching metaprogrammable grammar direction, although they never became large visions or systems.
There are others in the 'self' tag of the blog. A modern look at this type of environment, which Slate seems to be progress towards, would be interesting.
Morphic alone was not good enough to build the future out of. First-class information objects called presentations from the CLIM history would have complemented it nicely.
I think i hear this idea from the smalltalk community (or former community members) than anywhere else. The sense that there is supposed to be something out there thats an order of magnitude better than what we have today. Where does that come from? Whats so great about "the future" ie what promise does it hold?
XCode's Interface Builder is an Objective-C knockoff of a Lisp tool from the 80's which needed a lot of work even back then and never received it.
We're talking about two decades of extremely limited conceptual progress on interaction. The only GUIs that are run over network streams are HTML/JS/CSS, and those took about fifteen years to turn into fully standalone clients, and not terribly reliable or secure ones at that.
We still don't have a continuation concept (workflows that can be set aside like data items and continued at any point in time) in any shipping UI, despite that being demonstrated 10 years ago at MIT.
We still very typically treat dates and times as text strings instead of first-class manipulable objects whose identity is separate from presentation.
I could go on, but I'm just trying to convey the sense that our (known) future is stuck in the past.
Agreed, but the solution sounds like the whole naked object fad from a decade ago.
Are they fads, though, inherently, or because of a lack of cultural and financial support? I like to learn from all of them but have no idea how to make a new effort that is worth more than just a splash of publicity.
My current bet is on just getting smart software in the hands of a wide audience that don't listen to programming culture.
What else can one do? Who are we rewarding by the way things work now?
If I continue, it will be with a specific story in mind about who it's for and what message to convey. I have been attending The Strange Loop for a few years now and growing some ideas to write about.
It's worth noting that Slate was one major project in a long stream of development I started privately in the early 1990's and then brainstormed with some nerds on at the TUNES project until I made Slate its own thing (a kind of stepping stone towards the TUNES goals).
However, pull of a successfully language is very hard. That depress me.
--- See more at
https://www.reddit.com/r/coding/comments/2ocw2r/how_to_creat...
Being a language designer is rough like this.
The question is how to do it and with whom and for what audience.
We wanted to make the idea of a programming world as an OS manifest, so Slate images and object networks are like a file system image. The most straightforward way for us to get into that was dynamic with optional typing.
The idea at some point was to have staged meta-programming (like we did to build the VM out of Slate) that was typed, so that the static existed within the dynamic but in a more obvious way than "sure, my Haskell universe exists on a nasty filesystem".
We tried.
Obviously not ideal, but we leaned in the direction we hoped others would see. I don't think enough people saw what we were doing beyond the front page news blurbs. Slate has a lot of good code in it.