This would be down to very fundamental differences in thinking and conceptualisation that are difficult or impossible to "just" teach over. It requires those arguing over "ease of use" to recognise that it's not a property of the tool itself, but a function of both the tool and the user and how well the tool fits the particular, individual, user.
If you've spent years editing your code character by character it won't be apparent why being able to use shortcuts or indentation to edit your code as forms would be a new editing default
I'd argue it's possible to teach everyone, but not motivate everyone
I've also seen a few smart people learn the mechanical parts of Clojure and then dismiss it, not understanding the hype because they were just using it like a very imperative language that just happened to be immutable
As a learner you should definitely go through it's rational and Rich Hickey talks first before learning it: https://www.youtube.com/watch?v=rI8tNMsozo0
It exposes the PDP-11 most cleanly. For modern machines the mismatch between the C abstract machine and the actual hardware has been steadily increasing for decades. It's still close to the hardware compared to almost all other languages, but it is by no means "as cleanly as possible". It's not portable assembly like in the days of yore.
A lot of myths about lisp being conceptually pure come from poorly taught college classes. If there were one active lisp user for every time I've heard "Lisp? The only thing I remember about that is that it doesn't have loops," then the lisp community would be a large thriving community.
Well .. sort of. I agree with the comment about C being effectively a PDP-11 VM; there are all sorts of features which it doesn't and can't expose. If you look at the Intel instruction set of the present day with all its extensions, how much of that can the compiler really emit? Multithreading is also something that's been very awkwardly retrofitted to C, with all sorts of memory ordering issues that aren't easy to fix. Then there's all the "undefined behaviour" wrangling.
By raw FLOPS the most powerful part of the average computer will be the graphics card, which really isn't suitable for C (or Lisp!) programming at all.
Another reason could be developers who like to compose programs from the bottom up would naturally like repl based development, but there are many languages with great repl experiences.
Anecdotally, there seems to be a dislike of Lisp just because of the parens-based syntax. Do you think the different syntax counts as being such a fundamental difference for 90% of developers? Is it really so bad to have to write:
(define x 1)
let x = 1;
That difference makes it "left-handed scissors"?
The big 'problems' are a) interactive use (much of Lisp usage is 'interactivity first'), b) the code as data thing and lack of static feedback (type checks, ...).
The 'code as data' thing is a real hurdle: what is code, what is data, what is transformed code, what are code transformers, ... One needs a mental model to work with code which is making heavy use of meta-linguistic-programming.
I can understand that people that have achieved "lisp enlightenment" will view Racket this way. With respect to replacing s-expressions, I am hopeful that the original s-expression-based Racket retains prominence even when the Rhombus language is fleshed out. I know I will continue to use s-expressions.
> a) interactive use (much of Lisp usage is 'interactivity first')
To me, having used Clojure (which hopefully counts as an interactive Lisp) and worked in environments like A+ (in the family of APL/J/K), this is an amazing feature and I struggle to see this being such a "fundamental difference ... that is difficult or impossible to 'teach'" (paraphrasing OP).
> b) the code as data thing and lack of static feedback (type checks, ...).
Not that much in my view. I don't see Clojure as a particular interactive Lisp, I actually see it only as 'derived from Lisp and others'. 'Lisp' is usually much more interactive, with stateful images (running copies of 'object seas'), mix of interpretation and compilation, interactive error handling, all-layers Lisp (where most of the layers can be inspected/manipulated/changed at runtime, incl. its own implementation) and internal development environments (not externally attached).
For an explanation see: https://news.ycombinator.com/item?id=22326853
At least speaking personally from my opinion I see a lot of people claiming that lisp simple syntax and homoiconicity make it a simple language and in my opinion this misses completely the point of simplicity in a language.
I am not claiming that lisp is complex, just that that argument is faulty.
In the case of lisp and its rich macros system the only thing I can see is that anything could cause any kind of effect; I see this as a significant source of complexity in practice. I am sure that library/implementation authors made a fantastic job in refining wonderful abstraction so that this is not a problem in practice.
Julia offers also has rich macros but there the messaging there is different, macros are intended to be used in library code to allow for greater ergonomics. Users of the language to be able to write an idiomatic library as that involve language features that are not necessary in normal scripting.
(I just now realize that I never heard of an Obfuscated Lisp Contest, things could get quite crazy there)
In https://github.com/evdubs/interactive-brokers-api/blob/maste..., there is plenty of:
(class/c (init-field [class-member-a integer?])))
(init-field [class-member-a 0]))
(init-field [class-member-a integer? 0]))
It's great that Julia has messaging that macros should be reserved for libraries. I can't say that I've seen Racket messaging be the same, but I also don't see a proliferation of macros in libraries that I choose to use for projects, either. Especially in such a manner that makes me concerned that, "will this completely screw up my intention?" If you have a different experience, I am curious to hear it.
This is exactly what I mean, Racket is not a nice language because it has a minimal syntax, it is a nice language because it is powerful, well thought, and its features work well together. Homoiconicity and macros are tools that Racket uses internally to define itself and they are essential to how many of the language features work, but often they are not directly relevant to the (non-library-writing) user.
Both left and right handed scissors have blades, a pivot, and handles. The only difference is the arrangement. But remember that both this and the analogy with Maxwell's equations are analogies.
Agreed, and to me, this makes the point that the syntax (arrangement) is a key component to an unwillingness to learn. However, I don't see how this establishes lisp as having, "very fundamental differences in thinking and conceptualisation that are difficult or impossible to 'just' teach over". With left-handed scissors, you have the same concept; you just need to train your left hand to use them. Likewise with syntax. Describing that as being a very fundamental difference that is difficult or impossible to teach over seems odd to me.
Or trousers. One size does not fit all.
Or the people discussing the intuitive representation of Maxwells' equations themselves: https://news.ycombinator.com/item?id=23700295 - not everybody likes the equations, some people like pictures for a better understanding, but the equations-first people may not understand that.
Why is that interesting? Because it raises the question: is the analogy made in the article more akin to Maxwell (breakthrough, brilliant but close to unusable), or is it more akin to Heaviside (taking known concepts and making them usable in practice)?
So in addition to the Stigler's law  situation with Heaviside, the formulation of special relativity may have been more or less inevitable after all of Maxwell's laws were put in the same room together. Not that Einstein wasn't a once-in-a-generation talent, but the reality of how progress is made in science is often glossed over in favor of assigning glory to particular individuals.
Even Maxwell's laws taken individually are named after different people, but together they all belong to Maxwell. I get that this practice is intended to be a convenient way to put a label on an abstract concept rather than a way to write history, but I still think it has an effect on how we think and talk about the history of science.
Discussed at the time: https://news.ycombinator.com/item?id=3830867
“Maxwell's equations of software” examined (2008)
Also, Maxwell's equations have the important property that they are linear. How would that work in the Lisp analogy?
Also, LISP is a language that's been dead since 1970s. Did you perhaps mean Lisp?
More seriously, I have seen a lot of badly written Lisp/Scheme, as much as in any other language. Lisp DOES scale quite well, if the code is well-designed.
If Lisp were mainstream I'd probably see that as a red flag
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
What are these amazing 'commercial' programs?
And why are they so large? And, do they need to be so large?
Does the entire team understand all the inner workings of the commercial program?
The Lisp eval function is easier to read, understand, and modify than to start over and rewrite it from scratch.
( As for those brackets, well ...
Sure, because C and Fortran are extremely limited languages - no first-class functions, no sum types, pitiful error handling. In a world where language design was extremely-primitive, user-defined macros made sense. Once languages that offered standard ways of doing the constructs that most programs need were invented (i.e. ML in 1973), there were better alternatives.
> The Lisp eval function is easier to read, understand, and modify than to start over and rewrite it from scratch.
That's not actually true though. The definition in the link uses a bunch of obscure lisp-specific terminology and doesn't really gain anything from doing so. It genuinely is easier to reimplement it from scratch (perhaps with the help of a more neutral reference) than to understand the Lisp version.
However, that's not how Lispers usually read Lisp code. Lispers would connect to a REPL and start "dissecting" the code evaluating it piece by piece. Lisp is unlike many other PLs where you usually have to follow "write -> save -> lint|compile -> run -> check the results" routine, boils down to "write -> eval -> check the results".
You can even say that coding in Lisp is dealing with a "living," "breathing" program, whereas in other PLs - your program is "dead" and comes to life only after it's compiled and ran.
> It is avoided commercially for this reason.
Lisp is being used today by Apple, Walmart, Cisco, Amazon, Netflix, and even NASA and many other companies. Huge banks and FinTech startups around the world actively using it. Clojure is the most popular programming language in its category of PLs with strong FP emphasis. It is more popular than Haskell, OCaml, Elm, Elixir, Purescript, and recently surpassed Scala.
Not a single guru, CS veteran or renowned programmer ever complained about Lisp being hard to read, because they understand - if they know anything about programming at all, publicly saying shit like that would raise many eyebrows.
But every single time someone mentions Lisp on HN, there will be at least one dyslisplexic, who has never developed enough patience or inner curiosity to learn it.
Universal Computation was demonstrated a long time before Lisp. Any Turing-complete language is universal, Lisp included. Church's lambda calculus is included, and Lisp is a notation for lambda calculus. So, you can write a Lisp interpreter in Lisp, and it's pretty compact because (surprise!) a Lisp Interpreter has a lot of support for the stuff you need to do to Interpret Lisp. There's nothing deeply meaningful about it beyond what you start out with from Church.
It is much more impressive, and subtly meaningful, that a NAND gate is universal. You can build a machine that runs Lisp from nothing but NAND gates, and people have. There have even been commercially successful discrete-transistor mainframes made of practically nothing but NOR gates (plus core memory), which are identically universal.
Transistors are therefore universal. But because their operation is described in analog terms, they don't quite fit the mathematical formalism. The universe doesn't care about that, so it allows us to build up Universal Computation out of analog transistors. The more transistors you put in, the more computation you can do in a second.
Lambda calculus and lisp for the abstract model.