Tuesday, May 16, 2006


Am I supposed to like Smalltalk?

When people talk in general about "high level, extensible, dynamic" languages on their blogs, they usually mention Smalltalk and Lisp in the same breath. Smalltalk programmers talk about their language in the same glowing terms as Lisp programmers; this prompts me to read about Smalltalk, and this weekend I tried out Squeak.

I think I'll stay with Lisp. I'm sure someone will say I didn't try it long enough, but there were a couple of issues I don't think will go away with extended use.

First of all is the environment/IDE. With Lisp/Emacs/Slime, or for that matter Java/Netbeans, to write method after method, you can just type. What I saw in Squeak was a bad combination of mousing and typing. You have to click in the '--all--' window of methods, then mouse down to the editing pane, and replace text, then save, then do it again for the next method. I'm sure this is a YMMV thing, but these mini-interruptions sure wouldn't keep me in 'flow' as much as just typing.

Second is the 'OOP all the way' flavor of the Smalltalk language. Sometimes a function is just a function, and doesn't need to be in a class. I prefer the options that Lisp provides, I use imperative, OO, and functional, depending on the problem.

All this is without bringing up macros, which I don't use that much now, but will do so more in the future, which will only widen the gap.

Have you tried Smalltalk, and why do you prefer Lisp?

I had much the same experience with smalltalk. I thought the concept of "everything is an object" could be useful, and an integrated IDE has it's place, but being forced to use it for everything lost me. Sometimes, I just want to edit in vi.

That being said, GNU smalltalk focuses less on the IDE / GUI and more on just the "language", but if you look at the source files, they have a lot of extra artifacts added to support importation into the GUI.

I decided that I much prefer ruby's "everything is an object" model to smalltalk, which doesn't force any form of IDE and allows a much more natural coding flow. I don't like ruby better than lisp, but at the moment there isn't any language i'm very happy with.

If you thought Smalltalk was worth trying, i'd recommend looking at ruby instead / as well. It's interesting.
I found Smalltalk to be nice and simple, which was appealing. However, I agree that the "everything is an object" mentality is annoying. My experience says that stuffing everything into object form is counter-productive in some cases, so much so that one must perform mental contortions to think about the problem.

If I went back to Smalltalk, I'd miss macros. Macros are what make me love Lisp so much.

Still, I admire Smalltalk for what it brought to the table when it was introduced.
Same as you -- I just couldn't get past the IDE. I try it a couple of times per year, and each time my heart sinks with dread.
Having worked in Smalltalk (VisualWorks, Squeak) and Common Lisp (SBCL,Clisp,ILISP,SLIME), I have to disagree with most of the comments about the Smalltalk IDE.

Incidentally, you don't have to keep selecting the '--all--' list item to create a new method. You can reuse the method pane in the browser as many times as you want. As long as you have selected the right class, write over the contents of the method pane, and the browser will do the right thing. And, there are add on features such as the WhiskerBrowser which take usability to a different level.

As far as whether you like an all objects style, or whether macros are non-negotiable, those are language issues. And, I'm sure a real Smalltalk "guru" can explain the motivations behind those choices a lot better.

Speaking of Lisp IDEs, I've only seen videos of the Symbolics Genera environment and it seems like the ideal to aspire to, but in its absence the usability of the Smalltalk environment has no match in Common Lisp -- before you unleash your flame throwers, let me clarify that I'm proficient in and use CL on a daily basis. This is not a critique of the Lisp language, but of Lisp systems.

Having used the Squeak environment for more than casual curiosity, I have to give it due credit for the way the browser, inspector and debugger were designed to work together. The integration of that environment is head and shoulders above any Emacs/Lisp IDE I've seen. Symbol completion is nice, but that's not an environment -- sorry, that's just the bitter truth.

I grant you that the mouse/keyboard interaction in Smalltalk will be a slight discomfort for anyone who's brain has been wired to Emacs (such as mine was :). But that's veneer, as far as I'm concerned. You can either adjust to it in a couple of days, or you can rewrite it to suit your style. What I'm talking about is deeper than that.

It's worth looking deeper at the Squeak environment, with an eye on the design more than the implementation. As Alan Kay said, 'point of view is worth 80 IQ points'.
I pretty much had the same issues as everyone else. Language looked nice, with good built in libraries. But programs are composed of text, you shouldn't have to/be able to treat code structures as if they were visible,tangible objects.
I've used Squeak off and on for several years now. The interface doesn't bother me; in fact, I find myself often wishing other systems had a similar interface. Debugging code written in Lisp (with Slime), or Python, or whatever, is nowhere near as easy as with Smalltalk.

I haven't used it for "real world apps" for the several reasons. The main reason is the same for Lisp: I'd have an exceptionally difficult time finding a replacement programmer for anything I wrote in Smalltalk or Lisp. Even using python in Zope (my current work project) might be pushing it.

Secondly, Squeak lacks a jit. While I could rewrite critical pieces of code in C and use Squeak's plugin interface (pretty easy, actually), I'd now have to find a Smalltalk who's comfortable with Squeak's ffi. Or, I could use Cincom Smalltalk, but their business model probably won't work for me, at a startup.

So, I've used it for tiny personal projects, and that's about it.

I'm curious -- what makes you think you'd miss macros in Smalltalk?

Dylan was a good compromise: it was objects all the way down, and had a CLOS-like object system (meaning, methods aren't part of classes). It had macros, though not exactly like the Lisp ones (Dylan switched from a prefix syntax to an infix one during development). A lot of Lisp people worked on Dylan, including some who had previously worked at Symbolics. Apple Dylan was written in Common Lisp.

Apple pretty much killed the project in 1996, and relatively few people used the Windows or Linux implementations. Like Smalltalk, Apple Dylan had an IDE, and stored all the code in a database (though you could export/import code as files to edit with other editors).
Smalltalk is one of the small handful of languages that experienced programmers can actually learn something useful from. You've focused too much on the negatives of how it differs from lisp (and I will agree with the majority of those negatives). However, lisp has its own negatives, and smalltalk has its own strengths.

Here are some positives to Smalltalk that I don't need to strain to identify.

1. One contribution that I personally find important is the ease of entering the world of smalltalk. Get squeak, launch, and you are there with a GUI and access to a large quantity of relatively high quality reusable code. Compare this to firing up Java, Perl, or *gasp* your favorite dialect of lisp with slime. Most programming environments are simply shameful when compared to smalltalk in this regard. Other than Lispworks, modern lisps are remarkably shameful in this regard.

2. Objects all the way down. You may not personally like this notion, but Smalltalk is one of the few supposedly object oriented environments that actually demonstrates the power of this concept when implemented as Alan Kay envisioned (e.g. late binding). You can debug from the highest levels of abstraction down to the lowest levels of detail with one style. Smalltalk hints of treating all portions of the system (processors, threads, remote machines, remote processes) all as objects with consistency of reasoning about how things work and interact. If you really know lisp, you know the power of "all the way". What could be a more effective development environment than a lisp machine or a symbolics machine where it is lisp all the way to the core. The next time your OS blue screens or panics, remember it could have resulted in a interactively debuggable pop-up. Smalltalk hints at this somewhat better than current lisp implementations do.

3. Self documentation and ease of re-use. You may not like the GUI very much but you are missing a big piece of the point. That GUI is designed to simplify re-use. Not the "re-use" claimed by java weanies the world over but actual re-use (at least as close as anyone actually has gotten). If you code from a blank sheet, you will tend to write everything yourself (assuming you have the skill to do so). However, in Smalltalk, you are strongly encouraged to not start scribbling into that blank file. Instead you are encouraged to explore. What is already there that is close to what you want? How was it implemented? Are there pieces you can re-use? Is there a way to change what is there to make it re-usable? Unlike the plethora of code one finds on the net today, an experience programmer can actually learn something by reading some of this code (less true today than it once was now that the monkey programmers have found smalltalk too). Anyway, the key point is that this interface tries hard to explore and locate what is already available. An experienced Smalltalk programmer will tend to extend what is already there rather than write gobs of new code. The GUI reflects that. Smalltalk also encourages brief and useful documentation by making it readily available. This is nowhere near as well integrated as elisp documentation, but hell, one rarely sees documentation *that* well integrated.

One of the things I find remarkable about smalltalk is the range of things you will find implemented in that core squeak image. I have looked for an algorithm on the net only to find bad implementations and worse descriptions. After wasting time searching the wasteland, I fetched squeak, poked around for a couple of minutes, found exactly what I was looking for (in excellent code), extracted it and translated it to the language I was working in. I would never think to attempt this in lisp -- the likelihood of success is way too low.

Most programming languages/environments have little to teach (most are direct descendants of fortran - often with little more than syntactic "sugar"). But others have a lot to offer. Different ways of expressing solutions and different ways to think about the act of programming itself. Various dialects of lisp, prolog, fp, gofer, perl, and *smalltalk* are some of these languages. If you are going to bash a language, find something more worthy of bashing. It isn't all that hard.

As with any programming language (even the progeny of fortran) you are best served learning its strengths by observing someone who is really good with it. A good language/environment, operated by someone conversant with it, should be able to make some of it look like magic (any sufficiently advanced technology...). You can almost always learn from this. I think you would have gotten quite a bit of mileage observing and pair programming with a squeak wizard. Often, but not always, you can take away the best of what you have seen and make it happen in your own environment. This is what you should be striving for in your explorations.

Perhaps the reason people mention both smalltalk and lisp in the same breath is that there is a lot to learn from both.

-Scott D. Kalter
That should read "I'd now have to find a Smalltalk programmer who's".
Just Tried smalltalk for the first time last night. Not sure of opinions about it. Im thinking EMCAScript may be my perfect language ;-)
I have used squeak from time to time, and generally have enjoyed the experience. Well, to a point anyway. I'm not a SmallTalk guru, nor a Squeak guru, so bear that in mind.

One of the things about smalltalk is the constant browsing a beginner does to find out what has been written that can be reused, coupled with the frustration of not understanding how to use what is found. That is me largely. I did develop a cut-list program for a carpenter friend of mine in Squeak (I needed fractions and Squeak does that nicely out of the box).

I don't use smalltalk for anything other than a toy to play with programming concepts because of 2 things:
1) I find other languages more approachable. I can understand how to install extra libraries and use them easier than I can in smalltalk.
2) I can deploy other languages easier than smalltalk. I tried to explain to my carpenter friend how to download all the pieces needed for Squeak on his windows platform, then how to get my code and run 'file-in' on it to get it in the vm, then how to open a workspace and start it. I gave up and rewrote it in java as an applet (including porting the fraction stuff to java - that was fun!) and telling him to point to a url. I could have done that with the squeak plugin, but then would have been back to the same thing with how to get/install the squeak plugin and hope it worked with my code.

I wrote a billing automation program in lisp and it has been very robust and has weathered several changes (some on the fly) over the past two years, and I'm still running it on an old version of clisp. It was very easy to deploy.

Anyway, my $.02 -- if it's worth that much. :)

-- Jeff B.
Well others have made good points. I just can tell I like Lisp and Smalltalk, but I'm more used to Lisp and have written much more software in it. Be it some Scheme, Emacs Lisp, Common Lisp. However I have at least three smalltalks on my machine also (besides around 3 Lisp and at least two Schemes ;-)

What I like more about Smalltalk are the browse facilities, and the cross referencing is better there usually.

Squeak comes with around 5000 classes here, and you'll find something for everything. Getting now packages is easier for me on Squeak just load the Package Browser and that's it.

I can not comment on the quality of the libraries in Smalltalk, because I do not know them good enough. But I have had hard times with quite a few Common Lisp libraries. The often come with no documentation they do not compile cleanly and have an interface to run away.

This has not happen to me with Smalltalks. Smalltalk definitivly is easier to understand and it's more uniform in it's interface.

Luckily I do not have to decide to prefer one over the other. So I still can enjoy the installeds Lisp and Smalltalks.
To Jeff B:

Why didn't you just ship your customer the image file and VM?

Making him "download all the pieces" and file-in your code is a poor way to distribute a squeak application.

I hear you can integrate the VM and Image into one file, which would then be a single-file executable, But I have never done it.
Also on deployment:

I agree the documentation in Squeak often lags, but in this case, it is on the FAQ:

FAQ: Distributing Squeak Programs

Have you seen this "Smalltalk for Lispers"


I suppose you know that the first version of Smalltalk was basically Lisp.
"I can deploy other languages easier than smalltalk. I tried to explain to my carpenter friend how to download all the pieces needed for Squeak on his windows platform, then how to get my code and run 'file-in' on it to get it in the vm, then how to open a workspace and start it."

Why the HELL would you do that? Hand the guy a zip archive with the image/changes/sources and vm.exe file in it and tell him to click the .image file. WTF?

The java equivalent experience would be to expect him to download java, tomcat, integrate with apache, deploy jar file. No end user will do all that either.
Maybe I can say on that:
1. As far as I know You can write in Vi or whatever You want including cell phone in Squeak case(they had that in mind when i left 4 years ago) it was named "headless"squeak if I remember for cel phone i think you should run some web service (Nebraska??) i never do anything of that so that is what I remember (or not:-) from mail list discusions.
To find someone who want to answer Your question (not something they want to tell You )documentation or standard is very different thing ...and in fact it is the worst about smalltalk/squeak.
2. Squeak have great graphics not IDE/GUI - in the begining it is not easy to make a difference .Squeak IDE is 30 years old idea ,and it is the worst I ever see it is provable it can't work... and around 1996-8 I saw VisualSmalltalk where IDE is what it should be ...It is possible to "write" complete application without writing a line of code ... VisualSmaltalk(last time i saw it was owned by Cincom) is not open and You can have idea what it is from documentation or VisualAge from IBM(but they find a way to "improve" it so it is not so intuitive ...).
3.Math of Smalltalk is much more interesting and natural for me but they invented objects, patterns ... to hide it so You have a choice to be treated as 8 years old semi-idiot and to take objects... or to look what's behind Yourself .Or to go with lambda calc ...:-).
4.Smalltalk is based on very best ideas of 50ies and 60ies and it is my personal opinion -it was not invented by Alan Kay but he was remarcably brave to insist on this ideas and it is great that he saved them for us in time when bad ideas like structured programming and FORTRAN controled the most of programers mind ...Alan Kay is one of the real heroes in software and I think that we all shold at least to try to understand his ideas best way we can
I have my own small war against Alan Kay and objects, and I always think for smalltalk as for a toy that shows what we can reach if try to do the right things...so nobody is supposed to like smalltalk ,but it is absolutely unimportant if we like it or not this is the very best in software and the wisdom and understanding it can give is priceless (i.e. one can mix in random proportions smaltalk lisp and maybe prolog ant to get Dylan Pyton Ajax or whatever but few of "mixed states" can't teach You much more than how to repeat their style ... in smalltalk and lisp You can learn how to think ... well , not exactly I saw people who tryed to think on IT in 70ies when I was 3 years old and I dont think that anyone in the world now know how to think (IT) much better than in 70ies...so you can learn only as little as it is known about , but that is all we have... and for thinking it is good to know that same thing could be expresed in more than one-lisp-way so that is value of smalltalk for lispers - smalltalk is complementary way of thinking - starting with lisp you can come to smalltalk or starting with smalltalk you can come (back) to lisp but both are complete and independant (well, different axioms for same theory ...at least I said it in my math language :-)
I don't get it. All the stupid parroting about lisp. They read about it having macros, REPL, HOFs, supports multiple paradigms of programming and CLOS. So it has to be better than anything else. How many of these features do they actually use/have used?
I wonder if any of the people mouthing off about lisp have actually used it for any non-trivial task. Or smalltalk for that matter before opinionating. I'm not even sure I like the PG converts - those that read his articles and start blabbering about lisp. Lispers are being nice these days after having a reputation of being intolerant. I think in cll they should be intolerant towards parrots blathering around.
I wonder if the phenomenon about people complaining about smalltalk's IDE way of doing things is similar to the one of people complaining about lisp's parentheses.
Listen to the best of the programmers - they'll say, learn all kinds of programming paradigms. Learn C, lisp, java, haskell, smalltalk, etc. I suppose they are the ones that aren't being driven by a weird kind of insecurity - a dumb drive to prove (to who exactly?) their chosen language is the best. Because they KNOW it.
Kn8hqW Your blog is great. Articles is interesting!
lJmVgD Nice Article.
Thanks to author.
Good job!
Hello all!
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?