> My advice is this: as you learn Common Lisp and look for
> libraries, try to suppress the voice in the back of your
> head that says “This project was last updated six years
> ago? That’s probably abandoned and broken.” The stability
> of Common Lisp means that sometimes libraries can just be
> done, not abandoned, so don’t dismiss them out of hand.
I have found this to be true in my own experience. The perception of stagnation is, however, a common initial objection to folks working in CL for the first time.
My personal problem with CL libraries is not that, but rather the lack of documentation. More often than not, there is no documentation at all, not even a readme file.. It feels like some library authors simply don't care. I'd say this attitude has a negative impact on how people perceive viability of those libraries -- and by extension, of the language.
In Freenode's #mercurial, sjl said this about common lisp:
<sjl_> CL code from the early 90's runs just fine on SBCL from a month ago
<sjl_> But trying to run five-year-old python/ruby/scala makes me hate life.
This echoes his earlier blog post, volatile software:
It's a worthy effort. It really tires you after a while with languages that constantly break the language, the libraries, the ecosystem and the tooling in the ao called "minor versions". Ain't nobody got time to deal with that stuff. Then they are surprised that people still run "ancient" versions of compilers or libraries. Yes scala it's about you.
I'm curious about python being on that list. I worked with python on multiple applications, some fairly large (500kloc), over 10+ years with multiple version upgrades without issue. I always considered python's backwards compatibility to be one of its strengths. That was why the python-3 was such a big deal, it would break backwards compatibility which had always been a top priority.
I haven't read the whole thing, but, I gotta say, seeing the "Ugliness" section (http://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#ugl...) in the preamble gives me high hope for this writeup. It's so lovely to see writing on Lisp that isn't just hagiography.
Yes. I don't mind the parens (syntax highlighting can subdue them), but every time I actually fire up Common Lisp to try it, I see all caps somewhere, like someone even older than me is shouting at me, or I stumbled across a box of my Fortran punched cards from before I switched to APL in the 1970's. That's an ugliness not addressed by this guide.
Thanks for this guide, I'll keep referring to it often.
My current road to Common Lisp is working through Peter Norvig's book Paradigms of Artificial Intelligence Programming [0]. It's not a direct route to the kind of programming most people do nowadays, but I hope to at least get a taste of what it was to be a researcher in classical AI.
Not only classical AI. If you bake in probability into logic-based Lisp & Prolog AI you end up in probabilistic programming. This is a very hot research topic.
You can also then add deep-learning based samplers. It's all connected.
I'm wondering what is people's opinion on modern Scheme dialects like Racket vs. Common Lisp? It seems to be pretty stable, with active development community, and comes with batteries installed.
Well, first off Racket is a different language from Scheme, although it's very similar. It's definitely very cool, and the folks involved have invested a tremendous amount of effort into it.
At the end of the day, though, I prefer Lisp. I like that it's standarised; I like that so much code runs in just about every implementation; I like that — as someone noted elsethread — in Lisp it's not uncommon for libraries to be done.
I like that Lisp is much more complete than Scheme. Standarised places are great. Standardised extensible types are wonderful. I don't like that so many in the Scheme community are so very opposed to adding to the language, no matter how painful the lack (witness the abject failure of R6RS).
CLOS is amazingly good, better than any object system in any other language I've used. Scheme doesn't have a standard version.
I think that multiple namespaces is a huge feature. A lot of Schemers disagree, but I don't see a good reason for functions, macros, classes, tags &c. to share a namespace, and it makes programs more obtuse.
I don't care for Scheme's separate Boolean types, nor for the way it splits NIL, () & #f. They make code less concise, for no terribly good reason IMHO. Maybe that's a matter of taste, but I think it reflects the pragmatism of Lisp vice the idealism of Scheme.
Lisp has standardised compiler macros. Lisp's normal macros are, I believe, more powerful than Scheme's (as I understand it, one can implement Scheme macros in Lisp but not Lisp macros in Scheme).
Scheme's dynamic-wind is broken, while UNWIND-PROTECT isn't.
Scheme's continuations in general are really awesome, but make it slightly too difficult to optimise code. I think it's great to have them available in an educational language, but not so great to have them in a general-purpose industrial language meant for real programs.
Generally, when I come across some corner of the Lisp standard I don't understand, some years later I'll recognise how incredibly valuable it is to be able to have it, and how great it is that every implementation has it. I never come across any corner of the Scheme standards, because they have no corners. Whenever I write Scheme I'm not really writing Scheme — I'm really writing guile or whatever.
Scheme's a wonderful language for teaching C.S. concepts like continuations & computer science in general — it's not IMHO a good language for industrial-strength software.
Racket is a single implementation of what used to be a Scheme but has now grown to be something else entirely different. It's really cool — I just wish everyone involved had spent that time on SBCL & portable Common Lisp libraries instead. It's a free world, of course!
Just recently searched for an IMAP library but only found one for Allegro Common Lisp. The lack of libraries is one of my biggest concerns when it comes to using Lisp in production.
I have a similar experience. Started out learning Clojure because it was 'practical', stayed with Common Lisp because I had less tooling setup to deal with. To be fair, that was because the Emacs integration for clojure depended on a specific CVS revision of Swank and I was starting out with Emacs. The situation has greatly improved regarding Clojure tooling. Still not as good as CL.
With time I've found CL to be much more flexible than Clojure and less opinionated so you'll be able to explore different paradigms.
That said if you want to write an SPA, go with ClojureScript. It has a good dev UX story (Figwheel <3) and Webpack will have already lowered your expectations regarding build systems to so setting up a ClojureScript project will seem less of a hassle.
Clojure is really your better bet. It is highly practical with a good community and excellent Java interop. You never have to worry about finding a good library. The syntax is also a bit more easily parsable than CL. If you don't touch the Java interop stuff, it's just as elegant as CL.
One suggestion: checked again just now and SBCL is still not production-ready on Windows (for the understandable reason of insufficient volunteers); perhaps the recommendation for that platform should be changed to CCL?
>One suggestion: checked again just now and SBCL is still not production-ready on Windows (for the understandable reason of insufficient volunteers); perhaps the recommendation for that platform should be changed to CCL?
It only has a warning for threading code that has been left there for years. But I use it on windows with no problems.
On the other hand Clozure CL is a very very good implementation with a loooooooooooooooooooooooooooooooooooooooooooooooooong history (emphasis added) being used in production stuff.
But don't limit yourself to SBCL and CCL -- take a look also at ECL, ABCL, CLASP, etc.
I've tried both. Slimv was always very buggy for me, especially the REPL buffer. I think this was because it was made long before any of the new Vim async stuff existed, and so had to do a lot of ugly hacks to get a reasonable REPL.
Vlime was made after Neovim gave Vim a kick in the ass to add async, and it takes advantage of all of it. This lets its implementation be a lot cleaner and more stable, at least from what I've experienced.
One thing I do that makes the REPL a lot nicer: I run the actual SBCL process inside a Neovim terminal split (with rlwrap). This gives me an actual REPL like you would expect, not just Vlime's "REPL" (which is essentially two separate buffers, one for input and one for output).
I've been using slimv for hobby hacking for a while, but not professionally so you can take my commentary with a big grain of salt. You should try both, and if 'stevelosh likes vlime better you might start with that.
I like slimv a lot better myself, and prior to that I made due with a gnu screen split-window terminal with a vim plugin that would send stuff from one screen panel to the other (used that for Python, Clojure, and Node sometimes too). I tried using vlime somewhat recently, but it just felt off, hard to express everything I didn't like but maybe the experience of having to launch your REPL separately was the beginning (slimv just finds your lisp on the path). You're encouraged to compile whole files at once rather than bit by bit (perhaps sensible for Real Work), the REPL buffer is read-only which is quite bizarre to me, and the default key bindings make less sense. Feature-wise it seemed comparable since they both use Swank. The tutorial at https://kovisoft.bitbucket.io/tutorial.html which follows a classic SLIME demo vid is nicer than the vim-tutor for vlime.
I just wish common lisp people would embrace static typing so that I could ask the reply/compiler: After all these changes, is the code still formally correct (as far as types were specified)? Typed racket/clojure show it's possible.
> In Common Lisp you can certainly choose to panic on or ignore errors, but there’s a better way to work. When an error is signaled in Common Lisp, it doesn’t unwind the stack. The Lisp process will pause execution at that point and open a window in your editor showing you the stack trace. Your warrior’s sword is hovering over the monster, waiting for you. At this point you can communicate with the running process at the REPL to see what’s going on. You can examine variables in the stack, or even run any arbitrary code you want.
This doesn't seem like something that's particularly difficult to do with c/gdb.
> This doesn't seem like something that's particularly difficult to do with c/gdb.
Well, why don't you do it, then? Not trying to be snarky(not much anyway), but I feel you are seriously under-estimating the work involved. Either that, or the description does not make it clear enough.
It's a full blown REPL. We are not talking about just printing out the code at that point, or maybe mutating a variable on the stack. We can execute arbitrary code and even replace entire sections of code with new code, and then hit continue and it works as if nothing happened, only now running the new (and hopefully corrected) code. Just the memory management implications of doing this in C would be very interesting.
Note that you can also do this over a network connection. NASA folks used this to great effect to patch Deep Space-1. Lisp machines also used this capability over the entire OS.
I have also used a similar mechanism (with Chicken Scheme) to do incremental development on iOS, without having to do the whole xcode deploy/run cycle.
The closest analog I can think of today is a browser's "console", which lets you do similar things for javascript code.
A while back, I remember running samba with the configuration option "panic action = /usr/bin/X11/xterm -display :0 -e gdb ...". On a segfault, you'd get a happy little xterm ready to go. Never managed to recover an operation from that window, though.
I have caught a condition in StumpWM (a window manager written in Common Lisp) and done something useful with it. A completely different beast. Practical Common Lisp has a solid example that may be a bit enlightening (http://www.gigamonkeys.com/book/beyond-exception-handling-co...).
I have implemented live coding via DLLs for C , it’s not hard to do and can easily replace gdb. I don’t think that gdb offers live coding outside the box. Inspecting live state and to an extend REPL abilities do exist in GDB.
[+] [-] tumba|7 years ago|reply
[+] [-] mike_ivanov|7 years ago|reply
[+] [-] jordigh|7 years ago|reply
http://stevelosh.com/blog/2012/04/volatile-software/
I kind of have the feeling that fighting bitrot is sjl's main motivation for CL.
[+] [-] stevelosh|7 years ago|reply
[+] [-] diaz|7 years ago|reply
[+] [-] eikenberry|7 years ago|reply
I am missing something?
[+] [-] mbroncano|7 years ago|reply
[+] [-] agumonkey|7 years ago|reply
[+] [-] bunderbunder|7 years ago|reply
[+] [-] Syzygies|7 years ago|reply
[+] [-] krmboya|7 years ago|reply
My current road to Common Lisp is working through Peter Norvig's book Paradigms of Artificial Intelligence Programming [0]. It's not a direct route to the kind of programming most people do nowadays, but I hope to at least get a taste of what it was to be a researcher in classical AI.
[0] https://github.com/norvig/paip-lisp
[+] [-] nextos|7 years ago|reply
You can also then add deep-learning based samplers. It's all connected.
[+] [-] TurboHaskal|7 years ago|reply
[+] [-] vtail|7 years ago|reply
[+] [-] eadmund|7 years ago|reply
At the end of the day, though, I prefer Lisp. I like that it's standarised; I like that so much code runs in just about every implementation; I like that — as someone noted elsethread — in Lisp it's not uncommon for libraries to be done.
I like that Lisp is much more complete than Scheme. Standarised places are great. Standardised extensible types are wonderful. I don't like that so many in the Scheme community are so very opposed to adding to the language, no matter how painful the lack (witness the abject failure of R6RS).
CLOS is amazingly good, better than any object system in any other language I've used. Scheme doesn't have a standard version.
I think that multiple namespaces is a huge feature. A lot of Schemers disagree, but I don't see a good reason for functions, macros, classes, tags &c. to share a namespace, and it makes programs more obtuse.
I don't care for Scheme's separate Boolean types, nor for the way it splits NIL, () & #f. They make code less concise, for no terribly good reason IMHO. Maybe that's a matter of taste, but I think it reflects the pragmatism of Lisp vice the idealism of Scheme.
Lisp has standardised compiler macros. Lisp's normal macros are, I believe, more powerful than Scheme's (as I understand it, one can implement Scheme macros in Lisp but not Lisp macros in Scheme).
Scheme's dynamic-wind is broken, while UNWIND-PROTECT isn't.
Scheme's continuations in general are really awesome, but make it slightly too difficult to optimise code. I think it's great to have them available in an educational language, but not so great to have them in a general-purpose industrial language meant for real programs.
Generally, when I come across some corner of the Lisp standard I don't understand, some years later I'll recognise how incredibly valuable it is to be able to have it, and how great it is that every implementation has it. I never come across any corner of the Scheme standards, because they have no corners. Whenever I write Scheme I'm not really writing Scheme — I'm really writing guile or whatever.
Scheme's a wonderful language for teaching C.S. concepts like continuations & computer science in general — it's not IMHO a good language for industrial-strength software.
Racket is a single implementation of what used to be a Scheme but has now grown to be something else entirely different. It's really cool — I just wish everyone involved had spent that time on SBCL & portable Common Lisp libraries instead. It's a free world, of course!
[+] [-] hirow|7 years ago|reply
[+] [-] vindarel|7 years ago|reply
- https://github.com/CodyReichert/awesome-cl - http://quickdocs.org/
[+] [-] flavio81|7 years ago|reply
https://www.cliki.net/email
And note that CLiki does not cover all that it's out there.
[+] [-] typon|7 years ago|reply
[+] [-] PuercoPop|7 years ago|reply
https://twitter.com/stevelosh/status/1034147772440760320?s=1...
I have a similar experience. Started out learning Clojure because it was 'practical', stayed with Common Lisp because I had less tooling setup to deal with. To be fair, that was because the Emacs integration for clojure depended on a specific CVS revision of Swank and I was starting out with Emacs. The situation has greatly improved regarding Clojure tooling. Still not as good as CL.
With time I've found CL to be much more flexible than Clojure and less opinionated so you'll be able to explore different paradigms.
That said if you want to write an SPA, go with ClojureScript. It has a good dev UX story (Figwheel <3) and Webpack will have already lowered your expectations regarding build systems to so setting up a ClojureScript project will seem less of a hassle.
[+] [-] cultus|7 years ago|reply
[+] [-] rwallace|7 years ago|reply
One suggestion: checked again just now and SBCL is still not production-ready on Windows (for the understandable reason of insufficient volunteers); perhaps the recommendation for that platform should be changed to CCL?
[+] [-] flavio81|7 years ago|reply
It only has a warning for threading code that has been left there for years. But I use it on windows with no problems.
On the other hand Clozure CL is a very very good implementation with a loooooooooooooooooooooooooooooooooooooooooooooooooong history (emphasis added) being used in production stuff.
But don't limit yourself to SBCL and CCL -- take a look also at ECL, ABCL, CLASP, etc.
[+] [-] pvaldes|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] foo101|7 years ago|reply
Anyone has tried both Slimv and Vlime for Vim? What are the differences? Which one gives an experience closer to that of SLIME?
[+] [-] stevelosh|7 years ago|reply
Vlime was made after Neovim gave Vim a kick in the ass to add async, and it takes advantage of all of it. This lets its implementation be a lot cleaner and more stable, at least from what I've experienced.
One thing I do that makes the REPL a lot nicer: I run the actual SBCL process inside a Neovim terminal split (with rlwrap). This gives me an actual REPL like you would expect, not just Vlime's "REPL" (which is essentially two separate buffers, one for input and one for output).
[+] [-] Jach|7 years ago|reply
I like slimv a lot better myself, and prior to that I made due with a gnu screen split-window terminal with a vim plugin that would send stuff from one screen panel to the other (used that for Python, Clojure, and Node sometimes too). I tried using vlime somewhat recently, but it just felt off, hard to express everything I didn't like but maybe the experience of having to launch your REPL separately was the beginning (slimv just finds your lisp on the path). You're encouraged to compile whole files at once rather than bit by bit (perhaps sensible for Real Work), the REPL buffer is read-only which is quite bizarre to me, and the default key bindings make less sense. Feature-wise it seemed comparable since they both use Swank. The tutorial at https://kovisoft.bitbucket.io/tutorial.html which follows a classic SLIME demo vid is nicer than the vim-tutor for vlime.
[+] [-] stewbrew|7 years ago|reply
[+] [-] earenndil|7 years ago|reply
> In Common Lisp you can certainly choose to panic on or ignore errors, but there’s a better way to work. When an error is signaled in Common Lisp, it doesn’t unwind the stack. The Lisp process will pause execution at that point and open a window in your editor showing you the stack trace. Your warrior’s sword is hovering over the monster, waiting for you. At this point you can communicate with the running process at the REPL to see what’s going on. You can examine variables in the stack, or even run any arbitrary code you want.
This doesn't seem like something that's particularly difficult to do with c/gdb.
[+] [-] outworlder|7 years ago|reply
Well, why don't you do it, then? Not trying to be snarky(not much anyway), but I feel you are seriously under-estimating the work involved. Either that, or the description does not make it clear enough.
It's a full blown REPL. We are not talking about just printing out the code at that point, or maybe mutating a variable on the stack. We can execute arbitrary code and even replace entire sections of code with new code, and then hit continue and it works as if nothing happened, only now running the new (and hopefully corrected) code. Just the memory management implications of doing this in C would be very interesting.
Note that you can also do this over a network connection. NASA folks used this to great effect to patch Deep Space-1. Lisp machines also used this capability over the entire OS. I have also used a similar mechanism (with Chicken Scheme) to do incremental development on iOS, without having to do the whole xcode deploy/run cycle.
The closest analog I can think of today is a browser's "console", which lets you do similar things for javascript code.
[+] [-] zoltar|7 years ago|reply
I have caught a condition in StumpWM (a window manager written in Common Lisp) and done something useful with it. A completely different beast. Practical Common Lisp has a solid example that may be a bit enlightening (http://www.gigamonkeys.com/book/beyond-exception-handling-co...).
[+] [-] sahil-kang|7 years ago|reply
[+] [-] JulianMorrison|7 years ago|reply
[+] [-] kilon|7 years ago|reply