The ease of creating domain-specific languages. Consider a Prolog interpreter from PAIP or writing a pattern-matching macro that compiles to efficient code while remaining extensible using CLOS. Also writing programs interactively. But there's less reason to use Lisp with clangd integrated into editors such as CLion or Qt Creator instead of SLIME, as well as functionality such as
constexpr or variadic templates allowing for compile-time macros. It's not nearly as bad as Boost MPL of the old days so
Greenspun's tenth rule is less persuastive of an argument.
But now that mainstream languages borrowed features from functional languages, there's even less reason to use Lisp. It was more sensible back in C++98 days. Now JSON became mainstream and undoubtedly there are crazy people making interpreters based on it. It's a superset of Lisp syntax anyway. Everything-as-an-expression exists in Perl (the
do{} keyword and Rust. C++ looks like it solved the problem of closure upvar escape problem with move semantics, and so on.
Then there are some features that no languages borrow. Consider
RETURN-FROM which is as cheap as
longjmp(3). Technically Perl's
goto can be used in the same way but it's deprecated.
Funny, nowadays you can write
CONSTANTLY in C++ and use it in template-based generic code. Then the correct type gets inferred by the time code gets monomorphized.
In a few C++ standard iteration cycles we'll have tagged unions with
refutable (hopefully) pattern matching, something. Something Lisp never allowed.
