3 ms·
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
by hedora 3y ago
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).
- pfdietz 3y ago> is often interpreted Every competitive Common Lisp implementation has compilation. SBCL defaults to not even using an interpreter for eval.
- hayley-patton 3y agoSBCL 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 :)
- TeMPOraL 3y agoUnless 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.
- pfdietz 3y agoThis is reminding me there is the sb-fasteval feature, which I have not been testing.
- p_l 3y agoIt 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.
- dreamcompiler 3y agoAnd 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.
- medo-bear 3y agoworth mentioning is that CCL is finally back into active development !
- User23 3y agoI thought SBCL was a compiler only implementation? CMUCL did have an interpreter though.
- aidenn0 3y agoIt was until someone resurrected the evaluator it inherited from CMUCL
- phs2501 3y agoCMUCL'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!)
- pfdietz 3y agoSBCL 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.
- medo-bear 3y ago> 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.
- hedora 3y agoThe 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.