6 ms·

I've read the SBCL manual before, several times. It's not suitable for learning Lisp; it's written for people who already know Lisp but need an implementation-

by na85 6y ago

I've read the SBCL manual before, several times. It's not suitable for learning Lisp; it's written for people who already know Lisp but need an implementation-specific question answered. Let me illustrate: Suppose I want to compile my lisp code into an executable for easy deployment. My first step is opening the SBCL manual and reading the entire section on the compiler. There's nothing in there about how to actually invoke the compiler. Maybe there's a command line option. Read section 3 and find the "saving a core image" section. It has lots of verbiage about saving state to disk so that you can restart the program in the same state. But I don't want to restart in whatever garbled development state I'm currently in. I want the program to start in the initial state and progress normally, the way a program in just about any other language would naturally execute. I want execution to begin at the entry point (does Lisp even have "entry points"? There's another 5 hours of wasted time trying to figure that one out) and progress naturally like it does in literally any other language I can think of. By saving the current state how do I know I'm not introducing bugs due to some variable holding inadvertent state when I save-and-die? Okay so now I'm down the rabbit hole of stackoverflow and personal websites from random PhD computer science students at Carnegie Mellon from 2001 and about now is when I usually get frustrated, say "fuck it", and move on to a language like C# that actually has good documentation with copious examples (not to mention a library for just about everything), has an execution model that's actually easy to understand, and move on with my life. I say this as an aerospace engineer: I'm a smart guy but Lisp must be beyond my reach as a mere mortal without a computer science degree. I went through most of the Gigamonkeys book and while I can write a mean LOOP macro I can't actually do anything useful with lisp. The documentation is too confusing and too fragmented. I want to like Lisp but it fights me every step of the way.

reikonomusha 6y ago
You’re complicating to too much. You write a makefile to load your lisp code (which usually means loading your ASDF system), and dump the image (e.g., save-lisp-and-die). Development and deployment are separate in pretty much any language. Here is a real example from a real commercial project: Makefile: https://github.com/rigetti/quilc/blob/master/Makefile#L72 https://github.com/rigetti/quilc/blob/master/Makefile#L72 Build script: https://github.com/rigetti/quilc/blob/master/build-app.lisp https://github.com/rigetti/quilc/blob/master/build-app.lisp Everything you’ve seemed to use are completely free and open source solutions. Common Lisp has at least two major commercial options with excellent documentation which you’re looking for: LispWorks and Allegro CL.
Jach 6y ago
I guess I don't know what to say other than if you really want to learn Lisp, you have to meet it on its own terms. It's old, its heritage is older and always offered a different approach to the batch style of Fortran, it's not going to change for you. I hate this kind of wording because it makes it seem that Lisp is mysterious, or super difficult, or requires a ton of unlearning, or has no good (and free) learning material (you knock it but I enjoy Steele's 30 year old cltl2 mirrored on a CMU page), or is only for impractical purposes and CS-guilded programmers. I don't believe any of that, there are plenty of examples to the contrary. In contrast your own difficulties are puzzling. I hesitate to suggest reading, watching, or doing anything else, though things come to mind, simply to avoid wasting your time or money further if you took me up on any of it, as it might all be useless.
- na85 6y ago
  >It's old, its heritage is older and always offered a different approach to the batch style of Fortran, it's not going to change for you. I'm not asking for Lisp to change. I'm explaining why Lisp is hard to learn. >I hate this kind of wording because it makes it seem that Lisp is mysterious [...] or requires a ton of unlearning In my experience these things are 110% true. Even ASDF uses strange terminology completely divorced from modern usage. What are systems and modules, and how do they map to what every other language calls a package or a library? I have no idea. The "Getting Started with ASDF" page that was the top hit on Google works through an example where they define a Cow System that has legs, tail, head, etc. That's the usual example when talking about class inheritance... So are systems classes? What about CLOS? How the fuck do I get packaging in lisp? Again, here is where I usually give up. >In contrast your own difficulties are puzzling. Okay, well they're still the difficulties I'm hitting. I see lots of puzzlement on HN and elsewhere as to why Lisp isn't more popular than it is, and I honestly believe this is partly why. I have a busy job and soon to be a second child; I could spend my time trawling through powerpoint slides from MIT courses that took place in 2008 trying to find the answers, or I could brave the extremely caustic world of stackoverflow (no thanks, I deal with enough condescension already), or I could just give up and pick a different language and get up to speed faster and with less frustration. >I guess I don't know what to say other than if you really want to learn Lisp I guess I did want to learn Lisp, until I actually started trying to use it. The language itself seems awesome but the ecosystem around it, including the onboarding experience for non-graybeards, is pretty bad.
lispm 6y ago
1) start a fresh SBCL 2) LOAD your code 3) specify a toplevel function (aka 'entry point') and let it be executable -> SAVE-LISP-AND-DIE Result: a standalone executables which starts up with the toplevel function you have specified
kazinator 6y ago
> But I don't want to restart in whatever garbled development state I'm currently in. Right; the thing to is to start a completely new image, and the only thing you do in this image is load all of your compiled files, and then call the image-saving function. This was pretty obvious to me, coming from a C background. My first Lisp programs used Makefiles to do this stuff. You don't want to sit there and making deployed executables manually out of your dirty hacking session, of course. > I want execution to begin at the entry point Common Lisp implementations typically offer some image saving function, which has an argument for specifying something to be evaluated when that image is restarted, or a function to be called or some such. This general area is called "application delivery": you have to investigate the ways that your Lisp implementation offers application delivery. Saving an image might not be the only way; there may be a way to create an executable which isn't a saved image. In some Lisps, the hash-bang mechanism is supported, and that is appropriate in some situations. Some Lisps can produce shared library, even.

by na85 6y ago

reikonomusha 6y ago

You’re complicating to too much. You write a makefile to load your lisp code (which usually means loading your ASDF system), and dump the image (e.g., save-lisp-and-die). Development and deployment are separate in pretty much any language. Here is a real example from a real commercial project: Makefile: https://github.com/rigetti/quilc/blob/master/Makefile#L72 https://github.com/rigetti/quilc/blob/master/Makefile#L72 Build script: https://github.com/rigetti/quilc/blob/master/build-app.lisp https://github.com/rigetti/quilc/blob/master/build-app.lisp Everything you’ve seemed to use are completely free and open source solutions. Common Lisp has at least two major commercial options with excellent documentation which you’re looking for: LispWorks and Allegro CL.

Jach 6y ago

I guess I don't know what to say other than if you really want to learn Lisp, you have to meet it on its own terms. It's old, its heritage is older and always offered a different approach to the batch style of Fortran, it's not going to change for you. I hate this kind of wording because it makes it seem that Lisp is mysterious, or super difficult, or requires a ton of unlearning, or has no good (and free) learning material (you knock it but I enjoy Steele's 30 year old cltl2 mirrored on a CMU page), or is only for impractical purposes and CS-guilded programmers. I don't believe any of that, there are plenty of examples to the contrary. In contrast your own difficulties are puzzling. I hesitate to suggest reading, watching, or doing anything else, though things come to mind, simply to avoid wasting your time or money further if you took me up on any of it, as it might all be useless.

na85 6y ago
>It's old, its heritage is older and always offered a different approach to the batch style of Fortran, it's not going to change for you. I'm not asking for Lisp to change. I'm explaining why Lisp is hard to learn. >I hate this kind of wording because it makes it seem that Lisp is mysterious [...] or requires a ton of unlearning In my experience these things are 110% true. Even ASDF uses strange terminology completely divorced from modern usage. What are systems and modules, and how do they map to what every other language calls a package or a library? I have no idea. The "Getting Started with ASDF" page that was the top hit on Google works through an example where they define a Cow System that has legs, tail, head, etc. That's the usual example when talking about class inheritance... So are systems classes? What about CLOS? How the fuck do I get packaging in lisp? Again, here is where I usually give up. >In contrast your own difficulties are puzzling. Okay, well they're still the difficulties I'm hitting. I see lots of puzzlement on HN and elsewhere as to why Lisp isn't more popular than it is, and I honestly believe this is partly why. I have a busy job and soon to be a second child; I could spend my time trawling through powerpoint slides from MIT courses that took place in 2008 trying to find the answers, or I could brave the extremely caustic world of stackoverflow (no thanks, I deal with enough condescension already), or I could just give up and pick a different language and get up to speed faster and with less frustration. >I guess I don't know what to say other than if you really want to learn Lisp I guess I did want to learn Lisp, until I actually started trying to use it. The language itself seems awesome but the ecosystem around it, including the onboarding experience for non-graybeards, is pretty bad.

lispm 6y ago

1) start a fresh SBCL 2) LOAD your code 3) specify a toplevel function (aka 'entry point') and let it be executable -> SAVE-LISP-AND-DIE Result: a standalone executables which starts up with the toplevel function you have specified

kazinator 6y ago

> But I don't want to restart in whatever garbled development state I'm currently in. Right; the thing to is to start a completely new image, and the only thing you do in this image is load all of your compiled files, and then call the image-saving function. This was pretty obvious to me, coming from a C background. My first Lisp programs used Makefiles to do this stuff. You don't want to sit there and making deployed executables manually out of your dirty hacking session, of course. > I want execution to begin at the entry point Common Lisp implementations typically offer some image saving function, which has an argument for specifying something to be evaluated when that image is restarted, or a function to be called or some such. This general area is called "application delivery": you have to investigate the ways that your Lisp implementation offers application delivery. Saving an image might not be the only way; there may be a way to create an executable which isn't a saved image. In some Lisps, the hash-bang mechanism is supported, and that is appropriate in some situations. Some Lisps can produce shared library, even.