Sometimes it's hard to explain to people from other software development environments just what it's like to work in Smalltalk. Over the years, many languages have tried to approach the feeling of Smalltalk and not quite succeeded. The following story tries to relate how we feel.
You are a marine archeologist. You strap on your scuba gear with the new re-breather that doesn't make any bubbles and you jump into the water. As you explore around, you see fish, sharks, stingrays, coral reefs and squid. You swim over the coral reef and spot your destination - a sunken ship. You need to find out why it sank. You circle the ship once looking at the hull, feeling the texture of the wood, and finally entering the bridge. You turn the turn the wheel and it doesn't feel right - the wheel spins freely without the normal resistance. You open the hatch in the floor of the bridge and swim underneath to have a look. There's the problem. There's supposed to be a gear right there. That gear made the connection between that shaft for the helm and the rudder. You look around and spot the gear sitting close-by. It looks fine. Why would it have come off? It's supposed to be held on by a linchpin. Oh, there it is. The linchpin has been sheared in half. That's what caused the ship to lose its steering and run aground.
Several miles north of you is another marine archeologist exploring another similar shipwreck. He's sitting on the ship operating his remote-control submarine and staring at the monitor. There's the coral reef. Float up. Turn 10 degrees right. Forward. Slow down. Forward again. There's the ship. Forward slowly. He struggles to keep the camera turned toward the ship as he navigates the submarine around the hull. Stop here. The view on the screen is too close and only shows one or two boards. It's a struggle to look up and down. He would have to back away from the ship. It would take hours to see the whole ship this way. Let's move to the bridge. Up, up, up, stop. Now to the right. Stop there. There's the bridge door. It's closed. The submersible has no arms it could use to open the door. Besides, this submersible wouldn't fit in there anyway. Return the submersible to the surface. Record the cause of the accident as operator error.
As a Smalltalker, you're used to "swimming with the fish". You live in the same world as the objects you're exploring. You can reach out and touch them, manipulate them, turn things and see how it feels. You can go anywhere and do anything. You can go behind the scenes and figure things out.
In other languages, you're in a different environment operating your tools by remote control. You're limited by the abilities of your tools and you're not able to easily manipulate things in your environment. You can try to get closer and closer to the feeling of being there with virtual reality or better robotic probes, but in the end, there's nothing that's quite the same as swimming with the fish.
I think that Smalltalk's biggest problem is one of perception. People see it as slow and in some regards behind the times.
ReplyDeleteI think this is both unfortunate and unnecessary given the evolution of hardware since the mainstream community stopped caring about Smalltalk.
A goodly chunk of it may simply be that many technologists are forever obsessed by the new bright shiny, and anything that's been around a while is instantly deemed to be unworthy of significant interest.
This comment has been removed by the author.
DeleteDo people still say Smalltalk as slow these days? Smalltalk compares favorably with Java in performance and is faster than Ruby and Python.
DeleteWhere specifically do people see Smalltalk as behind the times? If you had your say, how would Smalltalk change to address those concerns?
I see the problems with low adoption of Smalltalk as:
ReplyDelete1. Fragmentation (similar to Lisp).
2. Lack of presence in University curriculum.
3. A general preference for source-code based over image/vm based development entrenched in the Corporate world.
By "fragmentation" I assume you mean that there are many different dialects of Smalltalk that all work a little differently. Interestingly, your other two points aren't anout the Smalltalk technology but rather how it's perceived and accepted by the rest of the world. How can we change that?
DeleteWell, an all-encompassing, immersive environment sounds wonderful in some ways, but it's live and intimate. It's easy to imagine there is some appeal to a somewhat more reserved, arms-length relationship: in the usual unix-y model, there is a certain amount of ongoing session-like environment, but applications are pretty much constant "base matter" that is brought to life for an execution. The question is: how and how much of the environment is changed when you run something? IIRC, the advanced Smalltalk (and Lisp) environments had facilities for managing snapshots. Conversely, it's not hard to imagine a modified *nix system that treats executing programs as more persistent things, not just transient mutators of files.
ReplyDeleteI love Smalltalk, because I script alot in AppleScript, where you have the exact same experience. -And it is of course also wonderful that most of the apps on the plattform supports AppleScript, giving you quite the fauna.
ReplyDeleteBut why not show people video?
ReplyDeleteActually, I'm planning to make a video to show Smalltalk in action and to help in the discussion.
DeleteUnfortunately, smalltalk *is* sleeping with the fishes.
ReplyDeletehttp://rapgenius.com/873950
This comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDelete