Common Lisp: An Interactive Approach (1992)
cse.buffalo.edu
cse.buffalo.edu
Nothing comes close.
Once I retire and have some more free time I want to make videos and make open source contributions to make it more palatable and sexy for beginners.
Folks are really missing out on a lot of joy and happiness by not programming in Common Lisp but I also understand why.
I use SBCL for everything but work because I cannot yet; we are getting there, but like you say, it’s such a nice experience working interactively building fast that it is magic and it’s painful returning to my daily work of Python and typescript/react. It feels like a waste of time/life, really.
But in short; for now clojure(script) is the most practical way currently.
Note: there is ABCL for running CL on the JVM, so for that you don't need clojure (I haven't tried but I have friends who use it and say it works well), however the JS issue (and I would need JS and interact with JS) isn't solved yet, as far as I know. I haven't looked recently, but threads like [0] are not that old and I cannot quickly see many things changed in that respect. So I would rather opt for what CLOG did and other Liveview type of systems, so it doesn't matter what happens in the frontend. WASM and (because now it's still needed) a robust JS implementation would be great.
There is a rich ecosystem of CL implementations. I don’t use it much at all, but ABCL is really interesting also if you work on the JVM.
Common Lisp (SBCL) and CLOG is worth checking out first.
The magic I described in the original comment exists in Clojure but you can feel its true power in Common Lisp.
On the SBCL side of things, a quick skimming of https://lispcookbook.github.io/cl-cookbook/type.html doesn't paint a very pretty picture. The syntax looks a bit verbose, and the error seem to be very rudimentary, not worded well, and lacking even a line number. Overall, the readability of the Common Lisp code in this link (as someone who doesn't know CL) honestly doesn't seem to be great. Hopefully, if someone could distill and write about some of the key language features that make CL great, we could carefully transplant/copy those features into a modern type-safe language.
Regarding the syntax of those type declarations, it's true I also thought CL was verbose and ugly at first, but it is also extremely flexible through macros and reader macros. At the end of the day I think it's easier to improve that in CL that it is to make other languages support the interactive development of CL which requires fundamentally rewriting the language runtime. For those type declarations specifically, there is serapeum which is a extremely commonly used library, that provides -> for more ergonomic type declarations, ie:
(declaim (ftype (function (string string) string) concat))And this is another thing I'm not sure how to explain, I thought CL is surely more verbose and ugly than python for small scripts, but maybe it's macros will make it cleaner for building large systems. But then when I started writing actual programs, even small programs without any of my own macros, I generally use about 30% less LoC than in python... I've thought about making sly/slime like support for python (built on ipython with autoreload extension) or ruby (with it's fairly new low-overhead debug gem). But at the end of the day support for these things will always be incomplete and a hack compared to CL where it was designed from the start to support it, they run 20-100x slower than CL, and imo their runtime metaprogramming is harder to reason about than CL which is mostly compile time metaprogramming. When I've had to dig into some CL library, which is a lot more often than in those languages because it has 10000x fewer users so of course I will be first to run into some issue, it has generally been easy to understand what is going on and fix it, compared to large codebases in other languages.
Regarding "modern type-safe language", languages with expressive type systems, rust, ocaml, haskell, typescript, etc, can give really confusing type errors, when you get into generics and traits and more expressive stuff. I'm not convinced it's a better development experience than a dynamically typed languages where values have simple types, and when you get a type error you see the actual contents of the variable that is the wrong type and state of the program, at least in the case of CL where the stack isn't unwound on error and runtime is kind of compile-time as you're running all code as you write it. But mostly this sort of interactive development is very hard to implement in static languages, I'm not aware of any that does it. For example even in static langs like ocaml that have a repl through a bytecode interpreter, simple things don't work like say you pass some function as an event handler, and then update the function. As you passed efectively a function pointer to the old definition, rather than a symbol name like lisp, it will be calling the original function not the new version. But the main issue is that efficient staticly typed languages the type system is all at compile time, type information doesn't exist at runtime, which is great for performance, but means you don't get the ability to introspect on your running program like you do in CL and elixir, which personally I value more than full compile-time type checking.
Would I like some new language or heavy modification of existing language runtime that provides the best of everything? of course, but I also realize that it's a huge amount of work and won't happen with 10 years, while I can have a nice experience hacking away in CL and emacs right now. And ultimately CL is an extremely flexible language and I think it'll be less work to build on CL than to provide a CL like runtime for some other language. For example projects really pushing the edge there is Coalton described above. While personally I prefer dynamicly typed for general application programming I think Coalton could be great for compilers, parsing some protocol, or writing some subparts of your program in. And vernacular (https://github.com/ruricolist/vernacular) which explores bringing racket's lang and macro system to CL. For more standard CL code, using extremely common and widely used libraries like alexandria, serapeum, trivia, etc, already makes CL into a fairly modern and ergonomic language to write.
Edit: also about the lack of line numbers in the compiler message, it's funny I never noticed that and I'm not sure how exactly emacs does it, but for those compiler warnings about types emacs underlines in red not just the line but the exact expression within the line and you can press a shortcut to go to the next and previous compiler warning/error/note. For better or worse emacs is the de facto free development environment for CL (lispworks and allegro are the commercial ones still maintained), though in recent years there are plugins for VSCode and most major editors, I haven't tried them and am not sure how they compare.
I ask because it seems if one want to go CL route, the options would be scarce for basic stuff that other programming languages have lots of tried and true libraries for. Take webdev for example. What are CL options that are on par with Django and Fast API?
I do think there is a meta going on around LISP repl and it's internal introspection which other REPL don't quite provide. You can come to almost the same place in output, but not at interaction with the run state of the 'machine' itself. (somebody else in the thread made the point its mostly there except handling exceptions in the stack)
The importlib.reload function only applies to one copy of a module. A comprehensive solution would be incredibly complicated and would still have limitations.
In contrast, a Lisp package exists in exactly one place. No matter where you get it from, two references to the same package are always eq (having "is" equality in Python terms). Therefore, if you redefine something in a package, you redefine it for everything that uses the package. It also helps that imports in Lisp apply to the symbols, not the things they refer to. So importing something doesn't hide a copy of it anywhere. The most naive redefinition technique will always work, with no edge cases.
The inability for class redefinition to affect already existing objects in Python is another severe limitation. Even if you could redefine anything reliably in Python, you'd still have this problem.
I still wish there was an environment more like Smalltalk for Python.
Some years ago I was playing around with Franz Lisp, and noticed an interesting debugging feature in it. A few days later, I was using a then-new version of Visual Studio for writing either C (not C++) or VB, and noticed the same cool feature in it, which MS was calling Edit and Continue.
IIRC, it was introduced in that VS version, but not sure, since I was not a regular Visual Studio user.
import code; code.interact(local=vars(foo))
Python has a debugger in the standard library that can also do post-mortem inspections.
You can also use `from importlib import reload` and then have an expression like reload(foo).bar() to constantly reload your foo library.
That's useful not only for breakpoints but also for errors. We can fix an error without re-running everything from zero. https://www.youtube.com/watch?v=jBBS4FeY7XM
- https://lispcookbook.github.io/cl-cookbook/ (recent and to the point, hope you like it) check out the editor section, there's more than Emacs these days: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...
- https://github.com/CodyReichert/awesome-cl for libraries
- https://www.classcentral.com/report/best-lisp-courses/#ancho...
- a recent overview of the ecosystem: https://lisp-journey.gitlab.io/blog/these-years-in-common-li... (shameless plug, on HN: https://news.ycombinator.com/item?id=34321090)
I am mainly thinking of testing, and if FiveAM is still the way to go, because there is a note at the beginning about Rove, which seems to be pretty well maintained these days. But looking at FiveAM again I see some recent commits. Also, in the concurrency chapter there is the section on lparallel, which seems like a very old unmaintained library.
This all said, I think one thing that makes cl nice is that it doesn't feel out of the question to use a very old library for something you need. So none of this is actually a problem.
FiveAM is still a very good solution, difficult to replace. We didn't replace it with another test framework, and we looked at a few of them. Rove doesn't live on its promise to run `rove <system>` on the command line for example.
Your last sentence is very true!
Sigh. It is depressing to see this kind of mistake in a book targeted towards beginners. There is already enough confusion around packages.
Packages are not "multiple name spaces for symbols". A namespace is a set of bindings, and so a namespace for symbols would be a set of bindings for symbols, and that is the definition of an environment [1], not a package.
A package maps strings onto symbols, so technically a package could be considered a set of bindings for strings, though no one actually thinks of them that way and they are never ever referred to that way. Packages are data structures that map strings onto symbols. That's all.
One can only hope that this is an isolated mistake and not indicative of what goes on in the rest of the book.
---
[1] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo...
Definitely take your authority on this in general, just genuinely curious.
So with your beginner mindset on, imagine reading this sentence for the first time:
"The existence of packages (multiple name spaces for symbols) in Common Lisp is very important for allowing several people to cooperate in producing a large system."
Now, as a beginner, you don't know what "package" or "name space" or "symbol" means, though you might have some preconceived notions about these words. But embedded in this sentence is the "fact" that packages are name spaces for symbols (whatever that might actually mean), and so you tuck this little factoid away in your mind so you can try to make sense of it later because the author has taken pains to point out that whatever it means, it's "very important".
And then you read the rest of the book, where you find that the term "name space" is never mentioned again.
At this point you might find yourself scratching your head a bit. So on the one hand the author takes pains to call out packages as "very important", and tells you what they are, but then never bothers to explain what the words that define them actually mean. So you, being intellectually curious, go to try to find out so you go out onto the Internet to try to find out what a "name space" is. A reasonable place to start might be the definition in the Common Lisp Hyperspec:
> namespace n. 1. bindings whose denotations are restricted to a particular kind. ``The bindings of names to tags is the tag namespace.'' 2. any mapping whose domain is a set of names. ``A package defines a namespace.''
This seems promising, though it seems a bit odd that here a package defines a namespace, rather than a package is a namespace. Maybe "defines" and "is" are actually synonyms? But the bigger problem is that this definition is chock-full of new words which you as a beginner don't know the meaning of, most notably "binding". So you go to find out what that means, and your first step is to go back to the book, which turns out to be no help because despite the fact that it uses the word "binding" it never actually defines it, and also when the word is first introduced it is used as a verb, not a noun. So back to the Hyperspec:
> binding n. an association between a name and that which the name denotes. ``A lexical binding is a lexical association between a name and its value.'' When the term binding is qualified by the name of a namespace, such as ``variable'' or ``function,'' it restricts the binding to the indicated namespace, as in: ``let establishes variable bindings.'' or ``let establishes bindings of variables.''
Whoa! That's a lot of new words, starting with "name", which is hyperlinked so it has a definition of its own:
> name n., v.t. 1. n. an identifier by which an object, a binding, or an exit point is referred to by association using a binding. 2. v.t. to give a name to. 3. n. (of an object having a name component) the object which is that component. ``The string which is a symbol's name is returned by symbol-name.'' 4. n. (of a pathname) a. the name component, returned by pathname-name. b. the entire namestring, returned by namestring. 5. n. (of a character) a string that names the character and that has length greater than one. (All non-graphic characters are required to have names unless they have some implementation-defined attribute which is not null. Whether or not other characters have names is implementation-dependent.)
Double whoa! What is an "identifier"?
> identifier n. 1. a symbol used to identify or to distinguish names. 2. a string used the same way.
OK, at least now this is a short definition, with only two new words, SYMBOL and STRING. So what is a symbol?
> symbol n. an object of type symbol.
Well, that's not very helpful. And at this point you might be forgiven if you decide that this whole Lisp thing is not really worth the bother and you really ought to go learn Rust instead because that seems to be what the cool kids are using anyway.
The Right Way to explain this to a beginner IMHO is to start with strings because everyone has an intuition about what those are which is close enough: a STRING is a sequence of characters (which are a complicated topic in heir own right, but a naive view of what characters are is good enough to start with). A SYMBOL is a thing with a NAME, which is a string, and which cannot be changed. A symbol is created with a name, and it retains that same name forever. A PACKAGE is just a map, a function, from strings onto symbols such that the name of the symbol mapped from string S has the name S. This is significant because it insures that there is one and only one symbol with the name S in a given package at a given time. Packages are COLLECTIONS OF SYMBOLS WITH UNIQUE NAMES stored in a way that allows you to efficiently find the unique symbol with any given name in that collection. That's it (or at least close enough for a beginner). The reason this matters is that it allows different people to write code without stomping on each other. Alice can put her symbols in one package, and Bob can put his symbols in a different package, and so when Alice types "foo" into her code she can count on that referring to the One Symbol Named "foo" in Alice's package, and likewise when Bob types "foo" into his code he can count on that referring to the One Symbol Named "foo" in Bob's package. But these are nonetheless two different symbols (with the same name) and so Alice's code doesn't stomp on Bob's code.
That's it. ~250 words with no unfamiliar terminology for a beginner to have to scratch their head over (assuming they already know what a "map" or a "function" is).
But still, I get your point. Certain diligent students might read that statement and, rationally, read a lot into the terms "namespace" and "binding," and then get confused when they look up those terms in the hyperspec. It does come across careless in this way. But I just don't think, in itself, this would lead to a confusion about what packages are good for, or why they are used. Whether a beginner wrongly considers a package a namespace, or something like a namespace, wouldn't affect the way they would decide to actually use a package in their work. (Not to disregard how an experienced, real-lisp-understander might use their precise knowledge of the way packages work to make even better/cleaner/organized code.)
But either way, thank you for the thoughts, and please take my thoughts with a grain of salt.
After that, nobody in their right mind should be hanging on to any preconceived notion that they might have spun out of the earlier phrase "multiple name spaces of symbols", and should be reading the actual book.
Except that "namespace" is a term of art which is actually defined in the Common Lisp standard, and so it is not unreasonable to suppose that this is the intended meaning in a book on Common Lisp.
namespace n. 1. bindings whose denotations are restricted to a particular kind. ``The bindings of names to tags is the tag namespace.'' 2. any mapping whose domain is a set of names. ``A package defines a namespace.''
So if "the bindings of names to tags is the tag namespace", that means that a set of bindings of names to symbols is a symbol namespace!
According to the Common Lisp Glossary, the values of the dictionary define what the namespace is of. Of course the keys are always names; that's what makes it a namespace.
Also, look: "a package defines a namespace" (and it must be one of symbols).
You're not catching crafty old Shapiro red-handed in anything here.
No, that does not follow. Even if one were to admit the parallel construct here, the result would be "the symbol namespace" which is clearly nonsense.
Neither "tag namespace" nor "symbol namespace" is a term of art, so here we are in the domain of natural language, and natural language is irregular and ambiguous. In natural language usage, a "namespace for symbols" is one where symbols are the domain, not the range. In particular, the most common usage is to distinguish between Lisp-1 and Lisp-2, where the former has a single namespace for symbols and the latter has at least two, one for values and one for functions.
Thank you for pointing that out; I'll read the whole thing in context.
The correct view (in a language with mutable variables) is that it's an association between a name and an abstract location where a value is stored. When we assign to a variable, the binding doesn't change; any closure which has captured that binding sees the new value.
On entry into a lexical scope, fresh bindings are allocated only once, no matter how many times a new value is assigned to any of them in that same scope.
Schemers get this right. In R7RS:
An identifier that names a location is called a variable and is said to be bound to that location.
The problem is not just in the Glossary. defvar is documented as leaving the variable unbound if it is previously unbound (in the case when no initial-value is specified).
Yet, defvar is described as establishing the name as a dynamic variable. But a variable is defined as a binding. Thus if X is unbound and (defvar X) leaves it unbound, then it is not establishing a variable because that would require a binding. Oops!
Well, it would be if that is how CL actually defined the word "binding" but it's not. The CL glossary defines "binding" simply as "an association between a name and that which the name denotes". It does not specify that "that which the name denotes" must be a value, and in fact there are name spaces (collections of bindings) in CL where the things denoted by names are not values. The TAG namespace, for example.
The CL authors did make a few mistakes, but the definition of "binding" is not one of them.
And by golly, Shapiro's Common Lisp: An Interactive Approach does that. It has a chapter on Strings, then Symbols, then Packages.
a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 ~ ! @ # $ % ^ & * ( ) _ - + = { } [ ] : ; " ' < > , . / ?
Then talk about how stringing these things together in sequences can denote different things, but that these denotations are just conventions. For example, by convention we denote strings using double quotes:
"This is a string"
Note that there are two ways you can look at the above. You can see it as a sequence of 18 characters that starts and ends with quotes, or you can see it as a sequence of 16 characters that starts with T and ends with g. This ambiguity leads to a whole host of problems, not least of which is that if you want to write a string that includes a double-quote mark you now have to somehow indicate that the embedded double-quote does not denote the end of the string but it intended to be a constituent of the string, and the fact that the same character is used to denote both the start and end of strings was actually a catastrophic design error but we're stuck with it now because of the weight of history. (The Right Way to denote strings is with balanced quotes «like this» but that ship sailed a long time ago.)
And then, once the student understands strings, you can start talking about how some strings, like "123", stand for numbers, and how this is also just a convention, because strings like "123,000.00" look like numbers to any educated human but don't stand for numbers in any programming language except Microsoft Excel again because history, yada yada yada.
The point is, numbers are really really complicated, even more complicated than symbols, and they are definitely not the right place to start teaching any of this notwithstanding that this is where everyone starts.
Computer Science once used to be the same thing as Numerical Analysis; that has left a deep imprint on the education. Here is how we use Lisp: (+ 2 2) evaluates to 4.
I think that is debatable. When he introduces S-expressions in chapter 3 it is in the context of a chapter on lists, not S-expressions. (In fact, he doesn't have a chapter on S-expressions!) And he doesn't actually define S-expression, he only defines "list S-expression" and leaves it up to the reader to infer that numbers are S-expressions -- or is it the printed representation of a number that is an S-expression? Shapiro never actually says. So is 123 a number? Or is it an S-expression denoting a number? Are these the same thing? Again, Shapiro never actually says. AFAICT, at no point in the book does he ever make it explicit that an S-expression is a string, and in particular, a string which is a serialization of a data structure.
It makes sense to you because you already know how it works. You need to read it with your beginner-mindset hat on to see the problems.
In the Preface there is a paragraph Package Systems, S-expressions and Forms where Shapiro explains what those mean. It's clear that he's not using S-expression just to refer to compound syntax. The paragraph concludes:
In this book, I distinguish the S-expression from the form—the printed representation from the object—in Chapter 1 and continue making the distinction consistently and explicitly through the entire book.
There is only small matter there in that Common Lisp uses form for an expression in an evaluated context. What Shapiro wants there is "distinguish the S-expression from the (internal) expression".
Some of that paragraph also rather belongs in the book proper rather than the Preface.
Chapter 3 does not leave it to the reader to infer that number tokens are S-expressions. It says so explicitly: "According to this definition (1 2 3.3 4) is a list S-expression, since 1, 2, 3.3 and 4 are S-expressions (denoting numbers)". That's just re-iteration; prior material in the book hammered the point that the printed representation of any object is a S-expression.
---
* Well, a Lisp beginner's mindset. Not a programming beginner's mindset. If you already know things like that compilers scan textual numeric tokens, turning them into binary numbers, that colors the interpretation.
Yes, he does say that. The problem is that this is wrong. There are many printed forms of objects that are not S-expressions. In fact, these are so common that CL has some fairly extensive infrastructure for dealing with these cases.
S-expressions have nothing to do with printing (except insofar as Lisp makes an effort to maintain read-print consistency in some circumstances), they have to do with reading. They are operational at the beginning of the read-eval-print loop, not at the end.
There are many examples of #< notation in the book, but, as far as I can see, no remarks are made about what that means, or even that the contents of #<...> are implementation-specific and may appear differently. I don't see any discussions of the concept of print-read consistency, and so on: that objects can sometimes be printed in a way that either cannot be read at all, or worse, that produces a different object, like the #: notation.
It would help the book to talk early about print-read consistency. What it is, when do we have it, when do we not have it, in what situations can we provide it for ourselves when we don't have it, etc.
Compiling Lisp isn't covered in the book; there is only a cursory mention of compile-file. The omission is a lost opportunity to discuss Lisp's "interactive approach" to compilation. In compilation there is the issue of literals: what kinds of objects are externalizable. That relates to printing because externalization is a kind of printing. Compile-file has to print the literal objects into some kind of bits in the file, which then recover a similar object.
The word "image" doesn't appear in the book; it doesn't look as if image saving is mentioned anywhere.
Because I started in Lisp with that book (back in late 1999 or 2000? I can't remember), I was never confused about how packages and symbols work.
What the book does right is explain, early, that symbols are objects that have a name which is a character string, and which is different from the token syntax so that Foo and FOO and |FOO| are the same symbol:
Quote from the Symbol chapter:
> Returning to our discussion of symbols, every symbol has a print name, or simply a name, which is a string of the characters used to print the symbol. The name of the symbol frank is the string "FRANK". You can see the name of a symbol by using the function symbol-name
After that it goes into how we can get any characters we want into a symbol name, and so on.
Then, early in the Packages chapter:
> In this chapter, you will see that several different symbols can have the same symbol name—as long as they are in different packages.
Thanks to starting with this book, I had an accurate mental model of packages from the get go.
The "name spaces for symbols" phrase appears only in the Preface. Firstly, nobody should be taking a passing remark in the Preface as a lecture on how packages work. Secondly, the phrase has a straightforward interpretation which is squarely correct. A symbol has a name which is a string. That name exists in a namespace, which is a package. If we understand "name" to mean "symbol name" (and not "symbol used as a name") then a package is a namespace, and it is of symbols.
In that sense, a lexical scope is a namespace for variables and function bindings, and a class object contains a namespace for slots. Those namespaces are not for symbols, they are based on symbols being the names; i.e of symbols.
If you don't know anything about Lisp symbols and packages, and are reading only the Preface, you will probably not understand what exactly "name spaces for symbols" means; you will just have to read the book, and carefully go through the Symbols and Packages chapters.
No, they aren't. The strings "Foo" and "FOO" and "|FOO|" might be read by the reader as the same symbol, but then again, they might not. It depends on a great many things.
By default, all else being equal, yes, reading these three strings will produce the same symbol. But there are any number of factors that can change this.
Clozure Common Lisp Version 1.12.1 (v1.12.1-10-gca107b94) DarwinX8664
? (setf x 'foo)
FOO
[Stuff elided]
? (eq x 'foo)
NIL
[More stuff elided]
? (EQ 'foo 'FOO)
NIL
And I know that you know this. My point is not that you don't understand symbols or name spaces; I know you do. My point is that explaining this stuff is hard, and very few people seem to be willing to put in the effort. And this is not unique to CL, and it's not even unique to software, or even to STEM. It seems to be endemic in the human condition. But that doesn't mean one should not lament it or try to improve it.
The student will not encounter that unless they explore someone else's code, or discover the features like readtable-case and experiment.
Just talking about the default behavior, if it is stable and portable, and doesn't mysteriously flip behind your back, is fine.
You might think that it's an outdated piece of shit, maybe you hate RMS with a passion or whatever.
But make yourself a favour and use it at least for the month that will take you to go through a manual like this or Practical Common Lisp or several others. Just install SBCL, QuickLisp, Emacs and SLIME (or Sly, that is a more featureful fork) and start hacking. I promise that you won't need more than ten hours to get hooked. Maybe you'll eventually like Emacs.
If you're on Windows, watch this video right now:
https://www.youtube.com/watch?v=VnWVu8VVDbI
There's a moment at 12:52 when he invokes SLIME from inside Emacs. If you're confused how he does it, it's using Alt-x (or M-x in Emacs slang) and then writing "slime".
Also at 2:40, to make a persistent environment string, there's now an easier way: in PowerShell write "setx HOME c:\Emacs" or whatever directory you choose. I use "C:\Lisp" and I put everything related under it: sbcl, quicklisp, emacs and my own projects.
Other than that, even if the video is ten years old, everything works as advertised. That's true for most of the resources you will find around. Apparently nothing is showing much activity, but that impression is misleading. The core sbcl is getting relentless upgrades and the rest simply works.
For web stuff, use Hunchentoot. Remember that quicklisp makes super-easy to download libraries.
More interesting resources, apart what others have already mentioned:
https://www.youtube.com/@CBaggers/videos
https://www.youtube.com/@GavinFreeborn/videos
https://lispcookbook.github.io/cl-cookbook/web.html
#clschool at libera.net.
If some of the authors of those are reading this: a huge thank you!
https://www.youtube.com/playlist?list=PLTA6M4yZF0MzsMlNL0N67...
It seems I'll need to use the Air to follow the series. As far as I can see it's ccl + aquamacs + slime... right? It comes at the right time because I'm starting with the CLOS part right now.
https://cse.buffalo.edu/~shapiro/Commonlisp/
Shapiro mentions "An even more up-to-date, faster introduction to Common Lisp" therein, if anyone's interested.
> web links must point to this page rather than to a separate copy of the dvi, ps, or pdf file
As for Elixir: it heavily leans on the actor model. Understanding this was the biggest hurdle for me, but once I got over that learning Elixir was a breeze (though I was already comfortable with FP by the time I picked up Elixir). If you want to go the Elixir route, I recommend trying to play around with an actor model system in a language you are familiar with first. I was familiar with Scala so I learned the actor model by playing with Akka.
My #1 recommendation to you though is to go with Scheme and watch the SICP lectures. That will sneak functional programming into your brain without you even realizing it.
Anyway, I found myself doing REPL development using both Erlang and Elixir. Many of the benefits that I read about CL seem to exist within these languages as well.
I hope to explore CL eventually, but I'm just having too much fun with Erlang / Elixir at the moment.
CL isn't entirely functional, nor pure FP, you can mutate things (and can not to with some care, or with libraries) and you can mix styles (with OOP etc).