Hacker News Reader

Comment by ilrwbwrkhv | Hacker News Reader

I still haven't found an environment which lets you build the system as seamlessly as SBCL. The REPL allows you to build the code at runtime and update the system in place. Since I was a solodev, bug fixing and building the thing without going on the wrong path was worth I think months and years of my time.

edit: Once you get the idea of a running Lisp image and you are updating the image it's a game changer. You are not writing a program, then compiling it and then running it anymore (even though those steps happen seamlessly).

View on HN

> image and you are updating the image it's a game changer.

Also Smalltalk.

https://lists.cuis.st/mailman/archives/cuis-dev/2023-August/...

Also Factor.

https://factorcode.org/

Not obvious to me that it provides the same experience: "The image is a map of the memory after the code was loaded. Unlike in Smalltalk, Factor code is always distributed in files rather than in the image."

https://concatenative.org/wiki/view/Factor/FAQ/Install

Factor provides support for both file and image based workflows. Factor is image-based and uses files when sharing, loading or refreshing vocabularies. however, just like lisp and Smalltalk, you can also save, share and restore system state via an image. For example you can save the whole state of Factor with the word

save-image

and you can restore that image using ./factor -i=path-to-image

This image workflow and interaction via the inspector provides a very similar workflow experience to both Smalltalk and Common Lisp.

It's likely to be more obvious if you tried it out.

Same here. It is just really annoying to me (ymmv etc etc) to use another env: it just is so much harder to inspect everything, debug easy and still end up with a really fast system because of sbcl.

What about state belonging to the older code, updating http handlers, user sessions, etc, on production? While living-in-the-image seems admirable, I always wondered how it blends with real production and real ops.

The only thing I heard about this is Paul Graham's story on fixing particular bug in viaweb while talking to the user, but that's just one story from 90s. Would be great to hear more with regard to more modern setup.

So a jupyter notebook is just a bad lisp repl

Not sure if I'm up to date, but jupyter (as good as it is) suffered from strange rules of evaluations for cells which makes it difficult to do anything large since side effects will impede thinking quick.

In my opinion it’s indeed like Greenspun’s 10th rule; it’s a vague imitation. If people weren’t so squeamish about parans the world would be a nicer place. The tech is there for a long time already.

I love lisp. I love the stability, the macros, the crash handlers, the repls, the elitism, slime, emacs, the works. But IMO sexpr is straight out terrible and hacking around that is a chore.

I suspect most of the power that you already _love_ flows from the sexp based homoiconic syntax :-)

I tried to convince myself of that, but putting a function/operator in the same parens as the arguments and then making a special case for the first element in the parens will never make sense to me, since you can get the "expressive power" in any number of ways. Ruby makes more sense.

Yeah, it's interesting. I find them elegant and want all my languages to have that syntax (no deviation either like [] for lists etc). Guess we cannot argue about taste :)

This is what the lisp repl is like. There's not much else like it: https://www.youtube.com/watch?v=_B_4vhsmRRI

PS: You can also do copy and paste :)

Reply on news.ycombinator.com