Club Squeak

I just updated the entry marketing isn’t the problem to include a mention of PPD VisualWave and noted the licensing problem. At a time when developers were able to freely download the JDK & JVM, Smalltalk’s leading low-cost player had been, in effect frozen in place by the merger.

So was it Java’s fault what happened to Smalltalk? Nope. Sure Java had the market’s attention. But that internet bubble was really big, man. There was room for Smalltalk on there too and we had real-world-deployed experienced programmers to help. I think it wasn’t all about Java and the great timing, luck and marketing. It was also the anti-marketing it felt like the Smalltalk leaders did. That’s right. We did anti-marketing.

As I see it, the first major error happened before anyone ever really heard of Java. ParcPlace System merged with Digitalk. … In this man’s opinion, Java didn’t kill Smalltalk. If anyone did, we did it to ourselves. Java just applied the heat while we were churning.

We’re Niche Players

There are also relevant bits to mix in related to IBM’s role but irrespective of the corporate landscape, Smalltalk has and continues to be hampered by it’s Achilles heel - networking. Without rock solid, high performance sockets and broad support for popular protocols, you just can’t be an impact player in a universe held together by TCP/IP. Digitalk IIRC didn’t ship with any TCP/IP support and VisualWorks performance was not compelling.

Commercial web servers offer additioan features that would be3 very time-consuming to re-create under Smalltalk. … If the Smalltalk environment does not provide lightweight, preemptive threads to manage incoming connections, performance will be minimal.

Jonathan Pletzke - Advanced Smalltalk 1997

In 1992, before Java, David Simmons embarked on SmalltalkAgents and almost got it right but what happened there is WAY beyond the scope of this post. Squeak in 1996 took steps in the right direction, but was not focused on delivering the kind of commercial grade networking capabilities Java provided out of the box. Today’s VisualWorks, DabbleDB and Qwaq have proven that within a narrow niche and with enough resources, Smalltalk can deliver powerful networking solutions. However, for the typical developer, this is not the case. Too many easy things are hard and hard things are for all practical purposes impossible. Case in point - XMPP aka Jabber which has exploded into widespread use. Yes there are 2 Smalltalk Jabber clients available but they are sorely lacking. Secure authentication isn’t built-in and rolling your own with the Cryptography package is not trivial. In contrast, in the world of Ruby, the robust XMPP4R and the drop-dead easy Jabber::Simple built upon it have emerged as defacto standards from a pool of a half dozen or so implementations. However these problems are not due to some inherent flaw in Smalltalk but rather another facet of its Achilles Heel.

What continues to drive the expansion of the web is the convergence of TCP/IP and social networks. The human network of Smalltalkers is too small and lacks the diversity needed to exert a broad influence outside of itself. Don’t get me wrong, the Smalltalk community is full of wonderful people who are passionate about Smalltalk. However, it’s made up of isolated islands of folk with hardcore developers and researchers on one side, captive users on the other and a very transient collection of power users, scripters and intermediate programmers flowing in between. These groups don’t really party together, and the result is that innovation rarely gains traction. Just within the world of Squeak there are 7 incompatible major builds - Squeakland, Croquet, Plopp, Seaside, DabbleDB, Scratch and Squeak. Continuing with my XMPP example, if you google Squeak Jabber you have to hunt to find the actual code let alone find any examples of using it. Now some Squeakers might object - SqueakSource is the preferred place to look. This is true, but it doesn’t address the issues of completeness or examples. To be clear, this is NOT a criticism of the people freely sharing code, it’s saying there are not enough people in the community, particularly developers with paying users of any kind(end-user, developer). So continuing with the saga, if it’s 3:00 am and you’re having a problem, there’s nowhere to turn except the Squeak-dev list. If you ask a question there, maybe someone will respond quickly and if they do they’ll probably be friendly. There’s also a good chance they’ll be knowledgeable about Squeak in general. There’s less of a chance they are familar with the Jabber code or have used it very much. In the end that probably doesn’t matter because the problem will ultimately end up being socket and/or vm related - outside the bounds of most highly experienced Smalltalkers. One simply can’t tackle these problems effectively without significant experience in C. It’s not that the problems are intractable, it’s that the Squeak economy isn’t robust enough to support the level of expertise required to have rock-solid networking widely available.

Originally the purpose of Smalltalk was “to provide computer support for the creative spirit in everyone. “ Today, the Squeak site describes Squeak as

“In short, a personal computing environment that could be programmed by “the rest of us.”

For as long as I have been involved with it(27 years), there have always been elements of the Smalltalk human network who looking at things through a zero-sum lens, have preferred and lobbied to pursue “purity” at the expense of reaching out to and developing solutions for “everyone”. During Smalltalk’s short-lived Golden Age, Digitalk provided a win-win choice for “everyone” while people able and willing to pay the price of purity were well served by Parc Place. When the human network broke down it hurt Smalltalk’s entrance into and codebase for the web era. The good news is that today, there’s an opportunity to jump-start another Golden Age - stay tuned.