Someone here mentioned a thing called “Glamorous Toolkit”. I downloaded it and started playing with it, and quickly became baffled as to just what it was, what it was for, and what all the odd layers of… things… in it were for. It was obviously written in Pharo, which is some kind of modern Smalltalk, but… why all the other stuff? What is a Mondrian and why would I want one? Why are all the examples (in a Smalltalk project) about parsing Java source code? If it’s a Toolkit - and one assumes it’s not the same kind of toolkit as Gtk, ie, it’s not a set of GUI components - what makes it Glamorous? It appears to be partially a rewrite of the entire Pharo GUI, so it is some kind of GUI toolkit or has one, and it presumably has aspirations of being a Smalltalk or a replacement for one, but it’s also… so much other things. Java-flavoured things.
I eventually figured out (and not from reading the Glamorous Toolkit documentation) that GT is itself just one tiny sentence in a decades-long conversation called “Moose”. For those of us who haven’t been anywhere near the room full of people talking about “Moose”, GT probably isn’t the place to start. It’s certainly not the place for me to start.
I found out that Moose, whatever it is, is associated with one thing called “Feenk” (which is probably a startup?) and another thing called “The Moose Book”. Which appears to be documentation - the entire missing manual that wasn’t included with Glamorous Toolkit.
So I’m reading The Moose Book to try to get a sense of what, and more importantly why, Moose is, and why it’s so huge and sprawling and full of strangely named things about Java.
In the “Moose in a nutshell” chapter very near the start, I found what appears to be a mission statement.
http://themoosebook.org/book/index.html#h2mooseoverview
Moose is a generic platform for engineers that want to understand data in general, and software systems in particular. Foremost, Moose is designed for programmers, not for clickers. To get the most out of it, you have to program it. First, that means that you have to program in Pharo. Second, you have to learn the inner workings of Moose to understand how to use it.
This is actually less difficult than it sounds. Pharo is a beautiful language, and if you do not know it already, you will not be sorry for learning it. And Moose is rather small having less than 2000 classes and less than 150k lines of code.
Okay yes that’s a very nice explanation. I will try to learn Pharo and not be sorry. It is high time I learned me some kind of a Smalltalk. The language spent many decades being dead or mostly dead (eToys did its very best to make me hate Squeak) and now appears to be less dead. I’m very happy that Smalltalk’s not dead. BUT.
2000 classes and 150,000 lines of code is “small”?
Look, I grew up on 8k PETs. I’ve been looking recently at Uxn code, where files can be tens of bytes long. I’ve been playing with data files that yes might be several megabytes in size, but the Javascript I’m using to analyze them are on the order of 10 to 100 lines long. I’ve read that the Lisp 1.5 metacircular evaluator is about 30 lines of code (though I suspect that’s cheating). What draws me to Smalltalk in the first place is the minimalism: the Xerox Alto ran in 128K of RAM.
This artifact (is this a typical artifact for 2020s Smalltalk programmers?) definitely comes from a civilization somewhere in JCR Licklider’s Intergalactic Computer Network which does not define “small” on the same scale that I do!
Edit: Another quote, sorry. Just to show the Licklider mutual incomprehension of galactic species doing first contact problem:
Let’s look at an example. Suppose you want to look for all classes that are not being directly called by JUnit test.
model allModelClasses select: [:each |
each clientTypes noneSatisfy: #isJUnit4TestCase ]
Having a highly expressive API brings makes querying inexpensive
It does! Especially having lambdas is great for queries. But I’m pretty sure I could write that exact API in Javascript almost literally character-for-character with no loss of expressivity - and instant comprehension (of the grammar, at least) from millions of working programmers.
model.allModelClasses.select(each => each.clientTypes.noneSatisfy(“isJUnit4TestCase”))
I’m not saying I want to be using Javascript forever, I don’t, but it’s installed everywhere and everyone already knows it. I don’t yet see the argument for why the language has to be Smalltalk to do this kind of malleable data analysis. (As opposed to, say, Javascript running in a Computational Notebook kind of environment.) Perhaps I’ll find out as I go.
Edit2: Another example, to see how Smalltalk would translate to Javascript:
b := RTCircularTreeMapBuilder new.
b shape
borderColor: Color lightGray;
if: [ :d |
d files anySatisfy: [ :f |
f basename = 'build.xml' ] ] color: [ Color red ].
b leafWeight: [:f | f size sqrt ];
explore: self
nesting: #directories
leaves: #directories.
b
b = new RTCircularTreeMapBuilder;
b.shape.borderColor(Color.lightGray);
b.shape.if(d => d.files.anySatisfy(f => f.basename == ‘build.xml’)).color(Color.red);
b.leafWeight(f => f.size.sqrt())
b.explore(self);
b.nesting(“directories”);
b.leaves(“directories”);
return b
Ok there’s a few quirks, yes. Smalltalk can run zero-argument methods instead of doing object lookups (like sqrt) which is very nice, and semicolon maybe reduces repetition a little. I’m doing a bit of a hack to make a split keyword like if:color: translate to JS grammar. Atoms/symbols/keywords or whatever the hash things are called might be better than strings, but they’re still basically stringlike (and they aren’t as visually clean as Lisp symbols).
But I think we can do at least maybe 80% of Smalltalk in modern Javascript ES6 fluent syntax. I’m guessing the big wins come a little less from the syntax and more from just having a runtime object namespace that’s backed by disk storage and not having to constantly wrestle with a filesystem or database to get things done with your big models once you’ve imported them.
