Straying into dangerous territory

This is the 2nd part to my previous post, Squeak is like an operating system.

It’s easy to get lulled into the notion when programming in Smalltalk that you can use it like you would a programming language that is separated from the OS, that uses libraries, and is only linked in by a loader. Indeed Smalltalk is a programming language, but more in the sense that Bourne Shell is a programming language on Unix, and you’re using it logged in as “root”. That’s a bit of a bad analogy, because I don’t mean to imply that Smalltalk is a scripting language that uses terse symbols, but the power that you have over the system is the same (in this case, the Squeak image).

In Unix, you manipulate processes and files. In Squeak, you manipulate objects. Everything is an object.

I had an interesting “beginner root” experience with Squeak recently, and it highlights a difference between Ruby (file-based) and Smalltalk (image-based). Some might judge it in Ruby’s favor. I was doing some experimenting in a Workspace. To further the analogy, think of a Workspace as a command line shell instance in X-Windows. I had been using a variable called “duration” in my code. It was late. I was tired (really interested in what I was doing), and I got to a point where I didn’t need this variable. Cognizant of the fact that in certain workspaces variables hang around, I decided I wanted to get rid of the object it was holding, but I was a bit spacey and couldn’t remember the exact spelling of it. I had already changed the code that used it. So I evaluated:

duration := nil


Duration := nil

just to be sure I got both spellings. At first nothing weird happened, but then I tried to save the image and quit.

I had forgotten that 1) all variables in Smalltalk begin in lower-case, and 2) “Duration” (with the capital D) is the name of a class. Smalltalk is case-sensitive. Instead of saving, I got an exception dialog saying “Message Not Understood”. I found the source of the error, and for some mysterious reason, a message being passed to the Duration class seemed to be causing the error. I inspected “Duration” in the code and Smalltalk said “Unknown object”. Alright. So it wasn’t the message. Still, I thought, “Huh. Wonder what that’s about?” I ended up just quitting without saving. I realized the next day the reason I got the error is I had deleted the Duration class from the image (in memory, not on disk)! I confirmed this by trying it again, bringing up a code browser and trying to search for the Duration class. Nothing. I thought, “Wow. That’s pretty dangerous,” just being able to make a spelling error and delete a critical class without warning.

What happened?

Say you’re using Unix, and you’re at the command line, and there’s a critical executable that Unix uses to calculate the passage of time, called Duration (I know this would normally involve using a time structure in C and some API calls, but bear with me). What I did would be the equivalent to saying, “mv Duration /dev/null”, and when the system tried to shut down, it couldn’t find it, and aborted the shutdown. I know this sounds weird, because I just said the image on disk was unaltered. Anything that is actively available as an object in Squeak is in memory, not on disk. The disk image is roughly equivalent to the file that’s created when you put your computer into hibernation. It’s just a byte for byte copy of what was in memory.

Unix treats directories/files, processes, and shell variables differently. It treats them each as separate “species”. One does not work like the other, and has no relationship with the other. I know it’s often said of Unix that “everything is a file”, but there are these distinctions.

Another fundamental difference between Unix and Squeak is Unix is process-oriented. In Unix, to start up a new process entity, you run an executable with command line arguments. This can be done via. GUI menus, but still this is what’s going on. In Squeak you run something by passing a message to a class that instantiates one or more new objects. This is typically done via. icons and menus, but at heart this is what’s going on.

Anyway, back to my dilemma. I was looking to see if there was a way to easily fix this situation, since I considered this behavior to be a bug. I didn’t like that it did this without warning. It turned out to be more complicated than I thought. I realized that it would take a heuristic analyzer to determine that what I was doing was dangerous.

I did a little research, using Google to search the Squeak developers list, looking up the keywords “Squeak ‘idiot proof'”, and interestingly, the first entry that came up was from 1998 where Paul Fernhout had done something very similar. He asked, “Shouldn’t we prevent this?” Here’s what he did:

Dictionary become: nil

Dictionary is, again, a class. become: is a message handled by ProtoObject, the root class of every class in the system. In this case it makes every variable in the entire system that used to point to Dictionary point to nil. The method description also says, “and vice versa”, which I take to mean that every variable in the system that pointed to the argument in become: would point to Dictionary (to use the example). I’m guessing that nil is a special case, but I don’t know.

Anyway, this caused Squeak to crash. The consensus that ensued was that this was okay. Squeak was designed to be a fully modifiable system. In fact, Alan Kay has often said that he wishes that people would take Squeak and use it to create a better system than itself. “Obsolete the darn thing,” he says. The argument on the developers list was if it was made crash-proof, anticipating every possible way it could crash, it would become less of what it was intended to be. Someone feared that, “if you make it idiot proof, then only idiots will use it.” The conclusion seemed to be that Squeak programmers should just follow “the doctor’s rule”: The patient says, “It hurts when I do this.” The doctor says, “Well, don’t do that.”

I can see that this argument has validity, but in this particular instance, I don’t like this explanation. It seems to me that this is an area where some error checking could be easily implemented. Isn’t it erroneous to put nil in for become:? Maybe the answer is no. I at least have an excuse, since I was using the := operator, which is a primitive, and it’s much harder to check for this sort of thing in that context.

I also realized that the reason that code browsers can warn you about doing such things easily is they have menu options for doing things like deleting a class, and they throw up a warning if you try to do that. The browser can clearly make out what you’re trying to do, and check if there are dependencies on what you’re deleting. Checking for “Duration := nil” would be akin to a virus scanner looking for suspicious behavior. I don’t believe even a browser would pick up on this piece of code.

This example drove home the point for me that Squeak is like an operating system, and I as a developer am logged in as root–I can do anything, which means I can royally screw the system up (the image) if I don’t know what I’m doing.

I do have a way out of a mess, though, with Squeak. Fortunately, since it’s image-based, if I had managed to save a screwed-up image, I could just substitute a working image. It’s a good idea to keep a backup “clean” image around for such occasions, that you can just make a copy of. I wouldn’t need to reinstall the OS (to use the analogy). It’s like what people who use virtualization software do to manage different operating systems. They save disk images of their sessions. If one becomes screwed up or infected with a virus, they can just substitute a good one and delete the bad one. Problem solved.

For the most part, I wouldn’t lose any source code either, because that’s all saved in changesets, which I could recover (though Workspaces are only saved if you explicitly save them).

Another thing I could’ve done is opened up another instance of Squeak on a good image, filed out the Duration class (have Squeak serialize the class definition to a text file), and then filed it in (deserialized it), in the corrupted image. I imagine that would’ve solved the problem in my case.

Having said all this, I don’t mean to say that if you’re a Squeak user, working at a more abstract level, say with eToys, that you’re likely to experience a crash in the system. That level of use is pretty stable. Individual apps. may crash, and people have complained about apps. getting messed up in the newer versions, but the system will stay up.

I can understand why some like Ruby. You get access to Smalltalk-like language features, without having “root” access, and thereby the ability to mess things up in the runtime environment. The core runtime is written in C, which conveys a “None but the brave enter here” message. It’s compatible with the file-based paradigm that most developers are familiar with. From what I hear, with the way programming teams are staffed these days at large firms, a technology like Squeak in unskilled hands would probably lead to problems. It’s like the saying in Spiderman: “With power comes responsibility.” Squeak gives the programmer a lot of power, and some power to mess things up. Interestingly, in the 1998 discussion I link to, there was a distinction made between “shooting yourself in the foot” in Smalltalk vs. doing the same in a language like C. The commenter said that a C programmer has to be much more careful than a Squeak programmer does, because a) pointers in C are dangerous, and b) you can’t avoid using them. Whereas in Squeak you don’t have to use facilities that are dangerous to get something useful done. In fact, if you do screw up, Squeak offers several ways you can recover.

In closing, I’ll say that just as a seasoned Unix administrator would never say “rm -r *” from the root directory (though Unix would allow such a command to be executed, destructive as it is), people learning Squeak come to the realization that they have the full power of the system in their hands, and it behooves them to use it with discipline. I know that in a Unix shell you can set up an alias for rm that says “rm -i” that forces a warning. I suppose such an option could be built into Squeak if there was the desire for that. It would depend a lot on context, and Squeak doesn’t really embody that concept at this point.

7 thoughts on “Straying into dangerous territory

  1. The more you write about Smalltalk and Squeak, the more I like it. I tried eToys a while back, but really did not have more than 30 minutes to mess with it. Very intriguing, though.


  2. @Justin:

    What made a good first impression with me with Squeak was Alan Kay’s presentation of it, particularly eToys, and Croquet at ETech 2003. It blew my mind. I know you’re real busy. I guess watch it in sections or something. Make a point of seeing it. It’s really impressive. He starts out talking about those who inspired him to create Smalltalk, like Ivan Sutherland (Sketchpad), Peter Deutsch (Lisp), Douglas Engelbart (the 1968 NLS demo), and Seymour Papert (Logo), along with some prior system examples. Then he gets into showing some real world examples of how kids in school have used Squeak to help educate themselves about real world concepts, like physics, and just generally about the concepts of computing. Then he gets into Croquet, which people have characterized as being like Second Life, though it’s meant for group collaboration on projects, and 3D simulation. The cool thing is it’s all written in Squeak. Even cooler is he eventually reveals that the whole slide/video presentation he’s given was done entirely in Squeak, not PowerPoint!

    To me, the Smalltalk language satisfies my need to program, to have some control over the system. The more modern windowing system in Squeak is called Morphic, and I think that would have some use to me as well. I should clarify that by saying “more modern”, I’m talking about its relative age to the MVC windowing system in Squeak, which is a carry-over from the original Smalltalk-80. I’ve played around a little with eToys too, and while I saw some potential in it for my use, it felt a little limiting. I think it would be great for kids to introduce them to programming and the concept of computing. It’s like Logo on steroids. 🙂

  3. Mark,
    I find the way you explain Squeak in this post and in part 1 very enlightening as to how to approach Smalltalk. I’ve tried a couple different Smalltalks and had some trouble getting the hang of it, but this “little operating system” metaphor really helps to make sense of it. Thanks.

  4. I did see that video, you linked to it some time ago. Very interesting stuff! Ahh, what I would not do for a 36 hour day or three day weekends… 🙂


  5. @Chuck:

    It’s kind of amazing how much difference perception makes, isn’t it? Prior to these last two posts, answering the question, “What is Smalltalk?”, I did a couple on “Redefining Computing”. That was the title. I referred back to a speech Alan Kay did from 10 years ago where he said that since nature has found an effective system for building things that can scale very effectively, software should emulate that model, which was what OOP was all about when he championed it 30 years ago. The problem is people got the message about objects, but not about emulating biological systems. That legacy lives with us today.

  6. Using Smalltalk sounds very similar to Lisp in this respect. You can mess with existing processes and environment variables while they’re running. Very dangerous… but it is also freedom from the edit/compile/test cycle. Also… debugging isn’t really a serperate process or program– you don’t have to do anything special to find out what’s going on with certain variables for example.

    This level interactivity makes VB’s popular edit-and-continue feature look downright tedious. (Experimenting with these languages is dangerous… you might not be able to go back to your old one!)

  7. @lispy:

    This level interactivity makes VB’s popular edit-and-continue feature look downright tedious.

    I’m sometimes puzzled why some people turn up their nose at Smalltalk, because it has features that people say they like in other programming languages. I’ve heard programmers rave about edit-and-continue and VB, and how they missed it in the first version of VB.Net. I’ve listened to the .Net Rocks! podcasts. The host is a VB.Net developer. He was so glad to learn that the next version of VB.Net would bring edit-and-continue back. Edit-and-continue is just an implementation of what you get for free in Smalltalk or Lisp.

    Re: experimenting with these languages is dangerous…

    Oh yeah! Don’t I know it! Several months ago I felt like I had taken the Red Pill. I was also having thoughts like that back stabber in the Matrix who was saying, “Why didn’t I take the Blue Pill??” I got worried that I’d get so spoiled that I couldn’t stand looking for anything but the few jobs that are out there that actually use this stuff. I’ve kind of gotten over that now. I’m not real sure what I’ll do down the road.

    It has been a journey. I was inspired to look in this direction by a few articles I read. The first was by Paul Murphy (on ZDNet). He wrote an article on Dijkstra and APL. I got inspired to look at some of Dijkstra’s old speeches. Interesting stuff. The next was by Joel Spolsky. I think he was complaining about the Java schools and “blub programmers”. The next was “Beating the Averages” by Paul Graham. His article kind of blew me away. I had never heard anyone talk about a programming language being the key difference between success and failure.

    I had initially been very turned off by Lisp when I was in college. It was spoiled by a terrible teacher I had. These articles and some others convinced me to give Lisp another try. In some ways I liked it, mostly because it’s been explained better now. In some ways it still felt foreign. Then I discovered Squeak and it’s where I’ve focused since.

    I keep forgetting if Spolsky ever said this. I know Eric Raymond did, that learning Lisp is an enlightening experience. It’ll make you a better programmer, even if you don’t use it in real world projects. Even though I’ve never listened to Raymond before, that was something I listened to. I never really thought I’d want to stay, so to speak. I thought I’d do as Raymond said: Learn Lisp, become a better programmer, and then go back to what I was doing, only better.

    Learning what I have through this, it’s caused me to look rather darkly in the rear view mirror at what I’ve been involved with in the past. What I’m learning now feels so inspiring. I keep feeling like I need to dig deeper and deeper into it, to try and truly understand it, because in terms of computing (not in life) there are some truly profound things about it. But the deeper I go the more I don’t want to go back. I think the reason is I’m realizing that Squeak/Smalltalk represents a totally different model of computing, a different culture of computing, than where I came from, and I like it better. One of the influences that really snagged me into Smalltalk (you could almost call him my “Morpheus” 🙂 ) is Alan Kay. I’ve said it so many times before it’s almost become trite. The guy’s amazing. Every time I listen to one of his speeches I realize something new. He is a deep guy.

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