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).
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."
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.
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.
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 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 :)
