Why Lisp?

My main problem is with the “driven” part of “test driven”. I’m fine with aiming for pervasive coverage etc., but I disagree that tests are this amazing software design tool that the test-driven ethos seems to put forth. There’s something off in the cart vs. horse equation with that.

I also work in a REPL. For me, design usually starts well before code. Then the REPL will take me towards defining behavior via understanding and exploring particulars around a solution or set of alternative solutions. Then as some final step, I will assert that it does what it should do, and guard against possible future changes violating some assumption.

Somewhat! The authors talk about the longevity of CL, which is less a fact about lisp than an accident of history. Janet, for instance, is obviously quite new. Elisp is quite old, but I wouldn't use it for non-emacs development. Schemes are old, and while there are lots of one-off schemes which seem to be educational projects for their developers there are also lots of very old and battle-tested dialects (Chicken scheme comes to mind, Racket is old-ish and backed by its use in education).

The interactivity is fairly universal. Scheme in its smallest nuts and bolts doesn't care that much about interactivity, giving eval but no other real support for a REPL, but due to cultural effects pretty much every specific scheme is very interactive. I've seen complaints about every specific lisp I've ever used that it's not a real lisp because it doesn't support [extremely specific interactive option user integrated into their workflow in '93 and can't live without], but everything the authors talked about is likely to be present in just about every lisp.

A point the authors didn't make is that Common Lisp compilers are quite fast compared to e.g. C++ compilers. So even in rare cases where you do need to recompile everything, the cycle time is short.

CCL's compiler is lightning-fast. I can recompile an entire system in CCL almost as fast as I can load the compiled object code. SBCL's compiler is slower (while often generating faster code because it does more work at compile time), but it's still much faster than a typical C++ compiler.

You do get used to the syntax, at which point returning to languages that are prefix here, infix there, statements one way, expressions another, can wrinkle your nose a bit. But syntactic patterns are a question of emphasis; they establish a grain to go with. Lisp's syntax is so uniform as to have no grain. That puts more responsibility on you in exchange for high level flexibility—you can do things the way you want, and a creative method won't be against the grain like it might be in another language.

As for the recursion part, that's more true of Scheme, and it serves SICP's purpose of explaining that iterative and recursive processes can each be generated by recursive code. Common Lisp and friends do have iterative options for loops. But you will probably work in aggregate list operators more than touching a loop yourself.

As a Lisp fan who sometimes codes in Scheme and Common Lisp whenever I get the chance, I agree with you. The gap has certainly narrowed in the past 20 or so years between Lisp and widely-used programming languages. In addition, the rise of statically-typed functional programming languages like OCaml and Haskell provide another alternative for those who love functional programming but want Hindley-Milner types.

I still think Lisp, whether in the form of Scheme or Common Lisp (I haven’t tried Clojure), is quite enlightening due to the immense flexibility these languages provide. However, I’m reminded of the rationale of MIT’s decision back in 2009 to move away from SICP and Scheme in the intro CS course in favor of Python: the vast majority of developers aren’t building new ecosystems from the ground up, but are instead reliant on an ecosystem of libraries. Lisps are wonderful for creating whole worlds due to the powerful tools they provide. I’m currently working on a side project where Lisp’s flexibility comes in handy. But if I’m effectively gluing together APIs to build a solution (and this is not an insult), then do I need macros, MOP, multiple dispatch, and homoiconicity? Thus, many programmers do not need the full power of Lisp to get their jobs done. There’s also the fact that languages like Python and JavaScript have a lot more commercial and community backing than Scheme and Common Lisp.

If I’m writing something complex like a DBMS or web browser, then Common Lisp would be one of my first choices. However, if I’m writing a machine learning application or a web application, then I’ll most likely reach for Python or JavaScript, respectively, due to the library ecosystems.