Smalltalk Considered Unfriendly
Eric Dobbs' blog post (Playing Nice - what Perl's got that LISP and Smalltalk lack) hits the nail on the head: Smalltalk and LISP have not been as successful as Perl because LISP and Smalltalk want to be independent universes, hermetically sealed off from the rest of the world:
There's always been only one Perl; differing versions, sure, but you have never had to spend any time choosing whose Perl interpreter to use. More importantly, Perl began with the assumption that it would not be the only tool in your toolbox: it set out from the beginning to play well with others. By contrast, there have always been many flavors of LISP and Smalltalk any of which have tried to be pretty much everything you ever need.
Painting in broad strokes, David says Smalltalk's weakness is "at the boundaries:" when you want to try to do some typical unix system maintenance, or interfacing with underlying C libraries, or something similar. As long as you're staying within the Smalltalk environment, it completely rocks. But it's definitely painful if you try to reach outside. And it's especially painful if you want your code to work with different Smalltalks. What Perl got right was making it completely painless to integrate with its environment.
In some sense LISP wants to be on a LISP Machine and Smalltalk wants to be in its virtual machine, whereas Perl wants to go out and play with the other kids. The former languages are introverted and Perl is extroverted.
But, as Eric points out, that raises the question: "Why is Java more successful than LISP and Smalltalk?" After all, Java also wants to do everything itself, in its own idiosyncratic way, instead of relying on the host platform.
My answer: Java has not been as successful as it could have been, had it not been so fixated on always defining its own, separate culture (e.g, libraries, protocols, architectures, standards, etc.) And Java has peaked. It is losing ground against its competition, not continuing to advance. It owes its initial success to several unique factors, none of which are anywhere near as important as they were ten years ago: a) C++, b) the internet revolution, and c) the backing of Sun Microsystems, Inc. Java is now a legacy programming language, and its future will unfold in accord with that status.
Note that the languages that are beginning to overtake Java don't suffer from Java's antisocial attitude: Perl, Ruby, Python and C#. Yes, C#. Sun's strategy with Java was "same language, same architecture, same libraries--on all platforms." Microsoft's strategy with C# (and the CLR) is "any language, same architecture, same libraries, at least on Windows, and we're OK with others duplicating the CLR (and .Net) on other operating systems."
But I would also note that the the CLR, although it is better than the JVM at support for multiple langauges, is nevertheless not as friendly as it should be to deeply dynamic programming languages. That's one reason that the CLR-based languages aren't quite as "hot" as Ruby, Perl and Python.
Society is based on the theory that cooperation and collaboration are superior to conflict and confrontation. Peace is better than war. Friends are better than enemies. But Smalltalk and LISP have been trying to succeed as anti-social hermits, alone on their respective mountaintops (or up and away in their lonely balloons.) In the long term, I don't think that approach is likely to succeed. Smalltalk and LISP need to learn how to "play nice."
And there are two sides to "playing nice":
- Being willing and able to request services from your neighbors
- Being willing and able to answer requests for services from your neighbors
In other words, interoperability is reciprocal. You have to be able to play the role of a "broker," someone who "makes a market" in some set of services or commodities. That means you have to be equally willing to buy (make requests) or sell (respond to requests.)
From the point of view of the outside world, to the extent that Smalltalk and LISP provide any interoperability at all, it's almost all one sided: Smalltalk and LISP may deign to request something, but they don't offer any services in return. Unless and until that changes, I don't foresee either Smalltalk or LISP making much forward progress in the marketplace.
Of course, it's not that simple. There are really strong and compelling technical reasons why Smalltalk and LISP don't offer services that are easily consumable by foreigners. And there are also strong and compelling cultural reasons why Smalltalk and LISP prefer to build their own services and tools, instead of using the "community standard" services. The future of the two languages will depend on whether Smalltalkers and LISPers see these facts as reasons to do nothing, or as challenges to be overcome.
[Post Script:
I don't whether this is a direct response to my post, but Cincom (the folks behind VisualWorks) are making significant improvements to the ability of VisualWorks Smalltalk to "play nice" with other languages—as described in a blog post by James Robertson, the VisualWorks product manager: Better FFI all the way around]
