[massysett]

Because I can eliminate drudgery in a way I can understand.

I find that no matter what language I use, I eventually want code that writes code. Other languages have bad tools for this. Sometimes I use an editor, or something else like m4, to generate code.

Haskell has Template Haskell, which is icky in a variety of ways, and it has other stuff that I have a hard time figuring out because I’m not a math PhD.

In Lisp I just write a macro.

Also, I agree strongly with the post below. I like Common Lisp precisely because it is old and unchanging. I like that I can get decades-old used books that are still current. I like that the next compiler version won’t break my code.

https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/

[samatman]

On the strength of your first four paragraphs, I have to plug Julia. It doesn't have the benefit you point to in your fifth paragraph, of having a decades-old standard; stability of the core language is good so long as you aren't comparing it with C or CL.

But it has a full-fledged macro system, the kind where you can write an anaphoric if. It doesn't have the Zen of macros in a Lisp, but it has the power, and that's the important part. People have used it to add ML-style pattern matching and Pythonic f-strings, symbolic algebra systems which manipulate the source code, they're genuinely full-featured.

It also features multiple dispatch, every function is a multi-method and the type system is designed to support this. The community of practice is quite REPL-focused, although remote REPLs aren't as far along as they are in Lisp world. There are some cases where Revise can't invalidate old code, but most of the time it has the "hit save, use the new program" special sauce.

The core language is heavily inspired by Common Lisp, by way of Dylan, and it shows. There might be some other feature of CL which you miss, but it won't be macros.

[vindarel]

These points scare me: https://gist.github.com/vindarel/15f4021baad4d22d334cb5ce2be...

I doubt Julia gives as many image-based tools for the REPL (no conditions and restarts?), no single-file binary? I guess Julia's ecosystem is less rich than CL's outside of science.

[samatman]

I realized I didn't address one of the main things you said, which was about image-based tools. That's better as its own reply I reckon.

Depends on what you mean by "image-based". Julia doesn't support reloading core dumps, but it has pre-compilation, and it has Revise, which will do everything it can to keep the REPL state up-to-date with changes to the source code. My experience is that it always updates state (silently) or fails and tells you, and when it fails can be predicted: if you modify the layout of a struct, or change an enum, it can't track that, so the prompt will turn yellow and you'll have to restart. You get the same yellow prompt (instead of green, and this is configurable to use textual cues btw) if there's a syntax error, but in that case, you fix the code and press enter and it goes green again.

Revise evals the minimum amount of code to update the program state, this is instantaneous for all practical purposes.

The Julia REPL is a massive improvement over any of the REPLs which ship with open-source Common Lisps, and head and shoulders above what comes with most other languages. It is not yet up to the standard of a commercial Lisp, or of the Emacs SLIME-mode approach, but the community lives in the REPL (and notebooks), so I expect to see the polishing process continue.

[samatman]

It's a young language still. Pre-compilation has brought "time to first plot" down considerably, and ameliorated many (but not all) of the specific complaints in that gist. One stands out, which is "lack of pattern matching", Julia is a language like CL where a language feature can be a library. MLStyle is arguably the best but there are a few[0].

Similarly, there's a start (heh) on a condition and restart system[1]. Julia macros are actually full-strength and that makes up for a lot. I would say that "less mature" is a fair comparison with CL but "less rich" is more of a judgement call. When people are in a mood to be critical of Common Lisp, the richness of the package/system ecosystem is a frequent target of that critique.

Binaries which aren't enormous is a main focus of development now, as I understand the timeline 1.11 will bring modest improvements (in the next few months) and 1.12 will be relentlessly focused on achieving this, it's a recognized problem.

I find Julia completely suitable for general-purpose programming, right now. Moreover I see it on the right trajectory. My hope is that when the trigger is pulled on 2.0, this will include a standardization process, resulting in an actually-stable language by about 2030. Note that Julia is closer to Rust-stable than Python-stable already, post-1.0 code which runs on the latest version (1.10) is more common than not, but I do think compatibility needs to be broken, once, eventually, to fix some bad decisions. It shouldn't have to happen twice.

[0]: https://juliahub.com/ui/Search?q=pattern+matching&type=packa...

[1]: https://news.ycombinator.com/item?id=39377229