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]
12 comments:
I'm really sorry to leave an off-topic comment, but... could you please remove MS Sans Serif from the default font list on your page, or maybe replace it with Microsoft Sans Serif? The former is a raster font, and doesn't benefit from antialiasing on LCD monitors. Thank you :-)
could you please remove MS Sans Serif from the default font list on your page, or maybe replace it with Microsoft Sans Serif?
Yes, I could do that. In fact, I just did.
And thanks for the information about the difference between MS Sans Serif and Microsoft Sans Serif.
Very well put.
I'm intrigued about your assertion about not receiving requests from other languages, and not sending them either. What do you mean by this?
Do you mean that Lisp can't read or print to I/O streams?
Do you mean that there is no infrastructure for interfacing with libraries from other languages?
Do you mean that you can't touch the POSIX API for IPC?
Do you mean that you don't have libraries for supporting XMLRPC or CORBA, etc.?
For anyone who has ever tried to wrap a C library in Ruby or Python, I can attest that it is far easier in your average Lisp dialect...
I'm intrigued about your assertion about not receiving requests from other languages, and not sending them either. What do you mean by this?
The major point is about attitude, not capability. Smalltalkers usually prefer to "roll their own," instead of using a C-based, Java-based or Perl-based library (for example).
Smalltalkers rarely even think about publishing their code so that non-Smalltalk consumers can use it.
Smalltalk systems generally have the ability to invoke foreign services. But the API for doing that is not part of ANSI-Standard Smalltalk, and so each implementation does it differently. And support for invoking libraries in languages that aren't in the operating system's link-library format is usually lacking (e.g, Java, Ruby, etc.)
Solutions do exist, such as CORBA and Web Services--but they are all specific to each Smalltalk implementation--which presents a major problem to anyone who wants to write Smalltalk code that will run in more than one Smalltakl flavor.
And the situation is essentially the same with repsect to making Smalltalk code invokable from other languages. Or perhaps even worse.
Each Smalltalk implementation that offers a solution for letting foreign code invoke Smalltalk does so differently. And the solution typically involves having at least one Virtual Machine running as a "daemon," listening for service requests.
In other words, it can be done, but it's hardly trivial. And Smalltalkers usually don't even consider it--perhaps partly because it's not trivially simple.
[By the way, let me say upfront that my major expertise is with Smalltalk, not with Lisp. If I've mis-stated the situation with respect to Lisp, I apologize.]
If the author had said python or ruby or something it might be relevant. But Perl? Is a link to a really old article or something? Perl is basically the COBOL of the '90s at this point.
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.)
This is a really difficult analogy to convey but if languages were forests, I feel we are calling one forest a forest and the other forest a tree. I have programmed on Smalltalk off and on for 20 years, python for the last 6. I fail to see the external interface difference or play zone difference as anything but a common fault in perspective. A Smalltalk image is a collection of Groups of Objects which provide certain functionality and are written by many different people. One can take this Smalltalk image and import additional functionality in many forms.
How is this really any different from the many python modules written in python to be imported by other python modules and run by a python interpreter all residing on the python path? Importing, configuring and using Zope (a python web application) is functionally the same as importing, configuring and using Seaside (a Smalltalk web application).
Oh wait, there is one difference. The Seaside stack is easier to install, starts faster, has fewer external module dependencies, a very functional built-in debugger, a good IDE, and total code browsing thanks to the IDE.
If I write a functional component for Smalltalk, how is that different or less friendly than writing a library for Python?
To me the issue is the same as RPN vs Algebraic notation. I grew up counting binary, calculating RPN and programming objects. That is my comfort space. Unfortunately Smalltalk has about the same mind share as RPN calculators.
Excellent post.
I've dabbled in Smalltalk a little here and there. By no means a guru, but I do respect it as a language.
That being said, in my dabbling, I hit the unfriendliness you speak off. I came away feeling that, the language was beautiful. The explanation was antiquated.
Smalltalk seems to want to live in a world of only Smalltalk. But, I guess sadly, the world isn't that way.
And as I see it the success of Perl, Ruby and Python all seems to have followed the same path each seeping in from the outside in. Being used here and there as glue. You know a cron script here, or as a more advanced bash there. Try writing a cron job in Smalltalk.
On the other hand, using C# and Java as comparison isn't fair. It is just a different world all together. A world of large corporate backing: making the libraries, and forcing interoperability.
Smalltalk doesn't have that luxury though. Instead, Smalltalk and lisp both would do best learning some social skills, and following the mold set forth by Ruby, Python, and Perl. I'd think they'd thrive in that environment.
Seaside would make a good service, though. Ramon Leon seems to be quite happy about combining .net database access and domain layer with a squeak presentation layer
People have no idea. Perl's use is scripting. Smalltalk's use is high-level system developing.
Only a nerd would use the wrong language for a task.
Thanks for your nice post!
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.
The answer is: Because he is wrong. Perl got popular because it was in the right place at the right time. That's it.
The reason we aren't all using Lisp or Smalltalk now is because those solutions required more of an upfront monitary investment then the others. That and they were concieved to be slow at the time. If we could go back in time and "release" a free Lisp or Smalltalk at the same time Perl came out no one would know Perl today.
Post a Comment