SBCL – Past, Present, Future [pdf]

But, additionally, CL makes binding to C libraries really easy via CFFI and things like cl-autowrap ( https://github.com/rpav/cl-autowrap ) so, when there isn't a native lisp library, it's often easy enough to just use a C library in your program (or, I suppose, anything that can compile to something compatible with C like `extern C` in C++ and the equivalent constructs in Rust)

I use and like it quite a lot.

Re startup time, maybe you prefer to run on JS. See eg https://github.com/anmonteiro/lumo

(Though you can also use GraalVM to get fast startup time on prod builds of JVM Clojure projecs)

Language is not big compared to python or something.

Technically it is a lisp-n not a lisp 2, doesn’t matter in a practical sense.

Optimization of tail recursion isn’t in the spec but is done in some compilers. Loops are encouraged, as is mutation, objects. It’s truly multi-paradigm.

It is very powerful, so in some ways it ruins you when you have to go back to writing python code, adhering to ‘PEP 8’ Standards, and people looking over your shoulder at code reviews.

Common Lisp has the potential to be freewheeling and exploratory in a way that other languages still do not.

I think of something, therefore I write it and it exists. There isn’t a lot of hemming and hawing about ceremony and rigor.

I like that feature of Common Lisp... it is my own patch of the Wild West, to some extent.

A lot of people think that if something isn’t difficult and tedious, it isn’t really software engineering.

They may be right, but I prefer whatever this non-engineering discipline is to what I’m doing now.

Common Lisp is probably in its best shape ever. There is finally a good package manager (https://www.quicklisp.org/), plenty of documentation (https://common-lisp.net/documentation), and active communities on reddit, #lisp and elsewhere (http://planet.lisp.org/).

There is and has always been a lot of FUD around Lisp, and Common Lisp in particular. You even mentioned a few examples. My explanation on why this is the case is that learning Common Lisp really takes some time and dedication, but our lazy brains try hard to avoid that and find silly excuses instead (Too many parentheses!).

> are there any compelling reasons for an average Joe programmer like me to start learning Common Lisp in 2019?

If you manage to use Common Lisp in a project, you get an enormous boost to productivity. It is the best language for 'getting stuff done' that I know of. Even if you cannot use Common Lisp directly, knowing it will stop you from reinventing a lot of wheels. Greenspun's tenth rule is real.

Encountering functionality you’re not familiarized with is pretty much the norm in all projects and I’d rather encounter something that is part of the core language (bonus point if it’s a standard) than a self rolled abstraction or some other library.

It is no coincidence that I always end up working with ugly and so called kitchen sink languages and prefer Perl over Python, C++ over C, Common Lisp over Scheme, Rust over Go and OCaml over SML.

I like the idea of designing and using languages with a small set of orthogonal abstractions but looking back at the whole Scheme fragmentation and my experience with past and current projects written in Forth, C and Go that started fine but turned pretty fast into maintainability hell I think it’s utopian and futile.

I’m not ashamed to say that I like ugly and messy and that I encourage those in doubt to dive in and enjoy the kludge that Common Lisp is.

One of the things that stands out for SBCL is its optimizing native code compiler. For a dynamic Lisp-like language implementation it provides outstanding amounts of help: useful error messages, warnings, optimization hints, static checks, etc. One throws large amounts of codes on it and it returns with even more messages... ;-)

The old criticisms of Lisp being too big were compared to Scheme & C, and it is definitely much larger than those two are: why, it defines modules & hash tables and has objects! Racket is actually a pretty neat system which is basically Scheme-plus-a-lot; I wouldn’t be surprised if it’s actually larger than CL.

I don’t know how Clojure would compare, but I imagine that it’s comparable.

Not that compared to language like Go or Python, Lisp is very much not big. It doesn’t have built-in email, or HTTP and that kind of thing (but there are good libraries available for almost everything these days).

> - Lisp-1 vs Lisp-2

Most language these days have a single namespace. Honestly, though, I think that’s a mistake along the same lines as most languages these days lacking a symbol type. https://www.dreamsongs.com/Separation.html is a nice overview of the arguments in both directions.

I like being able to easily add my own new namespaces to the language.

> - recursion discouraged (is that even true?)

I don’t believe it is. Recursion is just one more tool in the toolbox. Note that while the standard doesn’t mandate tail call optimisation, many implementations implement it anyway.

> - There is a thing called "Lisp Curse"

I think that applies to any Lisp-like language, not just Common Lisp. For some reason people’s brains turn off when they see:

    (if (foo x)
      (bar)
      (baz))

    if foo(x) {
      bar()
    } else {
      baz()
    }

I think that it’s still the best language out there for delivering quality, well-forming software which can run in a dynamic environment and handle dynamic situations. I professionally program in Go — and I enjoy it — but I would rather program in a Lisp implementation which adopted goroutines, channels and interfaces[0]. I would rather use something like an eshell which had a few man-years of work on it than zsh, and I’d rather use something like a next-gen Lisp scsh than sh.

There are some great languages out there: ML, Erlang, Lisp. They are each worth learning, worth using.

0: there are threading and channel libraries already, but I honestly don’t know what interfaces would look like in a dynamic language; I do know that I love them in Go.