Hacker News Reader

Comment by hedora | Hacker News Reader

Java took over by targeting large teams of inexperienced developers.

C++ took over by adding OO to C with zero cost abstractions, and then evolving into modern C++ (which discourages OO and encourages composition via template instantiation) without leaving programs behind.

Lisp has supported composition forever (it is one of the big advantages of functional programming), and the macro language is similar to templates. I think the big problem is that it is difficult to scale lisp projects with inexperienced developers (loses to java) and is not zero cost (has a GC, is often interpreted; loses to c, c++ and now rust).

View on HN

> is often interpreted

Every competitive Common Lisp implementation has compilation. SBCL defaults to not even using an interpreter for eval.

SBCL eval interprets until you hit a lambda form, at which point it will compile (last I checked). But you are much more correct than who you replied to :)

Unless I'm misremembering, this is only true in REPL, which should be better read as "SBCL is actually sometimes *AoT-compiling in interactive REPL sessions!!!"; #'LOAD-ing files would AoT-compile them by default.

This is reminding me there is the sb-fasteval feature, which I have not been testing.

It didn't use to - for various reasons, evaluator inherited from CMU CL had bitrotted at one point, and for many years every form more complex than essentially single function call resulted in compilation.

Few years ago there was work to fix the evaluator and now EVAL has limited evaluation back.

And CCL doesn't even have an interpreter. Every form you type into the REPL is compiled. If you want an interpreter in CCL you have to write it yourself.

worth mentioning is that CCL is finally back into active development !

Who is doing the development currently?

Matthew Emerson

https://lists.clozure.com/pipermail/openmcl-devel/2024-April...

I thought SBCL was a compiler only implementation? CMUCL did have an interpreter though.

It was until someone resurrected the evaluator it inherited from CMUCL

CMUCL's interpreter evaluated IR1 (the first intermediate representation of its compiler) IIRC, so it wasn't possible to have a truly compilerless CMUCL _and_ a functional EVAL. I believe this IR1 interpreter was dropped from SBCL very early on. When SBCL gained an interpreter again it was a simple metacircular evaluator a la SICP that was unrelated to anything inherited from CMUCL. (This is all as of 15 or so years ago, I'm sure things have evolved since then!)

SBCL has two evaluators now, sb-eval and sb-fasteval. I don't know how much structure they share. By default it builds with sb-eval, but this can be changed with options to make.sh. sb-ext:*evaluator-mode* is still :compile by default.

> I think the big problem is that it is difficult to scale lisp projects with inexperienced developers (loses to java) and is not zero cost (has a GC, is often interpreted; loses to c, c++ and now rust).

i think scalability problem is a bit overstated. the biggest issue with lisp becoming popular is that it doesn't have a large user base and is not a new language like rust. however despite being old, common lisp /still/ has so many 'novel' things in it that in metrics of programmer ergonomics and programming user interface make common lisp a big winner for me.

as regards zero cost, lisp programs can be made arbitrarily close to being zero cost, but here be deamons.

The big team thing matters for two reasons:

First, it implies lots of people are paid to learn it. Second, it implies companies will have to invest in adding/fixing support libraries.

Reply on news.ycombinator.com