Dan Ingalls did a Google Tech Talk last month which may be of interest to many of the current Squeak-dev list discussions(Morphic 3, JVM etc.) as well as Croquet or anyone interested in the web as distributed object space.
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.
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.
A discussion on the Squeak list reminded me of the saying “those who don’t learn from history are doomed to repeat it” and thus prompted me to squeeze out another bit of this saga …
Back in 1992, before Mosaic, before Java(formerly known as Oak) was demoed to Sun management as a language for networked consumer devices, David Taylor examined the state of object-oriented programming in a book entitled
Object-Oriented Information Systems: Planning and Implementation
This book is available used for under a dollar and provides considerable evidence for my view that the vacuum created by the collective choices of the Smalltalk community opened the primary avenue for the widespread adoption of Java. Taylor conducted an informal survey that listed case studies of actual projects and concluded:
these findings jibe well with my own personal experiences as a project leader, contract programmer, consultant and mentor on major Smalltalk projects as well as those as an engineer and database administrator.
In the early 90’s, the corporate landscape was littered with the rotting corpses of failed C++ projects aimed at what we now call enterprise applications. Smalltalk had replaced C++ as the language of choice for new projects and as a more effective means of transitioning COBOL applications and programmers. Early in it’s growth, Java wasn’t replacing Smalltalk but rather filling a vacuum created by the Smalltalk community. Moreover, it was only able to fill this vacuum riding the Smalltalk-based VisualAge IDE that Eclipse was born from. This is happening with Croquet and will continue to happen with Smalltalk-based innovations until and unless the community learns the lessons of its own history. I am optimistic that it will though it will likely be painful for most.
People who are really serious about software should make their own hardware.
Alan Kay @ Creative Think Seminar 1982
Related Links:
Water and Ice
In any Squeak environment, the Object Explorer can help you learn how things work. The following link has a step-by-step, illustrated example:
Often in Squeak, whenever there’s interaction with the UI, the most direct path to understanding starts with the morph you are clicking. You can cmd-click(Mac) or right-click (Windows) on any morph to bring up a set of icons called a halo.
* For folk not familiar with Star Wars, see the Force
Ramon Leon makes some good points about the “out of the box” Squeak UI and I agree that marketing is important. However, like most folk relatively new to Smalltalk/Squeak and strangely many who’ve been around a long time, he’s been misinformed about why Smalltalk isn’t more widely used. Smalltalk was not beaten by either Java or Ruby, but rather failed to address the needs these languages did in a timely manner. It may be a while before I find time to finish up the long, detailed essay on this topic that’s been sitting dormant so for now let me put it in a nutshell.
It is a matter of record that Java was not originally designed to compete with Smalltalk as a generic application development tool, but rather C/C++ for set top devices. Before Java’s public release, the momentum in the corporate world had clearly shifted to Smalltalk over C++. Java wasn’t publicly released until 1995 and early in the year didn’t even enter into the language discussion. Nor was Java mentioned when Digitalk and ParcPlace merged later that year. In fact, at the end of 1995, IBM which had only recently licensed Java was still touting VisualAge over Java for the web! At the time the Java Enterprise Edition Platform spec was announced in 1998, none of the incompatible Smalltalk offerings from a stagnant ParcPlace-Digitalk, an indifferent IBM, a research-oriented Squeak, or single platform Object-Arts was really focused on delivering internet aware solutions. Java and Ruby merely stepped in and filled a vacuum.
Update: It is true that ParcPlace-Digitalk’s VisualWave was a powerful offering in some respects. However, it was an expensive and all-encompassing approach with no free stepping stones or incremental building blocks. In contrast, Java developers could download the JDK, explore and learn.
When you look at the 35 languages that rank above Smalltalk on the TIOBE Index(also relevant is O’Reilly’s Programming Language Trends ), marketing doesn’t really seem to be a primary differentiator. If one is seeking to expand the use of Smalltalk, I think it’s necessary to broaden the context ultimately to include the evolution of hardware and also give more weight to it’s ancestral meme. Many of the languages ranked ahead of Smalltalk owe a great deal of their success to ideas made popular by Smalltalk. Things that can be done to achieve more widespread use of Smalltalk will be the topic of my next “Smalltalk Reloaded” entry but I’ll say in closing that embracing Sun Labs Lively Kernel is one of them.
There’s hope that this election will be a catalyst for a better Squeak community.
On the one hand Spoon seems to be pointing back to the future where dynamic, intelligent change management ought to allow Alan Kay’s original notion of objects as “message sending computers” to become a reality. OTOH, we are not yet ready hardware-wise to have objects be individual computers. Plurion can’t come too soon!
Perhaps the solution to this dilemma is to just be the future and start taking seriously the idea of “messages all the way down”.
Mash together the ideas of TeaTime and Spoon and starting growing message oriented systems capable of evolving into hardware.
Powered by FireStats