- An excellent debugger and condition system!
- Code won’t be broken in 20 years (which I value when developing things like compilers). There’s one standard, and several de facto standard extensions.
- Almost 30 years of history, documentation, discussions, etc. Every corner of the language has been discussed to death.
- Several stable, mature, and independent choices of open source implementation.
- Implementations are written in Lisp all the way down. You can immediately jump to the definition of anything at any depth, and often edit or redefine to taste. (Example, I improved SBCL’s integer square root in my live image, and submitted a patch.) The only off-limits bits are a part of the runtime, like the garbage collector.
- Several independent choices of commercial implementation and commercial support.
- Generally easy to optimize and micro-optimize code. Easy to edit/disassemble/debug.
- Easy to write assembly code with SBCL.
- Fast start-up time, easy to compile into native executables. No JIT lags.
- Excellent IDE support through Emacs and SLIME. Incremental development is real with Lisp, and absolutely not so with Julia.
- Easy to dynamically generate and compile code at runtime.
- Excellent metasyntactic programming facilities. (Macros, symbol macros, reader macros, ...)
Negatives compared to Julia:
- Poor support for numerical libraries and poor support for plotting, much to the chagrin of a scientific programmer like myself.
- No hip website or hip foundation backing it.
- Quiet community, with very broad interests. Not everybody is rallying around one theme in Lisp. You got database programmers, game programmers, scientific programmers, etc. This could be a positive, if the community were larger.
I'd add even the GC is accessible if you have the knowledge. Grammarly has a blog post that talks in part about manipulating parts of the GC to achieve higher through put by keeping heap objects (I think!) from reclamation.
"Escape from the Heap: Low-Level Programming in Common Lisp" https://www.youtube.com/watch?v=S7nEZ3TuFpA
On my desktop, SBCL will compile itself from source and run the small version of its test suite in 90 seconds.
These benchmarks may not apply for every use case, but at least they suggest that Julia is roughly as fast as compiled Lisp.
From my perspective, Lisp falls into the third tier of programming language speed.
First tier (speed wise) of commonly used or discussed programming languages on HN are C++, C, and Rust. These have the performance for almost any task but require significant development effort.
Second tier languages trade off a bit of speed for other conveniences. These include Ada, C# and Java. Definitely slower than first tier, but easier to use in their own domains of use.
I do a lot of programming in Python3 because it is just so expressive; speed wise, it occupies the forth tier with Ruby and Lua. The relative slowness isn’t a problem for many tasks and Python is really fun to program in.
Speed isn’t everything. While in grad school, for fun, I wrote a program to generate programming language parsers. Unfortunately, this was in 1974 using punched cards and the only language that I had access to was FORTRAN IV or assembly language—both very fast languages. I never got the program to a useful level of functionality (my goal was a LALR parser generator). If I had Python, it would have been a different story.
https://news.ycombinator.com/item?id=19750507 (picked the discussion because combining the optimizations of two people CL got to Julia level, though Julia code is correctly written but not particularly optimized)
https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (the more direct comparison)
And saying CL is fast because you can write in assembly is like saying Python is fast because you can write in C. And while you can't write in assembly in Julia, you can go down all the way down to the LLVM (and intercept the compiler right between detecting types and compiling so you can rewrite every intrinsic with your new backend in a more flexible way than multiple dispatch) like they did with XLA.jl for TPUs and CUDANative for GPUs.
Julia allows inline LLVM IR, so this is technically possible, if a little awkward: