11 ms·

Interactive Common Lisp Development

118 points by billiob 3y ago

ngcc_hk 3y ago
Not sure what this for and what is it to do with interactive part of development. If you are vim people try search for vim and lisp and got there. emacs people obviously no need.
- dmpk2k 3y ago
  I find the content of the article far too detailed and interesting to warrant a dismissive comment.
  - ngcc_hk 3y ago
    If you look at the top post you can understand the disappointment when I click this link and got that. Yes there are a lot of content. Just the topic is …
    - brabel 3y ago
      For someone who knows Common Lisp but rarely plays with the redefinitions mentioned in the post, it's quite enlightening to learn those things. If you're not into Common Lisp you're definitely not the target audience for a post looking at the weird details of it like this one.
      - ngcc_hk 3y ago
        I am into it. And he has some more info. Just not here or there. For batch mode you can run script. Using format print :-). But in real life when you encounter problem the great thing of lisp is you can curl-c and inspect what is going on. I just doing my study of cl-6502 and found that this interactive nature and the readable of lisp is invaluable. For interactive mode you can do rely upon emacs (or ccl which I cannot use for look like a decade now due to sudden issue; finally resolve this using xaddr) or vim (google vim lisp lead you there) where you can load an image and then interactive with it. Why it stop here in my script? Just inspect around. Now this is somewhere possibly this article in the interactive mode to see how symbols, … etc might be useful. The problem I have (I just read it the third times trying my best to appreciate) is that it does not lead you to anywhere. If you do not know these the article does not help. If you do, it does not help much as it is not going deep enough. Perhaps an interactive session or information how interaction and use of this concept in a future article might be useful. By this article alone more is expected when one read that. Just in case I am definitely no better than him on lisp. I just expect to stand on another “giant” shoulder to learn more about this lisp approach. Sorry if I think it shortfalls a lot. Best regards and let us move on. Good days.
- vindarel 3y ago
  It is about the little things that might bite you during a long development session, like deleting a generic function in source but still having the function in the image, or the strategy to update existing object instances when a class definition is updated (and slots are modified, added or removed). --- btw, regarding packages and removing a symbol: uiop:define-package fixes the annoyance.
vindarel 3y ago
To really discover what interactive, image-based CL development is about, my pointers: - https://www.youtube.com/watch?v=jBBS4FeY7XM https://www.youtube.com/watch?v=jBBS4FeY7XM (5min) my demo to show how to resume execution of a long running program, from the stack frame right before the bug, after having fixed and recompiled the function, without quitting the debugger hence without stopping the program, thus without restarting everything from zero. - https://www.youtube.com/watch?v=nsKx40ab9SY https://www.youtube.com/watch?v=nsKx40ab9SY (20min)showing what saving and restoring an image does, differences between SBCL and LispWorks. - https://www.youtube.com/watch?v=1aboMZkNDCY https://www.youtube.com/watch?v=1aboMZkNDCY developing a 3D graphics software. - https://mikelevins.github.io/posts/2020-12-18-repl-driven/ https://mikelevins.github.io/posts/2020-12-18-repl-driven/ - debugging CL tools: https://lispcookbook.github.io/cl-cookbook/debugging.html https://lispcookbook.github.io/cl-cookbook/debugging.html - and no: while we could deploy a ball of mud to production, we can also not and use traditional tools and techniques: build an executable from scratch, restart the app, reload state. But we can do everything in between too (inspect the running app, change it a bit, change it a whole lot (while staying in sync with local source code), use images to speed-up development etc).
- pjmlp 3y ago
  The critic of shipping images in Common Lisp and Smalltalk is kind of ironic in the days of Docker and Kubernetes all over the place. Thanks for the links.
  - whartung 3y ago
    To a point. There's an entire culture of software and processes around building up container images from scratch for deployment. There's a term of art that I forget, "Pets vs XXX", with XXX being disposable VMs, in contrast to a Pet computer lovingly cared for over time. For many Common Lisp scenarios, it's actually similar -- start with the raw based image, load in your code and data, snapshot it, and ship the resulting artifact. At least for me, interactive development aside, it's not untoward to restart a CL system from scratch as a routine part of development. We're not running on Lisp Machines anymore where restarting was actually quite expensive (though there were anecdotes about how at some point it was faster to restart a LispM than let it grind through its GC process, I don't know about that). However, I don't know how common that is with Smalltalk. How often they restart from scratch. Saving the image is routine in Smalltalk. Where in Lisp you CAN save the image, it's not necessarily part and parcel operationally, historically, or culturally to constantly save the image, especially post LispM. In Smalltalk it is. I think with CL folk moreso build a new base image, load in some routine utilities, etc. to form a baseline. But application code and image are separate. Smalltalk, they're not. Code is part of the image (it's stored separately, but it's presented as if they're one and the same). So the image is a much more first class citizen in the Smalltalk world, rather than, perhaps, an artifact. Especially today, I imagine they have build processes that build up the entire thing again from scratch, but it would not surprise me if they bumped into problems where the image and the source code "don't quite match" that they have to suss out in testing before deployment, because something slipped through and tweaked the long saved image that wasn't properly captured. In any case, while I'm sure it doesn't quite happen like that today, its not unreasonable to have someone ship a "ball of mud" Smalltalk image in contrast to one in CL.
dusted 3y ago
After getting sbcl up with visual studio code and the alive extension, my mind was totally blown, I'm certain that emacs/slime is the true pure way, but for someone who's not wanting to learn emacs, alive is just pretty amazing and magic, and it fits well with what is described in the article. I wish I could do stuff like recompile functions in-place and just retry the call without exiting the process in every language in this way.
- reikonomusha 3y ago
  The IDE situation remains the #1 issue in adoption. Emacs+SLIME+Paredit (or variants) really are the best way to write Common Lisp, but it's also extremely unpalatable to someone who isn't willing to invest in not just a new language, but also an entirely new and extremely intricate editor stack. It's been my hope for well over a decade that the situation would change. Alive is decent, but has a long way to go before being a tool a professional could reasonably use.
  - whartung 3y ago
    Honestly this unreasonably scares people off. This apparently very large loo loo of a first step, setting up all this infrastructure just to get started. The tooling is nice, but it’s not what defines CL. The language has ample benefits just on its own. A paren matching editor is the minimum tooling necessary for CL. Auto indent is a nice to have. vi has had both for pushing 50 years now. The REPL is a standout feature of the system. Being able to load your code and poke at it is wonderful. Very powerful feature. Python has a REPL. I never felt it was very good, but that’s me. I never used it much. Perhaps I was missing something. I wrote a bunch of Python without ever using it. And I’d wager many coders have treated Python like they’d have treated Perl, or most any scripting language. Write code, save code, run script, rinse, repeat. With no interim step, turn around was fast and work got done. There is nothing stopping folks from doing the same with CL. I’ve developed 1000s of lines of CL with little more than 2 little defuns. (e) and (l). (e) fired off ‘vi code.lisp’ and (l) wrapped ‘(load “code.lisp”)’. My knowledge of the debugger was knowing how to abort it back to the top level. I mostly did “print” debugging. If I was clever, I’d write a ‘dprint’ function that would take variable arguments. If I was lazy, I’d just “(print ‘(“x=“ x “y=“ y))”. No big deal. Even when working with LispWorks (which has much to recommend it), I operated much like this. Reload all the code, dabble with the REPL, add print calls, reload, test individual functions. I never took the time to learn the higher level tooling and such. I didn’t feel it was necessary, and I’d rather code than fight tooling. So, as the Lisp cognoscenti stares on in mouth agape horror as I left much of the Lisp experience on the shelf, I got stuff done anyway. Which goes back to the fundamental point. CL is a language like any other. It’s a very cool language, very powerful, and worth using just for itself. Its environment does not define it as a language. It augments it, it’s cultural and useful to be sure, but you don’t necessarily need it to be capable and productive and to solve problems. If all the talk of tooling and what not deters you from trying the language, don’t let it. It’s worth trying all on its own. Try it your way, however you’re comfortable. But do get a parenthesis matching editor. Edit: just to highlight the point, if you read PGs “On Lisp” and “Common Lisp” books, you’ll notice they’re pretty much all about the language and its power. He does not talk much as I recall about the environment.
xenophonf 3y ago
The Alive extension for VS Code looks really awesome. Vindarel posted a tutorial here: https://lispcookbook.github.io/cl-cookbook/vscode-alive.html https://lispcookbook.github.io/cl-cookbook/vscode-alive.html
borissk 3y ago
Lisp is amazing. Interesting why Python won the race to become the language of choice for the neural networks wave of AI.
- kragen 3y ago
  well, if we categorize python and js as non-lisp languages, i'd say it's mostly because python has been the language of choice at google since last millennium, at least for situations where flexibility outweighs performance last millennium when google started up, no lisp was a good option. clojure didn't exist, schemes were mostly for teaching, cmucl was in disrepair, and though there were proprietary common lisps, they were proprietary and wanted per-cpu license fees, which would have meant disclosing how many cpus google had—a closely guarded secret moreover, common lisp's approach of putting a uniform but somewhat repulsive veneer over all operating systems was a pure drawback in google's all-linux environment, and s-expression syntax is harder to read than python's (if easier to edit) also the python community was friendly and welcoming, while the scheme community was tiny and fragmented, and the common lisp community had degenerated into an ego trip for a world-class asshole named erik naggum this is guessing from the outside; i've never worked at google, which is why i'm allowed to write this
  - throwaway123422 3y ago
    [flagged]
- FullGarden_S 3y ago
  Simple. Python had more hype than Lisp did when it mattered (partly because it was modern). So everyone boarded the hype train and here we are.
- IKantRead 3y ago
  As a huge Lisp/Scheme fan, I don't find it surprising that Python became the language of choice for neural networks over Lisp. NN in general just boil down to doing lots of linear algebra, which is a lot about mutating very large matrices. For this you really just want a wrapper around BLAS/LAPACK, so you can leverage existing optimized libraries. Working with matrices in Lisp always feels a bit clunky, and doubly so when you want to do a lot of stateful operations on them. The real compitetor in this space to Python is something like Matlab, which has probably the best interface for doing linear algebra (but is worse at everything else). The one area where Lisp and Python both shine is the ability to perform automatic differentiation. Lisps are great for this task since it's all symbolic manipulation. However, this is only important once you have a solid interface for working with matrices. If you want to get a feel for the difference I would suggest reading through the surprisingly excellent The Little Learner. I think you'll find that while it really demonstrates the power of Scheme (Racket in this case) in areas where it excels, you wouldn't want to use the framework in that book for anything other than toy examples.

118 points by billiob 3y ago

Not sure what this for and what is it to do with interactive part of development. If you are vim people try search for vim and lisp and got there. emacs people obviously no need.

dmpk2k 3y ago
I find the content of the article far too detailed and interesting to warrant a dismissive comment.
- ngcc_hk 3y ago
  If you look at the top post you can understand the disappointment when I click this link and got that. Yes there are a lot of content. Just the topic is …
  - brabel 3y ago
    For someone who knows Common Lisp but rarely plays with the redefinitions mentioned in the post, it's quite enlightening to learn those things. If you're not into Common Lisp you're definitely not the target audience for a post looking at the weird details of it like this one.
    - ngcc_hk 3y ago
      I am into it. And he has some more info. Just not here or there. For batch mode you can run script. Using format print :-). But in real life when you encounter problem the great thing of lisp is you can curl-c and inspect what is going on. I just doing my study of cl-6502 and found that this interactive nature and the readable of lisp is invaluable. For interactive mode you can do rely upon emacs (or ccl which I cannot use for look like a decade now due to sudden issue; finally resolve this using xaddr) or vim (google vim lisp lead you there) where you can load an image and then interactive with it. Why it stop here in my script? Just inspect around. Now this is somewhere possibly this article in the interactive mode to see how symbols, … etc might be useful. The problem I have (I just read it the third times trying my best to appreciate) is that it does not lead you to anywhere. If you do not know these the article does not help. If you do, it does not help much as it is not going deep enough. Perhaps an interactive session or information how interaction and use of this concept in a future article might be useful. By this article alone more is expected when one read that. Just in case I am definitely no better than him on lisp. I just expect to stand on another “giant” shoulder to learn more about this lisp approach. Sorry if I think it shortfalls a lot. Best regards and let us move on. Good days.
vindarel 3y ago
It is about the little things that might bite you during a long development session, like deleting a generic function in source but still having the function in the image, or the strategy to update existing object instances when a class definition is updated (and slots are modified, added or removed). --- btw, regarding packages and removing a symbol: uiop:define-package fixes the annoyance.

vindarel 3y ago

To really discover what interactive, image-based CL development is about, my pointers: - https://www.youtube.com/watch?v=jBBS4FeY7XM https://www.youtube.com/watch?v=jBBS4FeY7XM (5min) my demo to show how to resume execution of a long running program, from the stack frame right before the bug, after having fixed and recompiled the function, without quitting the debugger hence without stopping the program, thus without restarting everything from zero. - https://www.youtube.com/watch?v=nsKx40ab9SY https://www.youtube.com/watch?v=nsKx40ab9SY (20min)showing what saving and restoring an image does, differences between SBCL and LispWorks. - https://www.youtube.com/watch?v=1aboMZkNDCY https://www.youtube.com/watch?v=1aboMZkNDCY developing a 3D graphics software. - https://mikelevins.github.io/posts/2020-12-18-repl-driven/ https://mikelevins.github.io/posts/2020-12-18-repl-driven/ - debugging CL tools: https://lispcookbook.github.io/cl-cookbook/debugging.html https://lispcookbook.github.io/cl-cookbook/debugging.html - and no: while we could deploy a ball of mud to production, we can also not and use traditional tools and techniques: build an executable from scratch, restart the app, reload state. But we can do everything in between too (inspect the running app, change it a bit, change it a whole lot (while staying in sync with local source code), use images to speed-up development etc).

pjmlp 3y ago
The critic of shipping images in Common Lisp and Smalltalk is kind of ironic in the days of Docker and Kubernetes all over the place. Thanks for the links.
- whartung 3y ago
  To a point. There's an entire culture of software and processes around building up container images from scratch for deployment. There's a term of art that I forget, "Pets vs XXX", with XXX being disposable VMs, in contrast to a Pet computer lovingly cared for over time. For many Common Lisp scenarios, it's actually similar -- start with the raw based image, load in your code and data, snapshot it, and ship the resulting artifact. At least for me, interactive development aside, it's not untoward to restart a CL system from scratch as a routine part of development. We're not running on Lisp Machines anymore where restarting was actually quite expensive (though there were anecdotes about how at some point it was faster to restart a LispM than let it grind through its GC process, I don't know about that). However, I don't know how common that is with Smalltalk. How often they restart from scratch. Saving the image is routine in Smalltalk. Where in Lisp you CAN save the image, it's not necessarily part and parcel operationally, historically, or culturally to constantly save the image, especially post LispM. In Smalltalk it is. I think with CL folk moreso build a new base image, load in some routine utilities, etc. to form a baseline. But application code and image are separate. Smalltalk, they're not. Code is part of the image (it's stored separately, but it's presented as if they're one and the same). So the image is a much more first class citizen in the Smalltalk world, rather than, perhaps, an artifact. Especially today, I imagine they have build processes that build up the entire thing again from scratch, but it would not surprise me if they bumped into problems where the image and the source code "don't quite match" that they have to suss out in testing before deployment, because something slipped through and tweaked the long saved image that wasn't properly captured. In any case, while I'm sure it doesn't quite happen like that today, its not unreasonable to have someone ship a "ball of mud" Smalltalk image in contrast to one in CL.

dusted 3y ago

After getting sbcl up with visual studio code and the alive extension, my mind was totally blown, I'm certain that emacs/slime is the true pure way, but for someone who's not wanting to learn emacs, alive is just pretty amazing and magic, and it fits well with what is described in the article. I wish I could do stuff like recompile functions in-place and just retry the call without exiting the process in every language in this way.

reikonomusha 3y ago
The IDE situation remains the #1 issue in adoption. Emacs+SLIME+Paredit (or variants) really are the best way to write Common Lisp, but it's also extremely unpalatable to someone who isn't willing to invest in not just a new language, but also an entirely new and extremely intricate editor stack. It's been my hope for well over a decade that the situation would change. Alive is decent, but has a long way to go before being a tool a professional could reasonably use.
- whartung 3y ago
  Honestly this unreasonably scares people off. This apparently very large loo loo of a first step, setting up all this infrastructure just to get started. The tooling is nice, but it’s not what defines CL. The language has ample benefits just on its own. A paren matching editor is the minimum tooling necessary for CL. Auto indent is a nice to have. vi has had both for pushing 50 years now. The REPL is a standout feature of the system. Being able to load your code and poke at it is wonderful. Very powerful feature. Python has a REPL. I never felt it was very good, but that’s me. I never used it much. Perhaps I was missing something. I wrote a bunch of Python without ever using it. And I’d wager many coders have treated Python like they’d have treated Perl, or most any scripting language. Write code, save code, run script, rinse, repeat. With no interim step, turn around was fast and work got done. There is nothing stopping folks from doing the same with CL. I’ve developed 1000s of lines of CL with little more than 2 little defuns. (e) and (l). (e) fired off ‘vi code.lisp’ and (l) wrapped ‘(load “code.lisp”)’. My knowledge of the debugger was knowing how to abort it back to the top level. I mostly did “print” debugging. If I was clever, I’d write a ‘dprint’ function that would take variable arguments. If I was lazy, I’d just “(print ‘(“x=“ x “y=“ y))”. No big deal. Even when working with LispWorks (which has much to recommend it), I operated much like this. Reload all the code, dabble with the REPL, add print calls, reload, test individual functions. I never took the time to learn the higher level tooling and such. I didn’t feel it was necessary, and I’d rather code than fight tooling. So, as the Lisp cognoscenti stares on in mouth agape horror as I left much of the Lisp experience on the shelf, I got stuff done anyway. Which goes back to the fundamental point. CL is a language like any other. It’s a very cool language, very powerful, and worth using just for itself. Its environment does not define it as a language. It augments it, it’s cultural and useful to be sure, but you don’t necessarily need it to be capable and productive and to solve problems. If all the talk of tooling and what not deters you from trying the language, don’t let it. It’s worth trying all on its own. Try it your way, however you’re comfortable. But do get a parenthesis matching editor. Edit: just to highlight the point, if you read PGs “On Lisp” and “Common Lisp” books, you’ll notice they’re pretty much all about the language and its power. He does not talk much as I recall about the environment.

xenophonf 3y ago

The Alive extension for VS Code looks really awesome. Vindarel posted a tutorial here: https://lispcookbook.github.io/cl-cookbook/vscode-alive.html https://lispcookbook.github.io/cl-cookbook/vscode-alive.html

borissk 3y ago

Lisp is amazing. Interesting why Python won the race to become the language of choice for the neural networks wave of AI.

kragen 3y ago
well, if we categorize python and js as non-lisp languages, i'd say it's mostly because python has been the language of choice at google since last millennium, at least for situations where flexibility outweighs performance last millennium when google started up, no lisp was a good option. clojure didn't exist, schemes were mostly for teaching, cmucl was in disrepair, and though there were proprietary common lisps, they were proprietary and wanted per-cpu license fees, which would have meant disclosing how many cpus google had—a closely guarded secret moreover, common lisp's approach of putting a uniform but somewhat repulsive veneer over all operating systems was a pure drawback in google's all-linux environment, and s-expression syntax is harder to read than python's (if easier to edit) also the python community was friendly and welcoming, while the scheme community was tiny and fragmented, and the common lisp community had degenerated into an ego trip for a world-class asshole named erik naggum this is guessing from the outside; i've never worked at google, which is why i'm allowed to write this
- throwaway123422 3y ago
  [flagged]
FullGarden_S 3y ago
Simple. Python had more hype than Lisp did when it mattered (partly because it was modern). So everyone boarded the hype train and here we are.
IKantRead 3y ago
As a huge Lisp/Scheme fan, I don't find it surprising that Python became the language of choice for neural networks over Lisp. NN in general just boil down to doing lots of linear algebra, which is a lot about mutating very large matrices. For this you really just want a wrapper around BLAS/LAPACK, so you can leverage existing optimized libraries. Working with matrices in Lisp always feels a bit clunky, and doubly so when you want to do a lot of stateful operations on them. The real compitetor in this space to Python is something like Matlab, which has probably the best interface for doing linear algebra (but is worse at everything else). The one area where Lisp and Python both shine is the ability to perform automatic differentiation. Lisps are great for this task since it's all symbolic manipulation. However, this is only important once you have a solid interface for working with matrices. If you want to get a feel for the difference I would suggest reading through the surprisingly excellent The Little Learner. I think you'll find that while it really demonstrates the power of Scheme (Racket in this case) in areas where it excels, you wouldn't want to use the framework in that book for anything other than toy examples.