[Barrin92]

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/ 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

[Jtsummers]

> 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.

[scroot]

> 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]

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.

[miki123211]

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]

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]

> 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.

[aquariusDue]

I follow GToolkit from time to time but each and every time I'm a little disappointed there's no code editor with LSP integration like Emacs has major modes for programming. I (think I) understand where they're coming from that GToolkit should be used to build tools to inspect and analyze your codebase and problem domain but I feel that it's such a heavy investment to make (kinda like Emacs) and I don't receive that last bit of payoff of being able to create in it too.

Please correct me if I'm wrong and things changed in the meantime. I really want GToolkit to be a complete IDE.

Until then I'll wistfully watch from the sidelines, dipping my toe in from time to time.

[klibertp]

EDIT: Argh, I misunderstood your point: you'd like to use GT as an IDE for non-Smalltalk code, right? I took "LSP integration" to mean "GT providing LSP server implementation", while you meant "GT implementing an LSP client", I think.

That's not something I ever thought I needed, though there is some support for syntax highlighting for JavaScript and Python, I think. I don't think GT is supposed to be a general-purpose, polyglot IDE: it's a bit more specialized than that, IIUC.

I'm leaving the off-topic rant below; it's a bit too long to just delete :(

> Please correct me if I'm wrong and things changed in the meantime.

Sadly, you're not wrong, and as an Emacs user (since 2012) myself, I share your reservations. The text editing widgets in GToolkit are usable, but nowhere near what you get in Emacs. Multiple cursors, iedit, re-builder/visual-regex, editable occur, AST-based editing (paredit/combobulate) are just some of the features I use regularly in Emacs which are (and will be, for a long time) missing in GT. On the flip side, rich formatting, inline images, and interactive widgets are way easier to implement in GT than in Emacs, and Lepiter is a good alternative to Org.

The conventional answer to that is that you shouldn't need those more advanced editing features when working with Smalltalk: the method bodies should be short, you should be using refactoring commands instead of hand-editing code in many places at once, and you should just auto-format after each edit. Even if it's not technically incorrect, I don't like that answer. Because this is the Smalltalkers' mindset (on average), things like LSP implementation (or other support) for external editors[1] never gained traction.

Without writing an $EDITOR-GT wiring yourself, the best you can currently do is some level of external integration. You can add a context menu option like "Edit in Emacs" in GT that will run emacsclient on a temporary file with the method body dumped. It's obviously underwhelming: you have either a powerful editor (Emacs), or a smart editor (GT), and you have to deal with two completely different UIs. Yes, it's bad. It's still better than trying to use just GT for all editing, though.

I ended up structuring my GT project a bit like a Web app. The sources on disk are a source of truth, and coding agents work with them. I have scripts that load the Git repo into a fresh image and either run the tests, run a one-time eval, or open the GT GUI (equivalent of loading a page and opening DevTools in the browser). In GT, I have an Emacs escape hatch for editing, and I use the Git tool to export any changes back to disk. So far, it works OK, though it's closer to how you work with Common Lisp images than traditional Smalltalk "100% in-image" development. It's not ideal, but it allows me to leverage GT while still integrating other tools into the project.

[1] There were attempts in the past; for Emacs, somebody wrote a frontend to Smalltalks called `shampoo`. It's been 14 years since the last commit.

[aquariusDue]

Yep, I'd like to use GT as an IDE for non-Smalltalk code like I currently use Emacs though the off-topic rant is very welcome too and I thank you for it!

Regarding the point of Lepiter vs Org I gave GT another go after I posted my comment and I realized that with the power of "adornments" (which you've mentioned) and so on Lepiter can be more flexible than Org files in a way (though the HTML export seems to ignore outlines currently). If I understood correctly there's nothing preventing you from mixing blocks of Markdown and Org (if Org was implemented) with other custom made blocks (like a snippet of code, chart or view of a GitHub repo). In that regard Lepiter (and GT by extension) seems immensely powerful even if I can't summon spell-checking willy-nilly like I can in Emacs regardless of org-mode or dart-mode for example.

Also there seem to be official examples which I didn't see last time that hint about the possibility of implementing text editors and potentially code editors with LSP integration.

https://book.gtoolkit.com/controlling-completion-in-a-text-e...

https://book.gtoolkit.com/editing-python-sources-through-the...

[klibertp]

> In that regard Lepiter (and GT by extension) seems immensely powerful

Yes - I think this all comes from the insistence on using a single rendering tree for everything displayed on screen. It allows mixing all kinds of UI elements everywhere, including nesting of arbitrary widgets inside a text field (and arbitrary text inside any other widget). It's a genuinely powerful model for UI composition :)

> I can't summon spell-checking willy-nilly like I can in Emacs

Yes, that's why I mentioned "features I use regularly in Emacs which are (and will be, for a long time) missing in GT" - it's not that you can't build them; they just need to be built, and with how few developers work on GT, it'll take ages before GT Coder gets those features.

It doesn't help that GT editors seem a bit less ad hoc scriptable than Emacs. I'm not sure why this seems to be the case for me - I suspect the need to structure everything as classes and methods adds non-trivial cognitive overhead for simple scripting. At least compared to the pretty flat, procedural shape of typical Elisp code. Then again, I did not invest enough time into learning how to customize GT's editors, so it might be a shallow impression that would go away with time.

> Also there seem to be official examples

Oh, nice, thanks, I missed that. I mean, it's obviously possible to implement an LSP client for GT, but I didn't know one existed. I'm especially interested in how that is integrated into Coder, since it should be able to provide a lot of functionality that I'd also want to script in my custom Coder instances.