Hacker News Reader

Comment by bradrn | Hacker News Reader

I did look at Amber before starting SmallJS. But having a full, separate IDE seemed nicer than a limited one in the browser. Amber itself has been stagnant for a few years now, alas.

But isn’t it sort of the whole point of Smalltalk that the IDE and the code run at the same time in the same place?

I would say the main point of Smalltalk that everything is an object, including basic types and also classes (reflection). That make everything so much simpler and more consistent. Having a 'live' IDE is nicely interactive, but it also has downsides, like a big image that stores side effects, bootstrapping issues when changing low-level stuff, and your program can break your IDE (corrupt the image), deploying an app is more complex because the image has to dangerously 'strip' itself of unneeded stuff. So as a 'compromise' SmallJS has a very quick change-compile-run cycle of about a second or two, without the downsides mentioned above.

I wanted to try Smalltalk earlier and discovered Pharo, but I found it to be just one huge antipattern as everything involved a single combined toolchain/IDE/runtime virtual machine image. Amber's documentation seems to have screenshots of the very same object inspector.

If I want to build a wooden chair, I don't want to start by learning to use a steel metal punch to create a panel saw first...

What exactly is the anti-pattern? Just that it is image based? There is Iceberg for exporting to git afaik. Haven't used it in depth though.

I think long lived state is the problem.

In Pharo your entire project along with its runtime, code, data and IDE is one long lived intertwined and dispersed state. I was never really sure if this is necessarily a problem or not.

But today I had an interesting idea. Pharo is Factorio of programming. You are evolving living, functioning system using itself. And we know most of Factorio games end up as ad-hoc tangled mess, where new things are added rather on the side than old things being properly refactored. So if your Factorio factories are always pristine examples of order you should be fine with Pharo. If not, you might be better off with something like PHP or Fermyon Spin which have app state living no longer than a single request-response. With long lived state neatly and separately held in the database and source files.

That's kind of solved with Iceberg and Metacello, they make it easy to just grab a base image and pull in what your system needs, no need to step through the change file and figure out where to file in the stuff you filed out when you broke things.

Though it's quite easy to make your application appear similar to a Factorio screen, since libraries like Roassal and Mondrian make it like a five to ten minute thing to create a custom visualisation of the involved packages. Static analysis tooling in other languages is usually not as malleable and easy to customise.

I worked on an application implemented in SmallTalk for about two and a half years, and having the IDE be in the application was honestly a huge force multiplier, at least for the kind of complicated desktop application we were making. Basically, it made development extremely smooth because you always had the application at your fingertips and while developing no matter what kind of error happened it would trap into the debugger so you could see what was going on. No more remembering to set breakpoints or running under a debugger or anything; just write code, test and get dropped straight in the debugger if something goes awry. In some cases we could even fix the bug, and retry the failing operation in-flight. To stretch the Factorio metaphor beyond the breaking point, I would even say that the image-based nature helped there to be less mess, because you no longer have to care about the organization of your code in the source files: you edit methods and classes, but the on-disk organization of the bits and pieces is no longer a concern.

Where the image-based system does cause trouble is when you need to interact with stuff outside of SmallTalk. It basically doesn't play very well with others (in particular stateful stuff like database connections which can't straightforwardly be persisted when the image is saved and closed). But overall, I found developing in SmallTalk to be extremely productive, even in the antiquated implementation we were working with.

If you see code itself as state… then isn’t any program long lived state.

Richard Gabriel made some statement to that effect in his 50 languages talk, the debate between Lisp and Smalltalk being “is code state or is state code?”, both circling the same drain.

How is a docker container not a modern realization, in part, of what both camps were yammering on about years ago?

Is this some variant of Lisp's 'everything is data is code' paradigm?

For metaprogramming, I think the ideas make a lot of sense. For bizapps in the 'real world', where the rubber meets the road, I think a division of data and action make a lot of sense. For example, on my last three or four business apps I started with data models (all of the persistent state) and walked backwards into the application.

I think -- I might be wrong -- in Scheme they have 'lambda uplift' or something like that to denote various levels of meta-programming "applied", IE, some level of abstraction is "applied" or "compiled" and the code is expanded.

More immediately Scheme, many Lisps and Lisp like languages as well as e.g. Elixir has quote and unquote, which easily allows one to flip between execution and data modes.

Lambda lifting is more of a compiler design technique.

The only thing persisting in a docker container is the filesystem, and that's only until the container is killed (not just stopped). Containers are generally meant to define an initial fs image and then be more or less ephemeral (`docker commit` being a thing virtually unseen in the wild). Smalltalk images persist the state of the whole runtime, typically automatically.

There's some overlap for sure, but I don't think one subsumes the other.

Yes. Code is the state of your project. You can't avoid it. But you can parcel it, keep it in different bucket, from other stuff. That's what source files are for.

Docker is neither smalltalk vm nor lisp. It's unholy pragmatic thing, when you have ton of state but you want to cram it all in a bucket so it doesn't crawl out.

> I think long lived state is the problem.

If we don't use a repeatable process that can be a problem.

So treat the long lived state as cache and check that does re-build from the versioned source code archive.

That’s the core of the smalltalk-80 design: that everything in the environment is an object you can send messages to, and the OS “doesn’t exist”

Having GUI tooling to inspect, debug and develop integrated in the execution environment is kind of Smalltalk's thing. It's like a Common Lisp with more clicking in that regard.

It's rather neat, and means you can extend your development environment in the same way you develop your applications. If you want to extend the inspector for a particular type of object you can do that. Compared to writing plugins for Eclipse or IntelliJ it's a trivial exercise.

GT does it too, though explicitly aimed at tool development rather than application development: https://gtoolkit.com/

In a sense it's the original vibe coding environment.

The Lisp everyonments that predated Common Lisp, like Interlisp-D[0] and the various Lisp Machines had the same amount of clicking.

Nowadays that experience is only visible in LispWorks and Allegro Common Lisp.

[0] - https://interlisp.org/

I mean, there is a reason people don't write Smalltalk anymore xD

Yes, Smalltalk was not free-as-in-beer and library code had vendor specific differences.

Reply on news.ycombinator.com