5 ms·

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 w

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.
- aquariusDue 3mo ago
  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 3mo ago
    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.

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.

aquariusDue 3mo ago
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 3mo ago
  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.