
The Common Lisp Cookbook - macco
https://lispcookbook.github.io/cl-cookbook/
======
jlarocco
For a more modern and up to date guide, Edi Weitz's "Common Lisp Recipes" is a
great reference: [https://www.amazon.com/Common-Lisp-Recipes-Problem-
Solution-...](https://www.amazon.com/Common-Lisp-Recipes-Problem-Solution-
Approach-ebook/dp/B01JFTONBS/ref=mt_kindle?_encoding=UTF8&me=)

The more I use Common Lisp, the more disappointed I am that it hasn't become
more popular. It really is higher level than Python, Ruby, or Perl but with
nearly the performance of C and C++.

~~~
nerdponx
As someone currently learning CL, I think part of the reason it doesn't have
widr adoption is that there is a huge number of features.

Consider a language like Python. Aggressive duck typing means consistent
syntax for different data structures and types. Stuff "just works" without a
deep understanding of _how_ it works.

CL is the opposite. What is the difference between setp, setf, defvar, and
defparameter? Why is the documentation so technical and dense? What is a
"form"? What are multiple return values and how do I get to them? Should I
spend time learning the loop macro DSL?

I find it similar to Haskell in this regard. The base level of knowledge to
use the language is so high that you pretty much need a book, or a degree, to
be able to get started. That's a huge barrier to entry.

~~~
TeMPOraL
> _Stuff "just works" without a deep understanding of how it works._

> _The base level of knowledge to use the language is so high that you pretty
> much need a book (...) to be able to get started._

I wonder what that says about developers these days.

Ever since I started 'till this very day, it was obvious for me that if you
want to learn something, you go pick a _book_ about it. Books aren't scary.
They have one of the highest knowledge-transfer-to-time ratios out of any
sources you could find; they easily beat videotutorials and text tutorials.
Most programming books I've read are also quite pleasant and easy to follow
(better than some novels I've read...).

Are people _scared_ of books these days?

I mean, I accept that the power of a tool can be a limiting factor to
adoption, but I'm deeply saddened by it. Learning and understanding things
isn't hard.

\--

> _CL is the opposite. What is the difference between setp, setf, defvar, and
> defparameter? Why is the documentation so technical and dense? What is a
> "form"? What are multiple return values and how do I get to them? Should I
> spend time learning the loop macro DSL?_

The answer to that is simple: go and read _a book_ :). _Practical Common Lisp_
is available on-line for free, and it's a current best introductionary book
for CL.

[http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/)

~~~
oblio
I think most people learned programming by doing stuff, not by reading books.
Basic, Bash, Perl, PHP, Javascript all agree with me...

~~~
TeMPOraL
You can't learn programming _without_ doing stuff, but to understand _what_
you're doing, you need to learn some facts - and books have one of the best,
if not the best, ratios of learning to time spent.

(In fact I'd be worried to work with programmers who didn't back their
experience in their primary language(s) with at least one solid book.)

~~~
oblio
Yeah, but you're talking about good programmers.

Do you really think that all the others really read books? :)

------
pnathan
Oh hai Hacker News!

vindarel on Github has been doing an _enormous_ amount of contributions in the
past two weeks, and the modern look and feel (and some of the more modern
content bits) are _entirely_ due to their hard work.

eudoxia0 spent some time prior to that converting it and getting it
modernized.

I'd like to congratulate them on their work, since we're on the front page of
HN.

(I sort of steward the GH fork of the cookbook these days).

------
daly
A Standard. One thing that has not been mentioned here. The lisp community
came together and created a standard.

I maintain code from the 1980, part of which is in Common Lisp and part of
which is in C. The C code breaks. The latest failure seems to be caused by the
GCC compiler changing the semantics of 'inline'. The include files differ
between platforms.

The Lisp code just runs.

There are no arguments like Python 2.7 vs Python 3.x. No arguments about C++11
vs C++14. No arguments about Clojure from 4 years ago and Clojure today. No
arguments about any of that.

There is a standard. ONE standard. It only matters when you have to maintain
someone else's legacy code. But it really matters.

~~~
rurban
Well, amongst Lispers we do argument a lot about the missing or
overarchitectured bits. The ffi, threads, the conditions system, the MOP, ...
But only the various FFI's pose a minor problem. It's complaining on a very
high level.

~~~
daly
Probably the most difficult area in the CL standard is handling pathnames.
There are so many possible pitfalls. FFI is an area that, despite best
efforts, is likely not a good candidate for inclusion in a standard. It would
be better to have all of the implementations converge on a convention since
the underlying foreign systems will change over time. Not everything that
"just works" has to be in a standard.

C++ issues a "new standard" every 3 years or so which is just nonsense. Even
Stroustrop said that the "new C++" is not the "old C++". They are adding ideas
(e.g. Concepts) that virtually no one is asking for or knows how to use. Ten
years from now that C++ maintenance job you have will be a nightmare. PL/I
tried to be everything to everyone for every task and eventually disappeared.
C++ is on the same long-term death march. You heard it here first.

------
laxentasken
Started looking at getting into Racket and CL after reading up on lisp and
there is something about it that really bugs me, in a good way. Sadly the
train seems to have left the station regarding positions where you use lisp
where I live. All is java and C-flavors.

~~~
TeMPOraL
> _All is java_

Possible tip: sneak in ABCL when they're not looking. ABCL is a Common Lisp
implementation for JVM, with (what seems like) relatively OK interop between
Lisp and Java code.

~~~
nikofeyn
why would one do that instead of using clojure?

~~~
TeMPOraL
Because as 'klibertp wrote, they're two vastly different languages, with
different design decisions.

The whole thread is about primarily Common Lisp; people who enjoy the design
choices made by the CL standardization committee and subsequent evolution of
the language's ecosystem would most likely want to know that there exists a
proper CL implementation for JVM.

~~~
nikofeyn
but the person i replied to replied to a commenter lamenting the fact that
there was nothing but java and c style development jobs instead of lisp
inspired jobs. they weren't lamenting the lack of jobs specific to just common
lisp. and to me, it doesn't make sense to "sneak in" an esoteric
implementation of lisp on the jvm when clojure already exists. what makes
people think that would be easier to sell at a place using java heavily?

~~~
TeMPOraL
I wouldn't call ABCL esoteric; it's as rightful JVM citizen as Clojure or
Scala. That said, I agree it's _much, much_ less popular in the JVM world, so
it could be a harder sell.

------
znpy
Hi, don't mean to interrupt anyone, just wanted to ask: why hasn't anyone made
the common lisp hyperspec a prettier, more navigable and tooling friendly yet?

~~~
coryrc
The license doesn't allow that.

Yes, that's dumb.

~~~
lispm
See the CL UltraSpec for work in progress:

[http://phoe.tymoon.eu/clus/doku.php](http://phoe.tymoon.eu/clus/doku.php)

It's based on the last pre-ANSI CL standard sources.

------
fokinsean
I've never ventured into a lisp like language. Would you recommend starting
with common lisp or is jumping into clojure ok?

I have been in the JS, Java, Python world for a while and this looks like a
language that could stretch my brain a little bit.

~~~
reikonomusha
If you want your brain stretched, I recommend Common Lisp.

The #1 issue for folks in my experience had been getting an environment set
up. Emacs, SLIME, encodings, paredit, ... . It's a big barrier to entry.

~~~
TeMPOraL
I agree (I know I had my issues with Emacs and SLIME when I started; being on
Windows didn't particularly help).

That said, for people who want to start with CL now, I'd recommend grabbing
[https://shinmera.github.io/portacle/](https://shinmera.github.io/portacle/).
It's a portable Lisp IDE based off a pre-configured Emacs + SLIME + SBCL +
Quicklisp + Git combo. I can confirm that it Just Works, out of the box.

~~~
brudgers
Portacle is a great project. My concern with it as a recommendation is that
Lispbox was a great project too, until it wasn't...or rather that the
enthusiasm of the maintainers of easy to use Common Lisp projects seems likely
to be shorter lived than Common Lisp (though perhaps Github may make this less
a potential problem). The fact that people get paid to improve and maintain
the Racket ecosystem as part of their day jobs in academia is one of the
reasons I recommend it for 'how should I start exploring Lisp' (versus
learning Common Lisp).

[https://common-lisp.net/project/lispbox/](https://common-
lisp.net/project/lispbox/)

~~~
TeMPOraL
> _the enthusiasm of the maintainers of easy to use Common Lisp projects seems
> likely to be shorter lived than Common Lisp_

Not surprising, given that Common Lisp itself is pretty much immortal compared
to the typical lifetime of things in our industry :).

That said, I know what you mean. I started with Lispbox years ago, and it was
already feeling its age back then. I agree with your observation. Sadly, the
commercial CL scene seems pretty weak - the two big players (Franz and
LispWorks) seem to mostly keep to themselves and focus on the commercial tools
they offer.

~~~
brudgers
One of the 'legacy' features of the Common Lisp community is that it is
socially acceptable to charge $2000 per year per seat for software. Though it
is not something that I personally have a problem with, my view that paying
for software is ok is not all that mainstream these days (imagine paying for a
web browser).

What I like about Common Lisp is that it is not in flux and so when I Google
up a question, the information I get may be ten years old but it is highly
likely to be correct. The price is that the format of the information may be
more like a technical textbook than a blog or a StackOverflow answer.

