Successful Lisp: How to Understand and Use Common Lisp (1999)
dept-info.labri.fr
dept-info.labri.fr
I have found, at least from my own experience, that a programming language is best learnt by a mix of diving straight into it and writing small software that you care about with it and then supplementing that experience with the study of existing literature.
When I began learning computer programming two decades ago, it was pretty much necessary to buy a good book and read as much of the book as possible chapter by chapter. For example, the first programming language book that I read was K&R and I read that cover to cover. It was quite formative in my journey of learning to program the computer. It took me a long time to start writing useful software but when I did, I had a pretty thorough knowledge of C.
I have come to realise that these days, it is not uncommon for aspiring programmers to jump straight into developing software with a programming language determined by requirements. Not everyone has the time to read a book cover to cover. In fact, I myself learnt Python by jumping straight into developing tools that I needed for myself with it and then followed the official Python tutorial. My Common Lisp story was different. I began learning CL directly by browsing the Common Lisp Hyperspec (CLHS). It is not an approach you would find anyone recommending, and for good reasons.
If someone wants to get started with quickly developing tools using Common Lisp, I would suggest bookmarking https://lispcookbook.github.io/cl-cookbook/ which is a great resource to look up common recipes for common tasks. Special thanks to @vindarel for maintaining the Lisp Cookbook. Don’t let the parentheses scare you. With proper tooling, they are no more distracting than, say, braces in other languages.
Modern companions would be:
- the Cookbook: https://lispcookbook.github.io/cl-cookbook/ (check out the editors section: Atom/Pulsar, VSCode, Sublime, Jetbrains, Lem...)
- https://github.com/CodyReichert/awesome-cl to find libraries
Also:
- https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/
- https://news.ycombinator.com/item?id=34321090 2022 in review
Successful Lisp: How to Understand and Use Common Lisp - https://news.ycombinator.com/item?id=2087140 - Jan 2011 (7 comments)
Successful Lisp: How to Understand and Use Common Lisp - https://news.ycombinator.com/item?id=1032553 - Jan 2010 (9 comments)
As for the date, please know that this book is about ANSI Common Lisp. That is it is about a standardised language. It is not implementation or hardware specific. Therefore 90%+ of the content is relevant today as it is when it was written. That is simply the nature of Common Lisp.
If I was to make a Common Lisp lecture I would use this book and expand on the content where apropriate.
CL also has multiple dispatch and I’m not sure but I don’t think Java supports that.
I’m curious to see other responses. I’m also interested in the reverse: why Clojure over CL? (I assume integration with Java and immutable data structures, but there’s probably more.)
(let [ [a b c] [1 2 3]] (+ a b c))
as opposed to
(multiple-value-bind (a b c) (values 2 3 5) (+ a b c))
Also datastructres maps, sets sequence abstraction in Clojure seem more Organic...in CL its feels like bolted on
CL over Clojure: it's the OG Lisp that the creator of Clojure used and wanted to continue using but faced too much resistance from management afraid of anything not-Java/not-Oracle, or not-CLR/not-Microsoft, etc. Clojure shipped originally as "just another jar" so devs could "sneak" it in. If you don't have such a management restriction, why Clojure? If you want to integrate CL with the JVM, you can use the ABCL implementation, there's also something from one of the proprietary Lisps. Some useful CL features that are nice in this domain: conditions and restarts mentioned in a sibling comment (very nice to help interactively develop/debug e.g. a selenium webdriver test), ability to easily compile an exe (perhaps useful for microservices, or just to keep your deployment environment clean and not having to care about Lisp), and ability to easily ship with an open local socket allowing you to SSH in (or SSH port forward) and debug/fix/poke around in production (JVM of course lets you attach debuggers to a running process, even certain billion+ dollar companies will have supervised/limited prod debugging sessions for various hairy cases, but it's not as interactive). You should never hear CL advocates claim you can't scale to large teams/groups of engineers or large multi-million-lines sized projects, though you might oddly hear Clojure advocates sometimes claim you can't (and shouldn't) scale to such large projects -- large groups of engineers are a non-issue for them as well though, the challenge is in hiring, not in the language somehow making it impossible to modularize and keep people from stepping on each other.
Clojure over CL: its integration with the JVM is nicer than ABCL's, so if you do actually want a lot of the great world of Java stuff, it's easier to get at/you don't have to make a choice to enjoy things like state of the art GC or concurrency support. Database integration libraries are better. Clojure's philosophy of values are values is so much better. Access to libs (Clojure or Java) is via Maven, so it's a larger ecosystem with more self-integrating components (especially around monitoring/metrics) than what's available for Lisp via Quicklisp. Clojure is very opinionated, much of it quite tasteful, and that gives the whole ecosystem a certain consistency. (You can have immutable data structures in CL, you can if you want use [] for literal vectors and make them syntactically important e.g. in let bindings, but not everyone will be on board.) Even though its popularity seems to have stopped growing, at least at the same rate as e.g. Go which it was keeping pace with for a while, it's still popular enough with a bigger community; as a proxy measure there are multiple conferences around the world and good talks at adjacent conferences, whereas Lisp mostly just has one conference in Europe per year and only occasional the occasional project branching outside of that.
If you're doing a client-side-heavy webapp, ClojureScript is still amazing, CL's answers there aren't very compelling with the exception of CLOG (https://github.com/rabbibotton/clog) which takes an entirely different direction than the usual idea of translating/running Lisp on top of JavaScript and its popular frameworks.
What do you want?! A dollar value addition to your salary?
To answer your question: Knowing about an important and highly influential part of the industry in which you work.
If that sort of thing is not important to you, by all means let it pass you by.
Although the approach to macros is still quite distinctive. To the point that if a language has Lisp like macros, it’s probably considered a Lisp.
First, a lot of languages have closures these days, do you know them and more generally how to tastefully use higher-order functions? When Java 8 came out, I could see a difference between programmers who had useful experience or instruction (Scheme + SICP is still great on this) using closures elsewhere prior, excited programmers who were using them for the first time even if frequently not tastefully, and old programmers who had never strayed outside their lane and look at any new language feature or evolution that they now have to learn and contend with to keep up with a shady eye, never mind the potential benefits.
Second, some languages have something like macros, how familiar are you with metaprogramming? Maybe you'll be satisfied with C++? A comparison from the author of the CLASP implementation who is an expert in both langs: Lisp macros are to C++ templates as poetry is to IRS tax forms.
Third, do you know OOP, or perhaps you know it quite well from things like Java/Python/C++/Ruby/JS and dislike it? The Common Lisp Object System (CLOS) was the first ANSI standardized OOP system and yet it's a lot different from other attempts. In particular, it does not couple classes together with methods, they are defined separately which avoids a lot of common OOP problems while giving you multiple dispatch for free (eliminating some verbose design patterns too). It's also got less commonly seen things like metaclasses (with a whole book written on just the meta-object protocol highly praised by Alan Kay), multiple inheritance, a way to redefine classes and reshape existing objects at runtime (overload an 'update-instance-for-redefined-class method), and a poor man's initial support for maybe 70-80% of the value of aspect oriented programming with :before/:after/:around method combinators out of the box that can be further augmented if needed for the full value. Some of the ideas can be had with effort (perhaps done for you already via libraries) in other langs.
Fourth, do you know about conditions and restarts, a way to handle errors that's not just goto error or classic stack-unwinding exceptions? There's a whole (short) book ("The Common Lisp Condition System: Beyond Exception Handling with Control Flow Mechanisms") on just this topic if individual chapters/essays elsewhere aren't enough for you. I don't know a good alternative for getting this concept, thus the value of it may be limited to whether you can actually use it or an imitation (the book author did implement a version for Java: https://github.com/phoe/cafe-latte).
Fifth, do you have experience in incrementally writing and debugging a program as it's running, or have you only ever done the usual edit > compile > run > observe and repeat cycle? Common Lisp is still the best for this, Clojure is ok, Java with JRebel gives you maybe 80-90% of the practical benefits. TDD maybe gives 20-30% of the practical benefits while being tedious. Some people definitely do not like the style, but if you haven't seen the style to determine that for yourself, you're missing out. (And if you're freaking out about error checking, you can get some compile-time warnings from SBCL about bad types or missing functions and so forth; they're just warnings instead of errors because you can fix them as you go, you can redefine (even if you're in a debugger context) and continue rather than restart everything and lose any state. In SBCL, redefining a function also recompiles it for you. 'compile and 'compile-file are standardized built-in functions to the language you can invoke at runtime, rather than a separate program.)
As for editors, you don't have to use emacs. (I prefer vim.) https://lispcookbook.github.io/cl-cookbook/editor-support.ht... gives a list of alternatives besides those two. The main things IMO that you need as far as editor support goes: highlight matching parens (basically everything), and ability to talk to the running Lisp to provide the features of my fifth point. To elaborate even further on that, such support gives you redefinition, debugging (breaking/stepping/tracing), disassembling, intellisense-style function doc and even symbol auto-complete, and jump-to-code/cross-referencing features, all part of Lisp itself and conveniently/portably accessed with regular Lisp code talking to the editor typically over a socket rather than needing to be implemented externally. The main development feature, editor or otherwise, still lacking from anyone (though someone was working on this, I haven't followed up in a long while) is mass auto-refactoring; in practice it's not a huge limitation because you don't couple things as heavily as in other languages that necessitate frequent huge refactorings, and you can use the same sorts of tools people used just fine prior to semantic mass-refactoring tools becoming more common. (I use Grepper with vim for mass-rename.) Fowler's 2nd edition of "Refactoring" uses JavaScript with no fancy tools in part just to show the point that the discipline isn't tool dependent anyway.
Chances are that what you know and prefer is one of the first two or three things you ever used, which was decided for you by someone else, directly or indirectly.
If you think that makes it "native", you're deceiving yourself.
EDIT: to be fair, Coalton seems even more interesting than defstar, but it has issues with mutation.
This is not unique to Coalton. Any HM-based language that defines mutation primitives has it, including Haskell and OCaml. These languages don't "solve" it a sense most people think, instead they provide some sort of restriction or workaround to the HM theory to make mutation constructs feasible. There's a huge space of possible solutions, including ensuring functional purity with monads (Haskell) to using weak polymorphism (OCaml) to using Wright's value restriction (eliminate invalid mutations, but also eliminate tons of reasonable, valid programs).
Coalton developers know of the HM deficiency and described it very well here [2]. It looks like they're building out more important parts of the language that affect their users more seriously (e.g., adding records) before making a hugely consequential design decision around mutation, which people don't seem to bump into much.
It doesn't seem to have stopped them from building interesting software in the slightest. [3]
[1] https://en.wikipedia.org/wiki/Value_restriction#A_Counter_Ex...
[2] https://github.com/coalton-lang/coalton/issues/84
[3] https://coalton-lang.github.io/20220906-quantum-compiler/
> The Lisp development systems on both my Mac and my PC run comfortably in anywhere from 4 to 8 megabytes of RAM. Less in a pinch. The integrated C++ development environments take anywhere from 12 to 20 megabytes. Both have comparable tools and facilities.
So you don't have to rewrite anything. Nowadays ML stuff is usually about matrix multiplications in its core so Python with NumPy (or a Cuda library) also delivers good enough performance. The native code is already there, just call it. You don't have to write it.
- Requires manual type annotations to achieve remotely reasonable performance
- Does no interesting optimisations around method dispatch
- Chokes on code which reassigns variables
- Doesn't model memory (sroa, store forwarding, alias analysis, concurrency...)
- Doesn't do code motion
- Has a decent, but not particularly good gc
Hotspot hits on all of these points.
It's true that if you hand-hold the compiler, you can get fairly reasonable machine code out of it, same as you can do with some c compilers these days. But it's 80s technology and it shows.
I'm working on a better, parallel but still far from Java state-of-the-art GC for SBCL <https://zenodo.org/record/7816398> - which presumably is some skin in the game.
Just compare the Nyxt web browser with any Java monster out there.
var x = MyAwesomeClassFactoryBeanTemplate.getBean().getFactoryInstance().createNewMyAwesomeClass(foo, bar);Secondly, we are speaking about dynamic languages over here, that keep using C and Fortran.
I didn't stress the garbage collector enough so I can say that LW is faster or slower than other CL implementations. I'm currently doing an algorithmic research where the strain on garbage collector is not really that big, it's mainly about numerical performance and SBCL is by far the best from what I tried - LW, SBCL, CCL, Clisp, ABCL, ECL. Garbage collector takes usually 1-2% of run time which isn't that bad. I suppose that if I stressed it more than LW garbage collector would outperform SBCL but that's only my theory based on target audience of LW.
If you have experience with Allegro and LispWorks and can compare it to other implementations, could yous hare it, please? I'm quite curious. There isn't much on the internet about this topic.
Are allegro and lispworks appreciably better? My understanding was that lispworks, at least, forked from cmucl a long time ago and put less work into python than sbcl did.
The language is in production at Google, Facebook, Amazon and Microsoft (including making it into the Windows kernel), and is slowly being included in Linux as well.
https://github.com/azzamsa/awesome-lisp-companies
industrial theorem prover, design of Intel chips, quantum compilers...
and little me, being more productive and having more fun than with python to deploy boring tools (read a DB, format the data, send to FTP servers, show a web interface...).
It’s fun to use but it doesn’t really make sense to use it for most serious software projects, particularly those that want collaborators.
Right there, along with Haskell is exactly why Lisp was never an option for me. And much like the author, I've been subjected to the darn thing multiple times since an early age (the 80's).
[EDIT]: and most notably missing from the list: The Lisp ecosystem is pretty much impossible to understand.
There are so many flavors of the darn thing none of which are interoperable with the others.
Every time I found something written in some random dialect of Lisp, there's always a missing piece to get it to run on my machines unless it's a 20 line coding exercise.
I've also never found a list that explains why "this Lisp is different from that Lisp because ..." .
Everyone in that world seems to assume their favorite patois is the best thing since sliced cheese.
Seen from the outside, it's a giant mess.
Makes it impossible to pick the right tool for the job.
You see a headline “Did amazing thing using Lisp!!” and find that it’s actually more “Did amazing thing with A Lisp”, and, typically, not the Lisp you like to use.
Nobody calls C, Java, C#, C++, Pascal, D, etc. an “Algol” or whatever generic term might apply to this family of languages. “DOOM is written in Algol”. But this happens all the time with Lisps.
No, there are way, way more than that.
For programming, the best env for CL it's Emacs and Slime, and for Scheme there's Emacs and Geiser. For further programming, Org-babel from Org-Mode wth the accompanying modules for Slime/Geiser with ob-scheme or ob-lisp.
Emacs with Org-Babel it's like having an anotated REPL with options to put anotated marks, graphics and/or export it to ODF or PDF. Kinda like the Python/Jupyter notebooks but with superpowers.