How Developers Use Dynamic Features of Programming Languages: Smalltalk [pdf] | Hacker News Reader

How Developers Use Dynamic Features of Programming Languages: Smalltalk [pdf]

users.dcc.uchile.cl

87 pointsmpweiher10 comments

Here's a trick I miss from Smalltalk. (VisualWorks in particular.) While stopped in the debugger, you can easily write a script to search all existing strings for a match, even a regex match. Then you can very easily ask a string you're interested in for its "owners," inspect those objects and browse their code.

You can write code very complex conditional code for debugging, without the tons of roadblocks an environment like VisualStudio will throw in your way. Then your conditional debug code can find a particular instance and tell that specific instance to change its class to a special debugging subclass.

There are many other tricks, but the combination of just those two tricks give you debugging "superpowers."

There's so many nice things like this that Smalltalk offered. Fundamentally, they were inspired a lot by systems thinking / theory and related fields like biology. They seemed obsessed (in a good way) with allowing deeper understanding. Powerful debugging is def. a key thing here!

It was basically the big thing in practice. Expert Smalltalkers basically coded in the debugger. It was easy to change the method for the current context's code, unwind the stack, and try again. That, combined with a coding culture that emphasized simplicity.

> they were inspired a lot by systems thinking / theory and related fields like biology

How's that?

The objects are "alive", even the ones in the debug stack. You can "talk" to them and get their state, ask them to evaluate an alternate flow etc, for any line in the stack.

In fact, the stack itself is just a normal property of the system that shows up when the system encounters something it does not understand, and asks you to provide an answer.

Smalltalk is absolutely weird.

The #allInstances method would be a gift in many languages for debugging purposes.

Would a factory be able to achieve this? Keep a reference to everything it had constructed?

For your own classes/types and factory for every other class that you can in “client” code, yes. But harder or impossible with most languages for builtin types that you don’t instantiate directly.

It’s a very different feature set, but superpowers like that remind me of the Erlang BEAM. Being able to log into a production server, inspect its processes, trace messages in real time and load new code without disrupting the server is quite amazing.

We were able to do such things in Smalltalk as well. The Parcel format was designed to freeze the VM, apply a code change atomically after morphing any objects which were changed, then complete any in-flight transactions with the new code. Once, I logged into a running Web App Server image and manually manipulated DB lock in the ORM, because we had to do a demo before we could fix a particular DB bug. (So I was doing this "live" during the demo. Mind you, this was back in 2002 or so.) We could also use the image saving feature to basically create a "live" core dump while letting the server continue to recover and run.

Reply on news.ycombinator.com