I ..just... learning s-expressions isn't hard. At all. Its a made up thing and I think people cling to it because it gives them an out, they don't want to feel dumb or uninteresting in their work (understandable). As far as who learns lisp these days, while Clojure may not be doing Python numbers in terms of adherents, it is absolutely used in increasing numbers in business software, has multiple decent sized conferences and forms the back bone for a number of large open source projects. Its also used as a foundation for a lot of devops and build-tools type work. Racket scheme is used by at least a dozen universities for everything from intro to programming classes, to advanced semantics and compilers classes. On top of that there are a suite of new tools written recently (last few years) in Guile which are slowly gaining ground (Guix being the main one), Chez was recently opensourced (and is being integrated into Racket), Common lisp is still used all over and, wait for it, emacs isn't going anywhere. Lisp isn't the specialist tool or old ("grizzled") standby its purported to be. I think this is some message board logic, honestly. Not trying to be overly hostile or antagonistic, I just don't see the scene/market/environment in those terms. For example, I just discovered an extremely interesting but kind of weird embedded lisp in the wild several months ago! Its a scripting extension to a binary analysis framework that doesn't have first class functions, but does utilize meta-programming to drive a term-rewriting engine that executes single instructions on an emulator. Awesome, and strange, and, as far as I've been able to tell, not noted anywhere people draw up lists of lisp implementations (its been out, open sourced for almost 7 years that I know of). Lisp is kind of everywhere, it just doesn't have an organized messaging clique pushing awareness constantly everywhere (thankfully).
Right. Who are these people who do (numpy stuff) linear algebra, svd decomposition, pseudoinverses, linear regression, machine learning, but see a S-expression and immediately give up?
Mathematicians aren't averse to learning syntax, but they're lazy.
They learned that stuff because they are either basic methods in the field that have demonstrated value, or what they're actually doing research on.
The syntax buys them power that they wouldn't otherwise have, and they can smell it.
S-expressions? Not so much - the notation is more or less and arbitrary choice unless you're going to leverage the metalanguage capabilities to the hilt, and there are many other programming approaches available.
A mathematician who really wanted to jump into the deep end with programming syntax/structure would much more likely pick up Haskell (categories, yay!) or AVL rather than Lisp.
Understanding s-expressions isn't hard, but reading s-expression code quickly when you're not used to it is very slow and frustrating. Fluency is essential for efficient use of a language, and breaking people's already-existing infix fluency is quite a hurdle (or certainly appears to be from the outside).
The claim that learning how to read and write s-expressions is hard might well be a "made up thing". (I agree with you, I think anyone, if they sat down for a day and really applied themselves to it, would get it.) On the other hand, I think you'd agree, the fact that people have strong, negative, emotional reactions to s-expressions when they first encounter them is absolutely not made up.
We could sit here and grumble about how silly it is that people cannot overcome such an irrational response (indeed I often do), but that won't change the fact that people have these responses. If we did that, we'd be doing the same thing that GUI designers did in the 90's. "Why, the widget for $x is right here. Any reasonable user will RTFM, know that $x can be checked there, and behave perfectly rationally." (And it happened just so, as decreed from developer's rolling chair, right?) Of course, we know now how misguided this is as a method for UX design: all users are in a sense irrational, and systems need redundant strategies for saving the user from themselves.
The similarity here is that we cannot will away intellectual blemishes in users, we can only accommodate them. That is Lisp's challenge if it is ever to get big. For GUI's, the solution was to take seriously users' need for visually attractive interfaces, redundant display of information, and guardrails/handholding for actions commensurate with their risk, to name a few strategies. For Lisp, it's hard to know what might be the right approach. As klibertp writes in a sibling comment, maybe the solution needs to come from outside the language itself.
