Comment by patrickmay

I think it's innate that having differentiated syntax for different types of grouping is natural. Look at mathematical papers where people will introduce new brackets with new meanings. (Indeed look at the entirety of QM for a clear, simple case)

Because lisp is trivial to parse, it’s easy to make an extension for vs code that shows / edits Common Lisp / scheme looking completely different; you can make it unrecognisable. If the () are the only thing bothering people, then this is very simple to resolve. Can hardly be the only thing though. It’s also easy to build operators similar to the ones you have in Python etc like filter, map etc so you don’t have to apply recursion. These are there already but you can build them yourself in a few hours.

So it’s probably just what people learn first + lack of ‘marketing’ or negative PR (there are no libraries or ecosystem! The thing that least bothered me about CL but people with npm leftpad experience seem bothered by it).

It’s interesting as I worked I almost everything in production; c/c++ (including the MS 90s flavour), Delphi, VB, Perl, PHP, Java, C#, Haskell, F#, Common Lisp, Erlang, TS/JS, Python, Ruby, asm (z80, arm, x86) and I simply have not had a better overal experience than CL. The others are better at some things but a an overal experience, CL just is a pleasure.

The curly braces themselves are 100% irrelevant, as evidenced by the many, many successful and well-liked languages which don't use them, including Python, which is in the running for the most-used language these days. They're an implementation detail.

What's closer to innate is the Algorithmic Language, Algol for short, the common ancestor of the vast majority of languages in common use (but not, notably, Lisps).

Algol was designed based on observational data of how programmers, who had to somehow turn their ideas into the assembler to run on machines, would write out those ideas. Before it was code, it was pseudocode, and the origins predate electronic computers: pseudocode was used to express algorithms to computers, when that was a profession rather than an object.

That pseudocode could have been anything, because it was just a way of working out what you then had to persuade the machine to do. But it gravitated toward a common vocabulary of control structures, assignment expressions, arithmetic as expressed in PEBCAK style, subroutine calls written like functions, indexing with squared brackets on both sides of an assignment, and so on. I revert to pseudocode frequently when I'm stuck on something, and get a lot of benefit from the practice.

So I do think that what's common in imperative languages captures something which is somewhat innate to the way programmers think about programs. Lisp was also a notation! And it fits the way some people think very well. But not the majority. I have some thoughts about why, which you can deduce an accurate sketch of from what I chose to highlight in the previous paragraph.

Does decades of empirical evidence not prove that people are more comfortable with imperative, curly brace programming over s-expressions? It's not a chicken and egg problem. The egg has hatched and nested parentheses lost.

I would argue that imperative programming is most natural - it's what everyone gravitates to in the beginning. Then, at a sufficient level of complexity, a programmer gravitates to solutions like OOP or FP, but there's an obvious trade off in readability there. 99 Bottles of Beer implemented with a loop is intrinsically going to be easier to read than an implementation with tail recursion, even though the latter is generally better. Lisp's inside-out parentheses style adds yet more cognitive load on top of that.

Many things are socially constructed, but not everything.

Then why does this web page use indentation to clarify who's replying to whom, instead of {}s?

I don't know if it's innate but it's what we have. Lisp has been around about as long as programming, it's had plenty of time to catch on, it hasn't.

Maybe innate, maybe it's an offshoot of teaching math in an infix style, 1 + 2 vs. + 1 2.

C-like syntax is brutally hostile to programming beginners. There is not a shred of anything natural about it.

That alternative universe was the early 1980s where Lisp was very popular to learn due to bring consider the best language for AI.

If the "job" is to make lots and lots of software, even if most of it is mediocre, then the best tool is what will enable millions of mediocre developers to develop, not just thousands of elite developers.

Plus, add a heaping tablespoon of survivorship bias.

1. Many people try programming.

2. The vast majority of the people who try programming are subject to external forces that guide them to whatever they learn and use.

3. Out of these, a certain fractions stick with it and are found programming in the long run, even working in it.

We could easily conclude (probably quite wrongly) that the popular languages turn people away from programming, except for a few weirdos for whom they click.

JS is fine for scripting, sprinkling a bit of interactivity on a page. The issue is when you want to create whole software out of it, and the last thing you want is forgiveness. You want the compiler and linter complaining loudly.

The 10x seems to mostly have been from programmers switching from extremely low level languages like C++ to something far higher level. Paul Graham also talks about macros in his well known essay, but I honestly think a lot of the value one gets from Lisp can be found with Python. There are a lot of things you don't have to worry about like manual memory management and so on. Python isn't as fast as lisp or as beautiful (opinion), but the ecosystem is very impressive and the community isn't as fractured as the lisp community (for example see the bipolar lisp programmer essay).

I don't think FP by itself is that massive of a win despite what some dubious studies or zealots say, but it's certainly better than enterprise Java. I've read my fair share of horror stories of Haskell in production too.

I think the idea that Lisp was so much more productive than other languages originates from a much earlier time. But now the most important features of Lisp - like garbage collection - are commonly available in most languages.

This is very disingenuous. The frontend world does move quickly, but the part of the stack you're describing has been reasonably stable.

Vanilla JS was replaced by jQuery after about a decade. A decade later, React/Vue/Angular (React came first, not last) replaced jQuery

There was a paradigm shift in the kind of websites that people wanted to build. For better or worse, we went from HTML + CSS with some JavaScript (jQuery) to SPAs. It's easier for a team of junior developers to build a SPA with React compared to jQuery.

The abstractions that you're describing changed because the goal changed.

---

There has been plenty of churn around build tools, libraries on top of React/Vue, the paradigms within React/Vue (Hooks, Vue 3 composition API), state management libraries, and the adoption of TypeScript.

Again, this isn't really reinventing abstractions as much as dealing with an evolving language that wasn't designed for the applications we're building today (though it is clearly quite capable!)

It could have been VBScript.