The Whole Package Matters

August 18, 2009 at 8:06 am 4 comments

The enormous discussion on “Lisp and Smalltalk are dead” (latest count: over 2,900 views) has spawned a parallel thread of discussion within the College of Computing.  One of the points of discussion that I found particularly interesting is the discussion of Vinny’s comment, about how Smalltalk wouldn’t be so bad if he could use it in the editor of his choice.

At first, I thought that was an entirely orthogonal issue.  What does the editor have to do with the expressiveness of the language?  Amy Bruckman called me on that point, and now I see her point.  The user interface does matter.  How well the interface supports the language does matter.  One of the biggest complaints that students had with Squeak when I taught it was the user interface. Complaints ranged from how unpleasant the colors were (which were changeable, but as Nudge points out, when the default doesn’t work well, people aren’t willing to make the choice) to how hard it was to find the menu item you wanted.  I chalked that up to being part of the learning curve, but maybe that’s the point.

I’ve been exploring some other languages recently like Ruby, Scala, and various Lisp/Scheme implementations.  I’m surprised at how few of these have editors or IDEs that come with them.  (With the great exception of DrScheme which is my favorite pedagogical IDE.)  Most of these have some kind of Eclipse plug-in, which doesn’t do me any good at all.  I have never been able to get Eclipse to install properly, and never got my head around how to use it.  On the other hand, they all have Emacs plug-ins, too.  I can use Emacs.  I’m not great at it (I’m a vi guy from my internship at Bell Labs in 1982), but I can use it.  And for the most part, it’s all the same then — it’s reliable and relatively consistent, whatever language I’m playing with.

Several years ago, Don Gentner and Jakob Nielsen wrote a great paper called The Anti-Mac Interface. They considered what kind of interface you’d get if you reliable broke every one of the Mac’s UI guidelines.  They found that you resulted in a consistent and powerful user interface.  It was no longer good for novices doing occasional tasks.  It was great for experts doing regular tasks and who wanted shortcuts and macros.

Nudge points out that the surface level matters, and if that isn’t smooth, people are discouraged from looking deeper.  The user interface level to these tools matter, and if they’re not understandable, nobody gets to the expressiveness.

Entry filed under: Uncategorized. Tags: , .

Lisp and Smalltalk are dead: It’s C all the way down. New Scottish Computer Science Curriculum

4 Comments Add your own

  • 1. Alan Kay  |  August 18, 2009 at 1:08 pm

    I think the “QWERTY syndrome” is a more fruitful path to pursue here, and to relate it to the anthropological human universal of “coping”.

    Over history, we find invention coupled with dogma. Many who have studied individual and cultural learning have likened it to an erosion model of memory. (Once a little groove is randomly made by water it becomes very efficient in helping more water to erode it further.)

    So “creative acts” are often resisted, but once accepted for one reason or another will cling, and most often far beyond their merits. Most “creative results” are more “News” than “New”, that is, they are extremely incremental to the erosion gullies already established.

    Once we put in the effort (for whatever reason) to learn something to the point of fluency (and this will usually require lots of coping, because most things have real flaws and/or barriers), we will tend to stay with it, in no small part because our automatic mechanisms have made most transactions (however inefficient) possible with little cognitive effort.

    Further, we will tend to fight to “stay in the gully”, and may be willing to do zillions of inefficient things, just because those things can be done by “the back of the mind” rather than requiring the front to now learn something different, even if much more efficient.

    This is a good argument for not being random about first encounters with things that have to be learned regardless of their worth, and about letting bad de facto standards work their way into the system with the excuse that “these can be fixed later”.

    I personally don’t like any of the programming languages around (including those I helped to invent) and I don’t like the tools surrounding them (ditto). But I’m as full of erosion gullies as anyone ….



  • 2. Mark Miller  |  August 18, 2009 at 11:08 pm

    When I was taught Smalltalk in college we used GNU Smalltalk, which can be run from a command line. We used its scripting mode so that we could edit our code in vi, and then run GNU Smalltalk as an interpreter on the code, which was in a file. All Transcript and debugger output was directed to the console/terminal. It ran “headless” in scripting mode, with no UI. This lets you treat it like any of the other languages you might teach. I’ve read that it also has a text-only interactive mode, with a prompt, so that you can try stuff out like in a Lisp REPL. I liked the “scripting” approach when I was first learning it. It allowed me to appreciate the language right away, and was what I’d call a “better lie” about Smalltalk for a beginner.

    Even though I saw some really wonderful things in it, I didn’t understand some important things about it using this approach alone. For example I thought that the different collection classes, and the subclass: message were immutable parts of the language. I also didn’t really understand how closures worked, even though I was using them successfully all the time. I think this had more to do with how easy they were to create, and that they resembled code blocks in languages like Pascal or C. It was only once I got into Squeak that I realized that everything is malleable. And it was only once I watched one of Alan Kay’s speeches on object-orientation that I began to understand the idea of message passing. The scripting environment didn’t encourage the idea of exploring the system, and I think that’s an important part of it.

    All of this may be beside the point. I was recently invited to watch the Abelson lecture in the SICP lecture series on “Generic Operators” (Lecture 4b) online, and I realized what he was demonstrating was the precursor to the rationale for OOP/message passing. It gave me a historical context for how it came about, not by telling a story, but by showing how you can go from a traditional style of programming that looks procedural to something more powerful. Perhaps rather than trying to approach Squeak from the “top down”–interface first, it would’ve been more constructive to take a “bottom-up” approach, studying the technical rationales for the design of Smalltalk before getting into it.

    I’ve found this approach to be very helpful in the past. For example I learned to program in assembly before learning C in college, and I found that I understood C much better this way than if I had been taught from a “C first” perspective. I can validate this with my own experience. I met some very smart people in college who were totally flabbergasted by C, who couldn’t figure it out. The difference was they didn’t have the background I had to be able to “see C from beneath”, to comprehend what it was really doing under the covers, and to see the rationale for why C was created.

    What might be even better would be to get students thinking about better ways to do things besides what would otherwise be done procedurally, and guide them through the process of coming to the rationales that created the languages they’ll ultimately study–because there were rationales for creating them that came out of a scientific approach. In the Abelson lecture one of the students complained a bit that the presentation was “contrived”, because he figured that the people who came up with the more powerful scheme didn’t produce it whole in one fell swoop, as Abelson presented it. They must’ve tried different approaches through trial and error before coming to it. Abelson acknowledged the student was right. “It’s very contrived,” he said. He said that there were still arguments about how to handle real world situations by expanding upon the model he presented (this was in 1986). The student’s question helped me realize that while Abelson’s presentation was very interesting, it didn’t help me really get the thinking that went into coming up with the model he presented. I haven’t really dug into SICP yet. Perhaps that sort of practice is exercised in the book.

  • 3. Owen Astrachan  |  August 19, 2009 at 9:50 am

    You write that you’ve never been able to get Eclipse to install and you can’t get your head around how to use it. I can understand the latter ore than the former. But you’re right, the package matters.

  • 4. Mark Guzdial  |  August 20, 2009 at 2:30 pm

    Fair comment, Owen — I wasn’t clear. I’ll describe my relatively recent Scala experience. I installed Eclipse on my Linux box — no problem. Then I tried to install the Scala plugin. My experience didn’t match the description of how to install on the website, e.g., prompts weren’t the same, order of events wasn’t the same. I then tried to use Eclipse for a Scala program. I got confused in what a Scala “project” was and whether I really did get the Scala mode turned on, or if I never got the plugin installed. Bottom line is that I never got a Scala program to work from Eclipse. I tried something similar years ago (with Ruby or Jython, not recalling which now) with similar experience. So maybe I did get the plugin installed correctly and just the interface befuddled me, or both. I can’t tell.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9,003 other followers


Recent Posts

Blog Stats

  • 1,875,117 hits
August 2009

CS Teaching Tips

%d bloggers like this: