Re:Lisp: it's not about macros, it's about READ (2012)
by aidenn0 on Tuesday July 19, 2016 @10:55PM
(#12126559)
I think VM image saving/loading is still debatable as to whether or not it's good, assuming that it's the primary way of generating a binary image, as it is in most lisps.
A lot more work has to go into guaranteeing reproducible builds, and it tends to be a fairly non-compact representation of your executable. If CL were a little bit less customizable at load-time, that would allow for much faster FASL loading, which in turn would make the reliance on saved-images less important.
Obviously there are uses for that feature, and having a feature doesn't by itself make a language worse, but when that feature is a square-peg, but still the best fit for a particular round-hole, it causes problems.
Re:Lisp: it's not about macros, it's about READ (2012)
by mbrock on Wednesday July 20, 2016 @11:33AM
(#12129806)
I found it pretty easy to generate images in a reproducible way: just load your packages, run whatever setup you want, then save the image. Compactness hasn't been a problem for me but I suppose it could be. Admittedly I don't have much real experience with deploying Lisp applications in any serious way; I'm curious about what problems people run into.
1. The condition system including restarts to recover from errors.
2. A uniform syntax that can be fluently manipulated with paredit-style modes.
3. VM image saving/loading.
4. Runtime access to the compiler and very complete reflection.
5. A package system (ASDF) that lets you dynamically recompile and reload an entire system with all its dependencies just by calling a function.
6. First-class namespaces.
7. Well-defined multiple dispatch.
8. Metaobject protocol.
9. Language specification with conceptual clarity.
10. High-quality optimizing compilation despite extreme dynamicity.
I think the list could go on for a while...