Smalltalk: Welcome to the Balkans.
Never blog when you’re mad. This is an excellent rule that I’m breaking right here.
For fun and education I started a MongoDB driver in Smalltalk. I wanted to learn about a NoSQL database from the ground (-ish) up and potentially provide something useful.
Step one: get it running in VisualWorks. Not a problem. I’ve used VW for 15 years. Lots of details to get right, but I’m a programmer. Details are slops in which I wallow.
Step two: find a customer. Again, not a problem. Someone has an application they would like to have populate a MongoDB database for later processing by other tools. Problem: the server is in Squeak.
Step three: port to Squeak. The pain begins. Just getting the code out of VW was a pain. I discovered Monticello, which is a nice concept for source control, sort of a Smalltalk-y version of Git (in the sense that they are both distributed SC systems). VW interface to Monticello is broken. Discussion with author resolves the issue. Code has escaped VW.
Loading into Squeak is no problem, but the Squeak programming tools are just too painful to use. Look no further for a shining example of the tragedy of the commons. Design requires inhaling–adding features, trying experiments, tweaking, going off in crazy directions–but it also requires exhaling–taking similar things and making them the same and deleting experiments that didn’t work out or at least moving them out of the core. Back in the olden days the limitations of the VM drove this, which is why the core concepts in Smalltalk were so refined. If you wanted space for your application you had to find a way to rationalize existing code.
On to Pharo. Pharo has a more coherent set of tools than the cacophony of Squeak but the base language/libraries are the same. The cleaner look was a relief although the paint splatters seem a bit indulgent. Whatever. I run the tests. They all break. Not a big surprise.
What’s broken? First, numbers. Syntax for literals. “16rff” in VW needs to be “16rFF” in Squeak. Sigh. No Double class because all floats are doubles, so Float is actually Double. No way to access the bytes in a Float. Then, dates. No built-in way to turn a Java timestamp into a timestamp. Different conversions required between Squeak and VW. Next, UTF-8 conversion. Grease to the rescue here. It’s the compatibility layer Seaside uses. Finally, sockets. At least this is no big deal. One class replaced by another. Except the Squeak version doesn’t support retrieving the position in a socket stream. Quickly fixed.
Now, I don’t particularly care for Java. Erich will tell you that I’m not productive until I’m swearing at Java. But credit where it’s due: the basics are portable. Numbers, sockets, strings, source code structures. You don’t have to worry about those moving from one platform or another. The vendors have found other battlefields on which to fight.
All the tests pass in Squeak finally. I’ve been making the changes in place, figuring I’ll make some kind of GratuitousDifferences class to capture the, well, you know. I load my code back into Monticello (I love SqueakSource, BTW–easy to use, free, what GitHub would have been if they’d stopped developing after a month. I told you not to blog when you’re mad.) I go to load into VW. Kaboom. The meta information is snarled. The monkey patches are gone. Merging does nothing sensible.
And that’s where I sit, blogging because I’m too mad to think. I’m not just mad because I’m stymied. That’s frustrating but not out of the ordinary. I’m a programmer after all. What I’m mad about is the gratuitous balkanization of Smalltalk. Here’s a language and platform that still has a lot to offer the programming world. There are lessons there about programmers being humans and users being humans that could be profitably absorbed by computing in general. And they won’t be, not if you can’t even move code between versions. Who would rationally invest in Smalltalk code if they weren’t already locked in?
I looked up Nash Equilibrium because it seemed appropriate. A Nash Equilibrium is (broadly speaking, look it up if you want accurate details) when none of the players in a game can change their strategy without losing something. The Mexican Standoff (as long as I’ve insulted Eastern Europeans I may as well insult our neighbors to the south as well) is a classic example. No one wants to be the first to lower their gun. The Smalltalk vendors seem to me to be in the same boat. Everyone has taken their “ANSI standard” Smalltalk in different incompatible directions, but to move towards compatibility would be a loss. Hence, no one is going to change.
The thing about a Nash Equilibrium is that what is rational from within the game can be absurd from an outside perspective. I’m calling bullshit on the state of Smalltalk. Vendors, you’re acting crazy. Have the tiniest possible core defined in terms of test cases. Build a shared library on top of that, implemented in terms of the core. Include numbers, collections, meta-objects, code structure, and code loading. None of this parcel/bundle/package/pundle/category nonsense. Compete on VMs, graphics libraries, and enterprise-y tools.
I know this can’t be a sensible proposal. There must be huge, insurmountable problems with it. After all, I’m too mad to think straight. But it would have made my job a lot easier today.
Written with all the love I can muster,