To really discover what interactive, image-based CL development is about, my pointers:
- 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.
- 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).
> 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).
Is anyone aware of SBCL or LispWorks-based tooling that integrates with ServiceNow CHG records to record and perform these kinds of changes to automatically create an audit trail of such changes in a CHG record as the Lisp image is manipulated for emergency changes?
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.
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.
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.
My understanding is that enough time had passed between the AI winter of the late 1980s and the rise of big data and deep neural networks in the 2010s to where a relatively tiny minority of modern machine learning practitioners came from the old-school AI community, which tended to prefer Lisp or Prolog. When machine learning became hot in the past 15 years or so, many new entrants to ML who had no previous AI knowledge used the tools they’re familiar with, which are generally C, C++, Java, JavaScript, and Python. In addition, many in the natural sciences use Fortran and Matlab. Perhaps had the AI winter of the late 1980s not happened (which took out the Lisp machine market) and had Common Lisp not been relegated to certain niches, perhaps there would’ve been more usage of the language, which may have led to Python being less dominant today.
I love Lisp and Smalltalk, but I work as a machine learning researcher as my day job, and I code in Python at work. Admittedly I miss Common Lisp whenever I code in Python, and I think Jupyter notebooks are a poor man’s Smalltalk environment, but when comparing Python to C and C++ (and I used to work primarily in systems programming, so I know my way around C), Python is a major productivity boost.
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
I like that you're framing this as if it was between python and lisp and not python being the language of choice by a huge margin followed by a dozen other languages, then lisp.
Maybe when Common LISP gets its next standard and stops being a geezer on the deathbed ? The world has changed since 1994. So has the computing landscape. If a programming language is static for more than a human generation, then it cannot expect any sort of adoption.
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.
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|2 years ago
- 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 (20min)showing what saving and restoring an image does, differences between SBCL and LispWorks.
- https://www.youtube.com/watch?v=1aboMZkNDCY developing a 3D graphics software.
- https://mikelevins.github.io/posts/2020-12-18-repl-driven/
- debugging CL tools: 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|2 years ago
Thanks for the links.
yourapostasy|2 years ago
Is anyone aware of SBCL or LispWorks-based tooling that integrates with ServiceNow CHG records to record and perform these kinds of changes to automatically create an audit trail of such changes in a CHG record as the Lisp image is manipulated for emergency changes?
dusted|2 years ago
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|2 years ago
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.
xenophonf|2 years ago
https://lispcookbook.github.io/cl-cookbook/vscode-alive.html
borissk|2 years ago
IKantRead|2 years ago
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.
linguae|2 years ago
I love Lisp and Smalltalk, but I work as a machine learning researcher as my day job, and I code in Python at work. Admittedly I miss Common Lisp whenever I code in Python, and I think Jupyter notebooks are a poor man’s Smalltalk environment, but when comparing Python to C and C++ (and I used to work primarily in systems programming, so I know my way around C), Python is a major productivity boost.
pjmlp|2 years ago
CERN and Fermilab were adopting Python for Grid Computing (aka Cloud nowadays), already in 2003.
MIT changed SICP from Scheme to Python back in 2006, thus news generations started playing with Python.
Peter Norvig called Python an acceptable Lisp around 2010, in HN. Having written Python for Lisp programmers in 2000.
https://news.ycombinator.com/item?id=1803351
https://norvig.com/python-lisp.html
What bums me out, is the lack of JIT in the box (yes I know there are some alternatives).
FullGarden_S|2 years ago
taeric|2 years ago
kragen|2 years ago
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
CyberDildonics|2 years ago
lenkite|2 years ago
ngcc_hk|2 years ago
dmpk2k|2 years ago
vindarel|2 years ago
---
btw, regarding packages and removing a symbol: uiop:define-package fixes the annoyance.