
ANSI Common Lisp (1995) - todsacerdoti
http://www.paulgraham.com/acl.html?viewfullsite=1
======
mr_luc
I feel like the Common Lisp and Erlang communities have produced writing about
software that has really stood the test of time.

From the CL spec, to Norvig's "Paradigms of Artificial Intelligence
Programming: Case Studies in Common Lisp," to both of pg's CL books (this one
and 'On Lisp') -- these all feel readable, even re-readable, and entertaining.

And of course the same can be said of the Erlang books -- I'll read anything I
find by Joe Armstrong or Robert Virding.

In both cases, authors are able to joyously present the language's unique
superpowers and ways of thinking (CL-style macros, OTP). But I think a crucial
factor is that, since both languages are very practical -- in terms of their
reason-to-exist, as well as what they provide 'out of the box' \-- the writing
tends to be imbued with the energy and possibility of actually building
things.

~~~
agumonkey
Both came of academic roots (mit/ai, and prolog influences for erlang), to me
it gave a very dry but highly structured conceptual foundations. I mean lisp
is mostly tree recursion everywhere. Unlike simpler languages that were use-
case driven, and iterated over the absorption of better concepts over time,
waving between fads.

~~~
dreamcompiler
> I mean lisp is mostly tree recursion everywhere.

Two things:

1\. This isn't true. Common Lisp style emphasizes looping; Scheme emphasizes
recursion.

2\. What's wrong with tree recursion anyway?

~~~
zerr
Many think/prefer that it is a compiler's job to convert conveniently (Algol-
style) written program into AST, even if this reduces the macros capabilities
- even Norvig switched to Python long time ago :)

~~~
dreamcompiler
Some of us find that writing ASTs directly with a smart editor is much more
convenient than writing Algol-style languages.

Norvig switched to Python when he left NASA and went to work for Google. He
wasn't going to convert Google's culture to one that embraced Lisp.

~~~
kesava
This is potentially such a Annie Hall Marshall McLuhan moment. Here's hoping
@norvig pops in and replies to this thread.

------
tazjin
Well, if we're doing a generic Common Lisp thread some of you might be
interested in buildLisp.nix[0], my project to write a build system for CL in
Nix[1].

The idea here is that Nix should be usable for builds at the same abstraction
level as Bazel (i.e. individual build targets), while retaining the power of
the rest of the ecosystem.

Example build "manifest" using buildLisp.nix:
[https://git.tazj.in/tree/third_party/lisp/alexandria/default...](https://git.tazj.in/tree/third_party/lisp/alexandria/default.nix)

This has a few additional neat benefits, such as making it possible to easily
spin up a REPL with the correct Lisp & dependencies loaded from within
Emacs[2].

There's also a similar project I did for Go[3] to prove the general viability
of the concept.

[0]:
[https://git.tazj.in/tree/nix/buildLisp/](https://git.tazj.in/tree/nix/buildLisp/)

[1]: [https://nixos.org/nix/](https://nixos.org/nix/)

[2]: [https://git.tazj.in/tree/tools/emacs-pkgs/nix-util/nix-
util....](https://git.tazj.in/tree/tools/emacs-pkgs/nix-util/nix-util.el#n69)

[3]:
[https://git.tazj.in/tree/nix/buildGo/README.md](https://git.tazj.in/tree/nix/buildGo/README.md)

~~~
fmakunbound
Lisp user here. Scratching my head on this one: What's it build exactly? Why
would I use this over, say, Quicklisp? Is this just a Nix thing?

Edit: Also, why do you need to specify all the .lisp files in the build(?)
file?

~~~
tazjin
> What's it build exactly?

For libraries, it builds an output with a concatenated FASL for all inputs
(which reference the sources by their exact hash in the Nix store, which means
that they will be distributed alongside).

For programs, it dumps an executable image (save-lisp-and-die with
`:executable t`).

For `buildLisp.sbclWith` it creates an SBCL that loads an image pre-loaded
with all the dependencies.

> Why would I use this over, say, Quicklisp?

Quicklisp is one small bit of the puzzle (the distribution of packages using
ASDF).

Using Nix for the task replaces Quicklisp, ASDF, your distribution package
manager used to install your Lisp, your distribution package manager used to
install native dependencies of your Lisp code (e.g. cl+ssl with openssl[0]),
your deployment tooling and generally your entire software packaging and
distribution stack which leaves you with one homogeneous system that is easily
composed across language boundaries.

> why do you need to specify all the .lisp files in the build(?) file?

I modeled this after the way Bazel rules are normally written, where
specifying each source file is common. In fact, ASDF does this too.

[0]: [https://git.tazj.in/tree/third_party/lisp/cl-plus-
ssl.nix#n2...](https://git.tazj.in/tree/third_party/lisp/cl-plus-ssl.nix#n22)

------
scottmsul
I read through much of this book as a fun hobby/side project. I felt at times
this was a book written by a genius for geniuses... For example, there's a
chapter on numerics. Simple, right? PG's "example" was a full ray-tracing
library in only about three pages. There were single pages that took me an
hour to read and understand fully. Very cool/fun stuff, but also extremely
terse, especially if you're new to lisp.

------
the-alchemist
I wonder what Paul Graham thinks of Clojure, which is the only Lisp I really
have experience with.

I love being able to take advantage of all the wonderful Java libraries out
there. Nowadays, I think you can even use Python libraries from Clojure [0].

[0]: [https://github.com/cnuernber/libpython-
clj](https://github.com/cnuernber/libpython-clj)

------
nabla9
ANSI Common Lisp is good book to learn Common Lisp.

I especially like the Appendix D: Language Reference. CL already has very good
and comprehensive reference: the Hyperspec, but the Reference in the book is
good companion to to it, very much like cheat sheet. You can quickly look up
things. (my copy is already braking down from the end)

~~~
lispm
There is also a Common Lisp Quick Reference for self-printing:

[http://clqr.boundp.org](http://clqr.boundp.org)

------
triclops200
If anyone is interested, this is a project you can use to generate a nice
template for a compilable common lisp project for Linux that uses sbcl, which
really reduces the initial setup pain for new projects:
[https://github.com/triclops200/quickapp/](https://github.com/triclops200/quickapp/)

And this is a project that uses that to make quickapp itself a binary you can
install: [https://github.com/triclops200/quickapp-
cli](https://github.com/triclops200/quickapp-cli)

Both of these projects need a little TLC as I haven't touched them in a while,
but they should still work.

------
mxyzpt1k
I have a copy for home, one for work, and one to lend. "On Lisp" by the same
author is a wonderful glimpse into the power of macros.

~~~
kristianp
You use it at work?!

------
elteto
I want to give Common Lisp a try. My previous experience with Lisp (any
variant) is almost nil. Would this be a good book to start with?

~~~
lanternslight
Try Practical Common Lisp or Land of Lisp instead. They are both much more
accessible. Then read ACL.

~~~
jgalt212
Seconded, Practical Common Lisp was instrumental getting me to think in a
sound modular fashion.

------
3fe9a03ccd14ca5
Why is lisp still so uncommon today as a practical, business-needs language?
Everyone I know who uses it loves it, but it’s virtually nonexistent in
today’s enterprise.

~~~
w3mmpp
Things could change though when you look at the landscape of computer
languages today:

\- OOP is trending downward, and for good reasons, look at Java and C#, too
verbose, too top-down.

\- dynamic languages are not efficient enough, especially in the cloud where
they require 10 VM to do the work that could be done on a single machine with
lower level languages.

\- c/c++ are too low-level, hard to master/difficult to maintain.

\- Rust is a mess, too verbose, too complex.

\- In the FP universe, which is trending up, Haskell is too complex, F# is
good but the libraries (.NET) are OOP mainly so the integration sucks.
Clojure, not sure, didn't play with it but my guess is it suffers the same
problem than F#.

So, personally, and not trying to convince anyone here, lisp, and especially
Common Lisp with its large number of available libraries and its good
development environments (emacs/slime), is getting more interesting every day.

~~~
F-0X
Just want to throw D into the ring as a candidate here. It's a smashing
language. I think it satisfies the very compromise you are seeking from your
evaluations of other languages.

~~~
w3mmpp
Thank you for reading me so well :) It's a very interesting language for sure,
checks a lot of boxes. How is the market trending for it job wise? What I'm
finding online so far seems pretty mixed.

