4 ms·

I find lisp really hard to learn. I don't mean the syntax, or the concept of macros (though I'm sure my understanding of macros is incomplete) but what I find

by na85 6y ago

I find lisp really hard to learn. I don't mean the syntax, or the concept of macros (though I'm sure my understanding of macros is incomplete) but what I find is lacking in the documentation is how one actually might use lisp. I read stories about "connecting to" a "running lisp" on a space probe and debugging in real time. Does that mean some lisp implementations listen on a tcp port? How does one actually connect to or disconnect from a repl? Is it just that when NASA launched their probe, someone went in on ssh and moved the process to the background with C-z? How does one deploy a lisp application? Can I compile my code into an executable with, say, sbcl which is what everyone seems to use? Or am I forced to rsync all my source code to my server and get e.g. systemd to manually invoke an entry point?

desine 6y ago
I'm new to Lisp, having started SICP last month, but I can answer some. The space probes are probably just a standard serial port (RS-232 style UART), with some radio protocol that has good error correction/stability. In amateur radio, FT-8 is a slow, reliable, long distance serial protocol often used for hobbyist DX (long distance goal) communication. So likely, yes, they have a minimal shell or REPL-style debugger, where they can at least query variables, and change the machine state. Most aerospace devices use single-user Real Time Operating Systems, which have guaranteed timing on programs running, but to a technician end-user, the feeling is similar to an old Unix system, with similar tool names. You can deploy via compilation, with SBCL, or LLVM, etc. But I've mostly seen Lisp (well, I'm looking at Schemes, specifically) extending a compiled app. It's been pretty trivial connecting Racket to my compiled C functions, and I'll try Guile later, and for me it's mostly been a rapid-development tool to work with my WIP C library.
Jach 6y ago
SBCL has a manual, your main questions are answered in it: http://www.sbcl.org/manual/ http://www.sbcl.org/manual/ Under the dev-tools/editor section you'll see slime mentioned. It too has a manual: https://www.common-lisp.net/project/slime/doc/html/ https://www.common-lisp.net/project/slime/doc/html/ It's common to use slime with emacs, but vim and atom work too. Slime includes a lisp program called swank which sets up a simple server that clients like emacs can open a socket to. In Common Lisp, "compile", "eval", "load", "break", etc. are built-in functions. Lisp programs are 'alive' and can be constructed or debugged and updated by compiling and executing bit by bit without having to suspend or restart the process, using the socket to communicate how to grow. Some examples are in this several part series you can take 10 mins to browse through: https://malisper.me/debugging-lisp-part-1-recompilation/ https://malisper.me/debugging-lisp-part-1-recompilation/ Going beyond that into say developing a full application with version pinning of dependencies and tests is documented in books/in pieces on the web (CL cookbook has a lot). But manuals tell a lot too. Under SBCL's Saving a Core Image, you can see a standalone executable can be made with save-lisp-and-die. But you can also load things with --script if you want a python or node like experience.
- 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.

by na85 6y ago

desine 6y ago

I'm new to Lisp, having started SICP last month, but I can answer some. The space probes are probably just a standard serial port (RS-232 style UART), with some radio protocol that has good error correction/stability. In amateur radio, FT-8 is a slow, reliable, long distance serial protocol often used for hobbyist DX (long distance goal) communication. So likely, yes, they have a minimal shell or REPL-style debugger, where they can at least query variables, and change the machine state. Most aerospace devices use single-user Real Time Operating Systems, which have guaranteed timing on programs running, but to a technician end-user, the feeling is similar to an old Unix system, with similar tool names. You can deploy via compilation, with SBCL, or LLVM, etc. But I've mostly seen Lisp (well, I'm looking at Schemes, specifically) extending a compiled app. It's been pretty trivial connecting Racket to my compiled C functions, and I'll try Guile later, and for me it's mostly been a rapid-development tool to work with my WIP C library.

Jach 6y ago

SBCL has a manual, your main questions are answered in it: http://www.sbcl.org/manual/ http://www.sbcl.org/manual/ Under the dev-tools/editor section you'll see slime mentioned. It too has a manual: https://www.common-lisp.net/project/slime/doc/html/ https://www.common-lisp.net/project/slime/doc/html/ It's common to use slime with emacs, but vim and atom work too. Slime includes a lisp program called swank which sets up a simple server that clients like emacs can open a socket to. In Common Lisp, "compile", "eval", "load", "break", etc. are built-in functions. Lisp programs are 'alive' and can be constructed or debugged and updated by compiling and executing bit by bit without having to suspend or restart the process, using the socket to communicate how to grow. Some examples are in this several part series you can take 10 mins to browse through: https://malisper.me/debugging-lisp-part-1-recompilation/ https://malisper.me/debugging-lisp-part-1-recompilation/ Going beyond that into say developing a full application with version pinning of dependencies and tests is documented in books/in pieces on the web (CL cookbook has a lot). But manuals tell a lot too. Under SBCL's Saving a Core Image, you can see a standalone executable can be made with save-lisp-and-die. But you can also load things with --script if you want a python or node like experience.

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.