Hacker News Reader

Comment by scotty79 | Hacker News Reader

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.

View on HN

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.

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

Reply on news.ycombinator.com