I'd claim that Smalltalk is mostly code-as-data and code-as-executable. Only methods (the leaves of the code tree) are manipulated as text in a typical Smalltalk system. And even those leaves are also accessible to code-as-data tools in modern Smalltalks (e.g. Squeak and Pharo). For example, I can rename slots (instance variables) across all methods of a class as a single operation. I can also search for all methods in the system that contain a specific literal, or send a specific message. Recent versions of Glamorous Toolkit (a layer on top of Pharo that completely replaces the UI) add refactoring tools that let me do system-wide find-and-replace using patterns in the AST. I find code-as-data-with-text-at-the-leaves a very nice mix of code representations. Text is great at fine granularity levels. It sucks for the big picture.

Good point. I really should dig into Smalltalk. Why hasn't it taken the programming world by storm compared to popular languages with compilers and devtools that have all the the "code as static text in 80 char wide terminals" problems that @Jack Rusher called out recently at StrangeLoop?

Smalltalk, during the period in which it was popular, had serious drawbacks around modularity, security, and compatibility with existing systems.

Think of how Windows is known for cruft accumulating in the registry or whatever. Now imagine that for the whole system. The advantage of isolated short-lived processes is that you get a fresh start when they crash.

The transition from "Smalltalk as an OS", with the problems pointed to by @Jack Rusher and @wtaysom, to "Smalltalk as a subsystem running inside an OS" (Squeak, Pharo, several commercial implementations) has made a big difference. Perhaps today, Smalltalk's biggest problem is smallness. The developer communities behind the currently most visible implementations (Pharo, Squeak, Cuis) are ridiculously small compared to other languages and IDEs. The systems themselves are not very visible, and "everyone" knows very very well that "Smalltalk is dead". On the other hand, what these small communities achieve is impressive. My current main work environment, Glamorous Toolkit, is developed by a consulting company of eleven people as a side project. They have built a complete new graphical stack, all in Smalltalk, building on Skia as a base layer. They have also built an innovative UI framework (again, all in Smalltalk) on top of that. All that is still beta quality, but it's usable, not a mere prototype.

Let me add that there is no fundamental problem with Smalltalk, not in this century. That things like the Glamorous Toolkit can keep up with so little attention should tell us something.

@Jim Meyer For some more historical context consider http://wirfs-brock.com/allen/posts/914 and https://gbracha.blogspot.com/2020/05/bits-of-history-words-of-advice.html. Essentially, Smalltalk was killed in the 90s by Java and the Web, while also being expensive and slow. Even today, tools like GToolkit are tied to the desktop way of software, while general computing moves more and more to the Web. As a language released almost 40 years ago, Smalltalk lacks features found in newer dynamic languages, like first-class map/dicts and optional typing, and has different names for common classes/methods. Perhaps there is another world where Smalltalk won in the 90s and Java didn't sour the programming world on OOP, but in this world Smalltalk, like Lisp, lives on in a tiny community of the devoted.

@Riley Stewart Good reads, thanks! This one cuts to the core I think:

Pay a lot of money to be locked in to slow software that exposes your IP, looks weird on screen and cannot interact well with anything else; it is much easier to maintain and develop though!

@Riley Stewart That's part of the story, of course, but not what I find most interesting. Smalltalk as a language stopped evolving, and thus didn't acquire features that we associate with modern dynamic languages today. But what was really lost is Smalltalk the system. The live-coding environment with integrated tools. Code as a database. The rise of Java is probably part of that explanation, but I suspect it is more a symptom than a cause. Traditional compiler toolchains were probably a better fit for "enterprise computing", where it's not individual productivity that counts but the existence of a job market for a workforce. From my perspective as someone who has used many dynamic languages (e.g. APL, Lisp, Python, Smalltalk), Smalltalk the language is uninteresting and has clear deficiencies. But for the work I am doing, I find that the easily extensible live-coding environment more than makes up for that.

Another amusing explanation of what happened to Smalltalk, presented as a counterfactual: