> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp
- you write some piece of software
- then you add a straightforward configuration language
- then you add variables because you don't want too much copy/paste
- then you add if statements to allow conditional configuration
- then you add loops because you are sick of seeing configuration that consists of unrolled loops
- ...
At some point your configuration system is Turing complete, so could be considered a programming language. However it was never designed as such, so it is not a horrible one
TeX would be a good example of this. Ansible playbooks are (I believe) Turing complete, and YAML itself has such a huge spec, that if it isn't Turning complete and/or self aware already, I can't imagine it'll be long before it is
And what about Lisp is enduser friendly? Configuration files are intended to address people that are programming-lite to poweruser-not-programmer level. Lisp s-expressions are recursive tree structures with prefix ordering, which is a "great filter" for the IQ of users.
Greenspun's law, being a joke of Lisp users, actually indicates the inability of the Lisp community to understand why their language is niche to ultra-high-IQ people. If syntax patterns, formats, and programming languages survive for decades, there is a grassroots practical reason for their existence that ironically the ultra-smart all-knowing Lisp hacker just can't properly fathom.
It's not, it's developer-friendly. A basic Lisp interpreter is like a few hundred lines of code, so it's a very tempting system to embed. I think Lua is similar, but I haven't messed with it.
It's also powerful enough that most things aren't incredibly awkward to specify in it. YAML/JSON/TOML/etc have issues expressing repetitive things that can be solved in a for-loop/map in Lisp.
I don't even think Lisp should be an IQ filter. I wouldn't call myself a great or even good Lisp programmer, but the prefix syntax and s-expr's aren't all that hard to pick up. I don't think it's any more difficult than JSON, although it is far less common.
I think that's much more stereotype than reality. People see all these parentheses and think that it must be a difficult language that requires a big mindset shift, like these purely functional languages with dependent types. In reality, it takes a week or two, plus an editor plugin that highlights matching parentheses, to get used to writing (function arg-one arg-two) instead of function(arg_one, arg_two). After that, it's smooth sailing. Just another decently designed language that's dynamically but strongly typed. Feels like writing Python, except with a bit of metaprogramming from time to time.
I think you're overestimating the importance of syntax and underestimating semantics. It doesn't take a very long program to get bitten by bad semantics. A few years ago, I was writing a game extension in Lua. It was only a couple hundred lines, and I still wasted hours debugging problems that would've been one minute fixes in Python or Lisp. All because of Lua's ridiculous idea of conflating arrays with hashtables, plus its habit of returning nil instead of raising an error when you do something that doesn't make sense.
If you can fog a mirror, you can probably edit Lisp.