Getting a taste of Common Lisp in college is probably the only useful thing I got out of that boondoggle. It left a seed in my brain that eventually encouraged me to try Clojure. Clojure ended up launching my career further than I'd ever expected while making my work life significantly more pleasant.
Lisp is a gift and I am extremely thankful for it.
I was exposed to Common Lisp in college in a "Programming Language Concepts" class, almost 20 years ago, and it didn't "click". I got no help or assistance or explanation, and this was pre-youtube and Google so it was hard to find an answer to "why is this happening?"
But I gave Clojure a try despite the bad taste in my mouth Common Lisp left, and it was def worth it.
I also remember learning Scheme and having it be a real mind bender. Scheme/Racket is great, but I think Clojure being more opinionated and being immutable by default is a huge improvement in terms of understanding larger projects. Also, their parallel computation and mutex constructs are some of the easiest to understand AND easiest to guarantee you did it right. This is going to continue becoming more and more important given the huge rise in CPU core counts both on desktops and in servers.
The main reason using the JVM for clojure seems a bit weird to me as an outsider is that from what I understand, the JVM will never use tail recursion, and preferring iteration over recursions is a bit strange for a lisp, and doubly so for one that values immutability so highly.
The main reasons for Clojure to use the JVM was (IIRC) twofold: Access to a large ecosystem where basically every idea has a library available already and being immediately productive because not needing to learn a new runtime (+ previous point of libraries already being available).
With those two reasons in mind, at the time Clojure was created, it made a lot of sense to use the JVM.
Been programming in CL for ~45 years (well, it wasn't CL back then), and still do so nearly every day. Julia is the first language I've seen in all that time that comes even barely close to the joy of CL, but, they just had to f-up the macros by requiring @s before them. Sigh. I guess it's back to CL.
The @ ruins most of the point of macros, which is to extend the language, provide cross-compatibility, and create DSLs (I guess that's three points...<-as are these). Anyway, since it's not surface homoiconic (although you can sort of dig down to the homoiconicity), it's better than most other languages, but still isn't a true contender for being an acceptable Lisp -- very close though. Just put the parens back and get rid of the junk syntax (and please stop idiotically marking the macros!), and I'd probably never look back.
I've used about 10 different Lisps - by which I mean, completely different Lisps, mostly in the pre-CL days, of course. I can't even remember most of them, although MacLisp was one for sure. I mostly remember the computers they ran on, which was many, ranging from IBM 360s to Apple ][s. I even wrote two of my own (which were used by literally no one, including me :-) and tried to make a micro-programmable PDP-something-or-other into a Lisp machine (which never really worked, although it did CAR and CDR really really fast!) Once CL came out ten thousand Lisp hackers like me breathed a major sigh of relief!
It's funny how all these writings miss to explain how to figure out what a function/symbol does. When I want to know what print does in Python, I can type: help(print) and get some useful information. In Lisp there is a function too, that I wish someone told me when I was a freshman: (describe 'print)
documentation is also a good one to know. Common Lisp makes pretty much the entirety of the system available to you programmatically. Browsing the CL Hyper Spec is a good way to discover these things, too.
The specification is (mostly) exhaustive, but would make a very poor introduction into the language. Common Lisp the Language (2nd ed.) [1] by Guy Steele himself gives good background information, but I wouldn't recommend it as introductory text either (and it isn't meant to). Practical Common Lisp [2] by Peter Seibel does IMHO a pretty good job at that.
That is, I love the idea of everything being exposed. And I dream of the idea of interacting with the system this way.
However, I can count on one hand the number of people I have worked with that new you could get documentation that way in python. The world has moved on to browsers being the expected place for all documentation. :(
It's a great article. Since then, we have more tools and resources so we can enhance it:
## Pick and Editor
The article is right that you can start with anything. Just `load` your .lisp file in the REPL. But even in Vim, Sublime Text, and Atom [and also VSCode] you can get pretty good to very good support. See https://lispcookbook.github.io/cl-cookbook/editor-support.ht... (also Lem, a CL editor that works for other languages, Jupyter notebooks, Eclipse (basic support) and LispWorks (proprietary, advanced graphical tools).
> if anyone is interested in making a Common Lisp LSP language server, I think it would be a hugely useful contribution to the community.
I already linked to it, but the Cookbook (to which I contribute) is a useful reference to see code and get things done, quickly. https://lispcookbook.github.io/cl-cookbook/
While I'm at it, my first shameless plug: after my tutorials written for the Cookbook and my blog, I wanted to do more. Explain, structure, demo real-world Common Lisp. I'm creating this course (there are some free videos): https://www.udemy.com/course/common-lisp-programming/?coupon... (ongoing -50% coupon for June).
## Web Development
See the Cookbook, and the awesome list (see below). We have many libraries, you still have to code for things taken for granted in other big frameworks. I have some articles on my blog.
See again the awesome-cl list. And the Kandria game, in the making, all done in CL: https://kandria.com/ (it just got accepted for a Swiss grant, congratulations).
## Unit Testing
We have even more test frameworks since 2018! And some are actually good O_o
He doesn't mention this list, what a shame: https://github.com/CodyReichert/awesome-cl => the CL ecosystem is probably bigger than you thought. Sincerely, only recently, great packages appeared: CLOG, cl-gserver (actors concurrency), 40ants-doc, official CL support on OVH through Platform.sh, great editor add-ons (Slite test runner, Slime-star modules…), Coalton 1.0 (Haskell-like ML on top of CL), April v1.0 (APL in CL), a Qt 5 "library" (still hard to install), many more… (Clingon CLI args parser, Lish, a Lisp Shell in the making, the Consfigurator deployment service, generic-cl)…
His list is OK, I'd pick another HTTP client and another JSON library (new ones since 2018 too), but that's a detail.
I didn't do much common lisp yet, but I tried alive with vscode. It was a bit clunky but looked like what I should have expected to get if I had used emacs so, pretty cool.
You mentioned VSCode: I was surprised at how well the GitHub Codepilot plugin works with Common Lisp code - not as well as with Python or JavaScript, but pretty good. Check it out.
Everytime I see this article and the comments(or other popular submissions on Lisp), I start learning Lisp(or Clojure). I start Touretzky's book or other books, do exersism.io, try to write a roguelike and others and then it fizzles out in a couple of months and I start to learn other more modern tech. I was expecting enlightment, but never received it (I tried for couple of months :) ). I think this has been going on for a decade at least.
Nice. Well I do the same with mainstream coding languages, since I started with Lisp. They tend to fizzle out, and I go back to Lisp. It's my "native programming language," to coin the phrase.
Racket is a single extensive implementation (maybe two versions of itself, the old one and the new one updated with bits from Chez Scheme).
Common Lisp is a language standard with multiple (very different) implementations. SBCL is a native code compiled Lisp with type inference. ECL compiles to C or byte codes, with an interpreter. LispWorks and Allegro CL are commercial Lisps with IDEs and GUIs. CLASP integrates with C++. There are a bunch of other ones.
For what you're missing probably mostly just what is described in the "Escaping the Hamster Wheel of Backwards Incompatibility" section. Racket itself is a more reliable and stable language than many, maybe most, but common lisp is on another level with that shit. It has good and mature libraries for nearly everything, where racket has them only for most things.
Also if you know you ultimately need to deploy a native binary and only a native binary will work, common lisp historically produces alarmingly fast native binaries. I haven't needed to use this in racket much so I can't directly compare; it doesn't seem to prioritize perf but still seems to be much faster than other languages that don't prioritize perf.
I definitely prefer racket though. It's a bit clunky in places too but is overall much better planned and still has all the extensibility benefits.
I would say nothing but also everything. Racket is Schema and Lisp mashed up. Though Common Lisp is very easy to read once you have Racket down. Personally, I prefer Racket for my personal side projects.
Nothing, Racket is specifically designed for education and it will work for many applications. If you hit some wall (lack of libraries/performance issues), you'll be able to pick up common lisp quickly, and be more sympathetic towards its warts and anachronisms.
I've been "toying"(mashing functions + keystroke until something nice comes out the REPL) with Clojure + SBCL for a few months now.
I'm by no measure an expert. Two things I noticed what I really LOVE about Clojure versus CL.
1) The immutability by default: Yes I know you can "get there" in LISP but Clojure really has this as part of the core dna of Clojure. Immutability is surely not the silver bullet it claims to be, but dammit it has made my programs so much nicer and elegant !
2) Square-brackets [] for function parameters: As a newbie to LISP* getting used to the syntax will take some effort. But I feel that with the [] of Clojure it makes it sooo much easier...
I've tried a few different books, including Land of Lisp, PCL, SICP, Chassel's Introduction to Emacs Lisp, but what I'd recommend head over shoulders above them all is buying a copy of Touretzky's Common Lisp: A Gentle introduction to Symbolic Computation. It's wonderfully thought through, really helped me finally grok elementary stuff like what a cons cell is, exactly how apostrophes function, what asymbol is, and a lot more. It's not meant to be comprehensive, it completely leaves aside CLOS, but it's left me with a damn solid foundation for working with Lisp.
Land of Lisp is fun, and the video is a must![0]; I also really like Norvig's PAIP (Paradigms of Artificial Intelligence Programming, available for free now on GitHub[1]). PAIP shows ways of programming in Lisp that really are unlike what I've seen in most other languages.
Lately I have been working the Exercism exercises and there are over 80 Common Lisp problems, with more problems being added over time (my hope is to finish what's there and then help by adding some more).
PAIP was my favourite, I recall not really liking Land of Lisp as I felt like the quality of the example code wasn't great, but I did enjoy the Dice of Doom implementation.
Depending on what you think is fun, I found the author of this intro to CL[0] very engaging and fun. I'd still run through gigamonkey's practical common lisp for something different alongside it.
Then you should be set to start tackling the boring nerd stuff.
I learned with Paul Graham's book, ANSI Common Lisp. Still have it somewhere. I also printed out and bound a copy of On Lisp, since it was out of print and he said to just download it.
It's better in print because then you don't need to swap between two apps on the same screen. Plus then you actually type out the code, which is a great exercise.
"This book should not have been published in its current form. It contains many instances of incorrect and inconsistent terminology, as well as many other errors."[1]
Lisp is a gift and I am extremely thankful for it.