Before they were called prototypes, instance-oriented approaches to organizing objects had become popular in AI during the 1980’s under the label of frame-based knowledge representation. At the time my career was just beginning to evolve from building spacecraft mechanisms to designing automated testing systems for them so I my understanding of computer languages wasn’t very deep. Even so, in spite of the fact that the people I saw as “experts” were more focused on the differences, objects, frames and entities all seemed more alike than different to me. Using Framework and dBASE, I combined them into something called the Knowldge Oriented Programming System(KOPS). Not long after KOPS was born Ashton-Tate began shooting itself in the foot so I began moving it to Smalltalk/V but had a great deal of trouble because the prototype ideas didn’t work well in a class based environment. When Digitalk introduced their visual programming tool PARTS which used unique instance methods I began to see that one could make Smalltalk more malleable. Around that same time, I read about Self, then Object-Oriented Programming With Prototypes and after that Squeak showed up with Etoys and Wonderland carrying the prototype meme. Today people are seeing prototypes as the future of object-oriented programming and Traits have found their way into the Squeak mainstream. Thanks in large part to Javascript I’d been able to experiment extensively with organizing objects without classes

All organizational functions carried out by classes can be accomplished in a simple and natural way by object inheritance in classless languages, with no need for special mechanisms. A single model—dividing types into prototypes and traits—supports sharing of behavior and extending or replacing representations. A natural extension, dynamic object inheritance, can model behavioral modes. Object inheritance can also be used to provide structured name spaces for well-known objects.
Classless languages can even express “class-based” encapsulation. These stylized uses of object inheritance become instantly recognizable idioms, and extend the repertory of organizing principles to cover a wider range of programs.
Self: Organizing Programs Without Classes

With Morphtron I had realized that one could achieve many of the same objectives without having support in the core language. This is because the memes are more fundamental than any particular implementation.

In a chapter on Symbiogenesis, George Dyson chronicles the evolutionary history of cyberspace going from order codes to subroutines and languages executing in operating systems and across networks:

The introduction of distributed object-oriented programming languages … is enabling numerical symbioorganisms to roam, reproduce, and execute freely across the computational universe as a whole. … Nils Barricelli, in 1985, drew a parallel between higher level object-oriented languages and the metalanguages used in cellular communication, but he put the analogy another way: “if humans, instead of transmitting to each other reprints and complicated explanations, developed the habit of transmitting computer programs allowing a computer-directed factory to construct the machine needed for a particular purpose, that would be the closest analogue to the communication methods among cells of various species”

“… In the game of life and evolution there are three players at the table: human beings, nature, and machines. I am firmly on the side of nature. But nature, I suspect, is on the side of the machines. …”

Darwin Among the Machines: The Evolution of Global Intelligence

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.

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:

• There is no way to tell how many of the C++ buyers are simply upgrading to new C features as opposed to using the language for object-oriented programming
• The early adopters of object technology have been primarily in the scientific and engineering markets where C is already an established standard.
• C has virtually no presence in corporate MIS departments
• Although there is some question about how gracefully COBOL can be extended into the object arena, Object COBOL already enjoys a large and highly receptive market in Fortune 500 companies, who are keenly interested in protecting their vast investment in COBOL programs and programmers.
• … found far more Fortune 500 companies working with Smalltalk that C++ for office applications

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.

Related Links:
Water and Ice

Intel The Software Company

Cisco The Software Company

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.

Getting Started With Croquet 

* For folk not familiar with Star Wars, see the Force 

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.

Each of these buttons saves you at least one click and most cases several. The “inheritance” button has color codings which provide information that’s very time consuming to get at. In my experiences, one almost always needs a few of these capabilities during a programming session. They do take up screen real estate but for many it’s a worthwhile trade-off.

In order to show these buttons you need to select “optional buttons” in the browsing section of preferences. If you don’t already know how to do this read the rest of this entry. (more…)