Hacker News Reader

> This power that Smalltalk systems have where the code runs in a GUI that is also the editor/debugger/etc has deeply fascinated me recently.

Have you tried emacs?

> And I'd like to actually understand a tool that I'd have to dive into that deeply, and I think I'll never have the time to truly understand all of the VM, the classes, etc.

I've recently tried to do that myself with Smalltalk via the Glamorous Toolkit[1] (a beautiful, modern Smalltalk environment based on Pharo). Because the programming environment itself comes with a Book teaching it, you can basically just read it as a normal digital book, but with the superpower that everything is editable and interactive: you can change the book itself, every code example is runnable and you can inspect the result objects right there, change it, modify the view for it... they say it's "moldable development" because you almost literally mold the environment as you write your code and learn about the platform.

> And I'd like to be able to create applications that run without shipping the entire Smalltalk VM.

That's why even though I really enjoyed SmallTalk, I can't really see it as anything more than a curiosity. I tried using it at least for my own occasional data exploration because it has good visualisation capabilities and super easy to use HTTP client/JSON parser etc., but the system is so heavy (1GB+ of RAM) that I couldn't justify keeping it open all the time like I do with emacs, on the offchance that I might need to use it for some small task.

Anyway, perhaps that's something you might be interested in.

[1] https://gtoolkit.com/

> Have you tried emacs?

Here we go ...

This isn't a vim vs emacs debate. We're talking about smalltalk and what do you know! emacs was made to resemble the big expensive lisp machines which were in turn made in the image of smalltalk but with lisp as the language of choice.

With this in mind, recommending emacs when someone states that they are interested in a system where the "code runs in a GUI that is also the editor/debugger/etc" does not seem out of place at all to me.

Pharo can also be recommended but its a lot more resource hungry and with a mouse centric workflow compared to emacs which is keyboard focused.

There are not just "lisp machines", but interactive Lisp implementations, coming with an IDE. The first of those were in the 60s, using text/terminal interfaces. The first Lisp already had interactive interface and end 60s "BBN Lisp" had a full-blown resident development environment, also using "images". In the 70s Smalltalk was developed (providing images, garbage collection, ... like Lisp before), then also on dedicated machines - at the same time frame Lisp was put onto these machines. BBN Lisp was then morphed Interlisp-D by Xerox, which was "Interlisp" ported to the Xerox D machines, running on the metal with a GUI added.

The Interlisp timeline gives an idea, that a lot of research into interactive development took place in the 60s and 70s, using it.

https://interlisp.org/history/timeline/

GNU Emacs is based on a Lisp system, but the focus was (is) to build an user-programmable, extensible editor, not to resemble a "lisp machine", which was a computer with an operating-system.

I wasn't commenting on Emacs vs Vim. My comment was regarding the meme-like nature of Emacs often being suggested for almost anything, almost "the Simpsons did it"-esque. My experience with Emacs is that it is a giant kluge, whereas Smalltalk and its kind are much more streamlined and simple. And Emacs is an editor driven and configured by a language. Smalltalk is a language that comes with an editor. They're different, and I don't think anyone is going to get a Smalltalk experience just working in Emacs.

> My experience with Emacs is that it is a giant kluge, whereas Smalltalk and its kind are much more streamlined and simple.

Yeah, and guess which one is *actually* widely used and still relevant today?

Neither, and for wildly different reasons.

This is correct. After trying out Smalltalk, I realised that Emacs has very much the same design: a minimal interpreted language which is used to implement a large program, where you can inspect and modify the program at any time. The major difference is that Emacs isn’t image-based.

I think this split is way overstated.

Consider the case where you fundamentally modify the invariants of an object. All you existing instances might now be in some inconsistent state. One way to avoid this is to enforce some unity of code and state. If we instead of modifying all the existing instances just modify instances created from this point forwards, we don't risk messing with the invariants.

Well now we have a standard unix model. The executables are "classes" that get "instantiated" (exec'd) into "instances" or processes.

As addedum, this experience was also available across the other Xerox PARC workstations, namely Interlisp-D, Mesa (XDE), Mesa/Cedar.

> And I'd like to be able to create applications that run without shipping the entire Smalltalk VM.

There's always a javascript vm... https://squeak.js.org/

Python notebooks such as https://marimo.io/ seems to provide many of the same benefits

> without shipping the entire Smalltalk VM

Are you OK shipping the entire JVM?