Disclaimer first… I was an avid Smalltalk advocate from 1992 until 2012. I worked at Cincom for 6 years.
A few thoughts.
For better or worse (worse in the final analysis I guess), Smalltalk doubled down on an odd proposition. Instead of tools and compilers and language syntax/model being orthogonal/independent things, what could be leveraged if they were highly coupled? If you read the Byte article, and some of the other seminal Smalltalk papers you see this theme.
Smalltalk syntax really struggles outside of a Smalltalk environment. I tried GNU/Smalltalk and a couple of other “IDE-less” Smalltalk in VIM. I’m very comfortable worth VIM. It just didn’t scale well.
But it was a dream in a well done IDE. For the last 10 years, I do C(++), Elixir, Kotlin, Python, Swift/ObjC in a variety of VIM, PyCharm, VSCode, XCode, AndroidStudio, Eclipse, and QT Creator. The IDEs just don’t go as far at all here. The text editors are more modern, but the ability to work with (navigate, refactor) the code at a high level is nothing compared to what it was in some of the better Smalltalk IDEs. To date, no refactoring engine has approached the level that John Brant and Don Roberts did for the original refactoring browser. Unit Test integration at the code browser level existed before the other NUnits were even built. The Smalltalk debuggers were so cool. Interactive process/context inspector/manipulators would have been a better term.
I’ve theorized that the reason Smalltalk the language and Smalltalk the syntax could marry well is that they found a sweet spot in language complexity that made the IDE easy ish to implement and manipulate code, at a syntax level and at a code structs level. Smalltalk syntax existed really only at the method level. Smalltalk code structure was modeled in the “image” as a code database more than as a textual flattening.
It’s interesting how a paper dated 2000 might give the impression that some archeological find reveals while Smalltalk was not a success. I think that would be a misnomer. I was there. This sentiment was pretty common. “It’s too different” is a pretty timeless trope. All this paper shows, is that just like today, there is a small subset of computing enthusiasts that get excited about new/cool/different things, while the populist/conservative types push for things to mostly stay the same.
Smalltalk required a paradigm shift to appreciate. Most of us have limited resources. We don’t have time to explore every revolutionary paradigm shift; the ingress process is just too high.
I’m not trying to pitch Smalltalk paradigm shift as a worthwhile payment for what you got out of it. Those of us that paid the price to achieve the shift, appreciated what the difference was about, even if we’ve mostly moved on since then. Papers like this were a common “I don’t think the shift will be worth it” sentiment.
So the common "refactorings" I see in IDEs now days tend to be things like rename, extract/inline, and a limited amount of class hierarchy change.
Some of the other one's I remember involved parameter add/removal (I think PyCharm can do this one?), extract to component, and high end ways to manipulate the class tree like add/remove/pivot class hierarchies.
There were some fun "extras" too like convert to/from ValueHolder (a ValueHolder is a Pointer with Notifications attached to it).
Where the magic began though was in this very simplicity all-in-one thing. To mess with the Refactoring engine in IntelliJs tools or VSCode, I have to learn another language, do another build environment. In Smalltalk, you were there already. It's all in the same code browser. Just scroll down to that part of the system. The AST is so simple, it's expressed in ~15 Node Types (compare to Ruby which has +90 parse node types someone told me?). The matching node type was a single additional node type. So you could see the code that did the refactorings. And you could use the same match trees they did. So you were minutes away from deriving your own refactorings. The first few times, it took longer than just doing them by hand, and then you got good at it and could do some cool things.
The only newer language that I've seen that maybe has this same "because we kept it simple we can do cool things" ethos to date for me is Elixir. My guess is there some others. My guess, is that like Smalltalk, any of these "mind blowing/changing" language/systems have a small but passionate following, but are not enjoying viral adoption.
One more thing, as much as I appreciate the efforts of the Squeak/Pharo crowd… I don’t think they’ve reclaimed the original Smalltalk synthesis experience yet. Like X11 desktops, they’ve not figured out how to apply the Less is More rule effectively.
I would be interested if you could comment on this further, if not here then maybe in a blog post. Do you mean deeper ability to manipulate the whole underlying system, rather than being confined mainly to the VM?
I put that idea forward because I’ve seen people working with the Emacs/Common Lisp combo wishing for something like that… that it was Lisp all the way down like an old Lisp machine. Seems like some are looking towards GNU Guix to approximate that sort of system.
For what it’s worth, I’m prepping myself to spend the next couple years at least exploring interactive programming systems like these, so perspectives like yours are fascinating to me. I’m not looking for a programming job any time soon (or maybe at all), so I’ve got time to study most seem to think is “alien technology.”
No, sorry. I meant in user polish. Squeak/pharo for me are a mess. The code browser has a variety of inconsistent and frankly just too many menu options. So it becomes not just live code experiment, it becomes a live user interface experiment at the same time. This kind of thing leads to “too many experiments/agendas at the same time” effect (for me).
A few thoughts.
For better or worse (worse in the final analysis I guess), Smalltalk doubled down on an odd proposition. Instead of tools and compilers and language syntax/model being orthogonal/independent things, what could be leveraged if they were highly coupled? If you read the Byte article, and some of the other seminal Smalltalk papers you see this theme.
Smalltalk syntax really struggles outside of a Smalltalk environment. I tried GNU/Smalltalk and a couple of other “IDE-less” Smalltalk in VIM. I’m very comfortable worth VIM. It just didn’t scale well.
But it was a dream in a well done IDE. For the last 10 years, I do C(++), Elixir, Kotlin, Python, Swift/ObjC in a variety of VIM, PyCharm, VSCode, XCode, AndroidStudio, Eclipse, and QT Creator. The IDEs just don’t go as far at all here. The text editors are more modern, but the ability to work with (navigate, refactor) the code at a high level is nothing compared to what it was in some of the better Smalltalk IDEs. To date, no refactoring engine has approached the level that John Brant and Don Roberts did for the original refactoring browser. Unit Test integration at the code browser level existed before the other NUnits were even built. The Smalltalk debuggers were so cool. Interactive process/context inspector/manipulators would have been a better term.
I’ve theorized that the reason Smalltalk the language and Smalltalk the syntax could marry well is that they found a sweet spot in language complexity that made the IDE easy ish to implement and manipulate code, at a syntax level and at a code structs level. Smalltalk syntax existed really only at the method level. Smalltalk code structure was modeled in the “image” as a code database more than as a textual flattening.
It’s interesting how a paper dated 2000 might give the impression that some archeological find reveals while Smalltalk was not a success. I think that would be a misnomer. I was there. This sentiment was pretty common. “It’s too different” is a pretty timeless trope. All this paper shows, is that just like today, there is a small subset of computing enthusiasts that get excited about new/cool/different things, while the populist/conservative types push for things to mostly stay the same.
Smalltalk required a paradigm shift to appreciate. Most of us have limited resources. We don’t have time to explore every revolutionary paradigm shift; the ingress process is just too high.
I’m not trying to pitch Smalltalk paradigm shift as a worthwhile payment for what you got out of it. Those of us that paid the price to achieve the shift, appreciated what the difference was about, even if we’ve mostly moved on since then. Papers like this were a common “I don’t think the shift will be worth it” sentiment.