2 ms·

Some more stuff: 1. The condition system including restarts to recover from errors. 2. A uniform syntax that can be fluently manipulated with paredit-style mo

by mbrock 10y ago

Some more stuff: 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...

aidenn0 10y ago
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.
- mbrock 10y ago
  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.
  - aidenn0 10y ago
    Have you read any of the XCVB papers? They dig deeper into the issues with generating reproducible images, in particular with parallel builds.

by mbrock 10y ago

aidenn0 10y ago

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.

mbrock 10y ago
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.
- aidenn0 10y ago
  Have you read any of the XCVB papers? They dig deeper into the issues with generating reproducible images, in particular with parallel builds.