Smalltalk: Swimming with the fish

A while back I backed an IndieGoGo project dedicated to bringing Smalltalk to the JVM: http://www.indiegogo.com/projects/redline-smalltalk-v1-0

I really hope this project pans out, because I would love to be able to program in Smalltalk for practical purposes.

(In fact, even the thought of being able to write a single application in both Lisp (Clojure) and Smalltalk (Redline) is making me giddy. We're still a long ways from this dream, but perhaps it'll be possible one day.)

You could also do http://amber-lang.net/ and ClojureScript, no?

In Smalltalk, you can manipulate objects directly rather than just indirectly via code that operates on them. The state of your manipulation is made persistent in smalltalk's image facility. Also, the whole object graph is supposedly better exposed accordingly then what you could get sigh just a plain old debugger.

At least I think that is what the author is trying to convey.

The debugger situation with Smalltalk is part of what he's talking about. You're running your application, and some part of your code throws an exception. A window pops up with the stack trace in it. You can inspect all the objects in each frame. "Inspect" in Smalltalk means, see and change the properties, call methods, change the code, clone, see the class hierarchy, etc. You can modify the method that threw the exception right there from the debug window, save it, and resume the method from where it broke. Application proceeds with new code in place and problem solved.

Look, a cosmetic bug in this window. Right click on it, click Inspect. Looks like one of the properties has the wrong value. Edit the property from the inspector, fix the problem. The application was running the whole time and now is fixed.

An impressive thing you can do with Fuel is serialize and deserialize the exception with all state. Somebody blows up your web application. You wrote a bit of code to catch unhandled exceptions and export them with Fuel. You download the binary to your local computer and deserialize it in your live Smalltalk image. You see the debugger window pop up and can examine all the state when the error happened as if it popped up locally. See, examine, change the code, all of it live the whole time. (I don't know if this is done in practice much, but it's pretty normal to run a headless Smalltalk image and connect to it over VNC when you need to debug something).

To sum up, everything is live all the time in Smalltalk, and you can interactively change all the actual running instances, both code and data, at any time without interrupting anything.

Fish vs. fishes... and I think "sleeping" is the more common form (at least in media), but yeah, I was wondering, too.