5 ms·

I genuinely do wonder why that has been the trajectory. When you look at the almost futuristic vision of interacting with living, programmable software objects

I genuinely do wonder why that has been the trajectory. When you look at the almost futuristic vision of interacting with living, programmable software objects and environments that evolve over time and you get a glimpse of it in Emacs, Pharo or Oberon (worth mentioning Free Oberon, fun to play around with https://free.oberon.org/en/ https://free.oberon.org/en/ think it was on the frontpage recently), how did we go back to dead text files again? I always have to think the "the world if" meme when I think about what would have happened if the whole Engelbart, Licklider, Alan Kay school of thought had won out

scroot 3mo ago
> I genuinely do wonder why that has been the trajectory. The simple answer here is still likely the best one: Smalltalk and Lisp Machine systems were expensive and proprietary right at the same time that Unix and C became free (and therefore ran everywhere)
- pjmlp 3mo ago
  Yes, and porting them on top of UNIX wasn't the same thing, while still being commercial. Even with commercial UNIXes, it was extra on top of standard UNIX developer SKU. Same with Ada, by the way.
Jtsummers 3mo ago
> how did we go back to dead text files again? We never went away from it. It's how a significant amount of computer use has always been. Smalltalk, Oberon, Lisp Machines (mentioned by sibling), they were always minority systems. There was a brief time when maybe home computers could have leaned this way, but that lasted until VisiCalc. What sold computers was software that turned them from clay to be molded by the user into a defined tool. People prefer appliances (or were convinced to prefer appliances), and appliances make more money for businesses than distributing programs as a Smalltalk package would have.
miki123211 3mo ago
The Smalltalk approach doesn't really integrate well with anything else. If you treat data and code the same, it's hard to separate code from data. If you're writing a program for a single machine on which it should be used, that's fine, but if you want to write your code once and run it across many machines, that's a problem. ERP systems are a bit like this; system owners (businesses) are often able to change any part of the system they want. Predictably, this makes version upgrades an incredible pain and often locks companies into an unsupported proprietary fork of a 20-year-old version of their CRM.
- pjmlp 3mo ago
  There are image distribution ways, and already on the 1990's there was image based SCM products. Most of those ERP systems are a pain, because all those changes where spread across several contractors, each doing their own little silo while keeping everything else running. SaaS products are basically the Smalltalk approach, and they aren't going away, in fact they are doubling down with iPaaS and AI agentic tooling. In such business domains, classical backend coding is almost gone, what is left are serverless, microservices, many of which are slowly being exposed as MCP tools.
- klibertp 3mo ago
  > The Smalltalk approach doesn't really integrate well with anything else. That's not true. GToolkit (built on Pharo Smalltalk) integrates tightly with Git for VCS and Rust via FFI for external libraries. It integrates with external Python and JavaScript through IPC. The same IPC mechanism is used to work around the GIL (the same way Python used to do with the multiprocessing library). Squeak descendants are also not the only Smalltalks available. Smalltalk/X is polyglot, supports Java and C code inline, and has a native AOT compiler (through C). Smalltalk/X and VisualWorks have built-in version control, namespaces, and packages with visibility modifiers. TL;DR: a live Smalltalk environment doesn't have to be an isolated island. The most popular open-source Smalltalks come from education and hobbyist coding, so they tend to miss a lot of "programming in the large" conveniences, but that's just a historical accident. There's no technical reason why a Smalltalk that's integrated into a wider ecosystem and suited for large teams couldn't exist.

scroot 3mo ago

> I genuinely do wonder why that has been the trajectory. The simple answer here is still likely the best one: Smalltalk and Lisp Machine systems were expensive and proprietary right at the same time that Unix and C became free (and therefore ran everywhere)

pjmlp 3mo ago
Yes, and porting them on top of UNIX wasn't the same thing, while still being commercial. Even with commercial UNIXes, it was extra on top of standard UNIX developer SKU. Same with Ada, by the way.

Jtsummers 3mo ago

> how did we go back to dead text files again? We never went away from it. It's how a significant amount of computer use has always been. Smalltalk, Oberon, Lisp Machines (mentioned by sibling), they were always minority systems. There was a brief time when maybe home computers could have leaned this way, but that lasted until VisiCalc. What sold computers was software that turned them from clay to be molded by the user into a defined tool. People prefer appliances (or were convinced to prefer appliances), and appliances make more money for businesses than distributing programs as a Smalltalk package would have.

miki123211 3mo ago

The Smalltalk approach doesn't really integrate well with anything else. If you treat data and code the same, it's hard to separate code from data. If you're writing a program for a single machine on which it should be used, that's fine, but if you want to write your code once and run it across many machines, that's a problem. ERP systems are a bit like this; system owners (businesses) are often able to change any part of the system they want. Predictably, this makes version upgrades an incredible pain and often locks companies into an unsupported proprietary fork of a 20-year-old version of their CRM.

pjmlp 3mo ago
There are image distribution ways, and already on the 1990's there was image based SCM products. Most of those ERP systems are a pain, because all those changes where spread across several contractors, each doing their own little silo while keeping everything else running. SaaS products are basically the Smalltalk approach, and they aren't going away, in fact they are doubling down with iPaaS and AI agentic tooling. In such business domains, classical backend coding is almost gone, what is left are serverless, microservices, many of which are slowly being exposed as MCP tools.
klibertp 3mo ago
> The Smalltalk approach doesn't really integrate well with anything else. That's not true. GToolkit (built on Pharo Smalltalk) integrates tightly with Git for VCS and Rust via FFI for external libraries. It integrates with external Python and JavaScript through IPC. The same IPC mechanism is used to work around the GIL (the same way Python used to do with the multiprocessing library). Squeak descendants are also not the only Smalltalks available. Smalltalk/X is polyglot, supports Java and C code inline, and has a native AOT compiler (through C). Smalltalk/X and VisualWorks have built-in version control, namespaces, and packages with visibility modifiers. TL;DR: a live Smalltalk environment doesn't have to be an isolated island. The most popular open-source Smalltalks come from education and hobbyist coding, so they tend to miss a lot of "programming in the large" conveniences, but that's just a historical accident. There's no technical reason why a Smalltalk that's integrated into a wider ecosystem and suited for large teams couldn't exist.