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...
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.
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.
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.
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?
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.
Lambda lifting is more of a compiler design technique.
There's some overlap for sure, but I don't think one subsumes the other.
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.
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.
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.
Nowadays that experience is only visible in LispWorks and Allegro Common Lisp.
[0] - https://interlisp.org/
Are there good tools that I'm overlooking for exploring the current image state? Smalltalk has that built-in but in CL I'm regularly loading my system into a fresh SBCL at least every couple days just because, at some point, some state is not what I expect it to be and I have no idea how to reconcile it.
Still, working with images in SBCL is a good technique. Command line utilities built as separate image files load very quickly, and then you get to write utilities in Lisp rather than bash or Python.
This project is nice, however if we don't have a specific, client-side IDE for interactive development, 70% of the power of Smalltalk is gone (one of the criticisms I give to Ruby)
How would one do to push changes to the web frontend (browser) without stopping the program ?
i would like the smalltalk code be loaded from files into the browser and interpreted/compiled there, without writing the resulting js back, but just running it in the browser.
dontlaugh•5mo ago
Why the Romanian flag?
amszmidt•5mo ago
Hasnep•5mo ago
amszmidt•5mo ago
From https://lists.squeakfoundation.org/pipermail/squeak-dev/1998...
whimsicalism•5mo ago
Smalltalker-80•5mo ago
imglorp•5mo ago
https://tashian.com/articles/dynamicland/byte-magazine-augus...