Hacker News Reader

Comment by mark_l_watson | Hacker News Reader

Nice, a new update. I remember playing with both small-js and Amber a longtime ago. Very cool projects but I am not a JavaScript developer so I always had friction using both projects so I settled on Pharo. Off topic: if you like long running image based development you can also get that with some lisps, for example, SBCL with frequently writing a new core image file - easy to do and good for applications where you have a massive amount of in-memory persistent data you work with.

View on HN

The workflow for long running lisp images is really unclear to me. It's so trivial for the code in the image to get out of sync with what's on disk.

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.

Could you say a bit more about your workflow? I'm used to having source code files open in emacs (or zemacs) and a lisp REPL in another buffer. I edit the source files directly and then recompile changes into the running lisp. The code stays in sync because the text code files are the master copy and the running image is updated (when I choose) to reflect changes. Program state (e.g., large data structures) isn't generally kept in the source files. If what's in memory needs to be preserved, then I need to have serialization and deserialization methods, or a database, or I need to save the running image to a snapshot file. I've probably so internalized this process that there are problems with it that are invisible to me.

So SmallJS works the same way. Update text files, press Run and the 'image' is updated in a second or 2. But it contains only code, not data. And I think that's a good thing..

The advantage to me was having persistent data in memory and stored in the image. I used a function ‘ll’ to reload all source code. I stopped using this technique when computers got faster so loading many data sources was not as consuming. Also, for my application I noticed that LispWork’s file IO ran much faster than SBCL so I used LW.

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.

You comment is more about LISP, but just to say that in SmallJS, you could write small command line utilities easily, that are started with the Node.js runtime quickly. And yes, the edit - recompile - run loop in SmallJS takes a second or two, so working from an image (with possible side effetcs) is not really necessary.

Reply on news.ycombinator.com