Comment by ralphc

Some Scheme and Lisp dialects have that. For example, Racket often uses square brackets instead of parentheses for things like clauses of a cond expression, and Clojure uses square brackets for vector literals and curlies for hash map literals.

> "Look at mathematical papers where people will introduce new brackets with new meanings"

Common Lisp has left brackets like {} and [] to the user (aka developer). It supports "reader macros", where the user can extend/supersede the syntax of s-expressions.

So, specialized tools/libraries/applications can introduce these brackets for their own use. Examples are embedded SQL expressions, notations for Frames (special objects, in kind of a mix of OOP and Logics), grammar terms, etc.

Thus it explicitly supports the idea of "people will introduce new brackets with new meanings".

> 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.

I believe you, but do you have a source for this? I can't find papers on how they chose to develop the syntax of Algol in the beginning.

You may be right, idk, but I want to point out that you’re conflating two orthogonal concepts: S-expressions and imperative vs. functional programming.

There are lisp dialects that are very imperative, for example elisp, but they still use S-expressions. Historically they might have been considered “functional” because they have first-class functions and higher-order functions like mapcar, but nowadays practically every modern programming language (except go!) has these.

The thing all lisp dialects have in common is not where they land on the imperative vs. functional spectrum, but rather the fact that the syntax is trivial and so it’s easy to write powerful macros.

Decades of empirical evidence prove that people are more comfortable with functional, reactive, beging/end delimited programming, i.e. Excel.

No, it doesn’t.

What has happened in reality is that C became really popular and then all the people designing languages they wanted to be popular, rather than to be experimental, or to push boundaries, etc obviously chose a syntax which was familiar with most programmers, ie a syntax like C’s.

Further, one can disprove that the syntax is particularly important by simply pointing to Python which became immensely popular despite a lack of curly braces and even worse with significant white space simply because colleges and bootcamps decided it would be a good language to teach programming to beginners.

Hmm, can't find the paper (mostly clutter from language bootcamp results) but around a decade or so back there was an education research project that concluded that teaching SQL first, rather than any imperative language (regardless of punctuation), was better for getting students to develop reasonable mental models for computing. (Unfortunately without the reference I can't address what the criteria for "better" were - but "what people get paid to do" isn't really proof of comfort at any level...)

I think it's quite telling that almost all of the innovations in lisp (garbage collection, first class functions, repl etc) have been absorbed into more popular languages except for s-expression syntax, which remains a small niche despite many great implementations of s-expression based languages.

Does over a century of empirical evidence not prove that people are more comfortable with keyboards whose top row is laid out "QWERTYUIOP"?

Has there ever been research on this? Perhaps this situation has come about because the schools people must go to to get the programming jobs only teach the Javascript way? It seems circular logic to say that the current paradigm must be superior for the fact that it is the current paradigm. Is it possible that there are other reasons it reached that status?

No, because people who start in programming do not go to a syntax comfort clinic, where they are tested, and then assigned to a programming language.

It only proves that those languages are the most learned because they are the most popular in industry.

It says nothing about what makes a language easy to learn.

> I would argue that imperative programming is most natural - it's what everyone gravitates to in the beginning.

When 6.001 (the introductory class for which SICP was written) was launched, most of the students who took it had never used a computer before. Yes, MIT students. This was around ~1980. And in the first hour of their first class they were already doing symbolic differentiation in scheme.

I think your view of what’s “natural” is a just so story.

Imperative programming is probably the most intuitive, but I'm doubtful curly braces and C-like syntax are anything more than coincidence. The first programming language was Fortran, and it didn't look anything like C. This is a really old Fortran program copied from a book:

     WRITE(6,28)
     READ(5,31) LIMIT
     ALIM = LIMIT
   5 SUM=0.0
     DO 35 ICNT=1,LIMIT
     READ(5,32) X
  35 SUM = SUM + X
     AMEAN = SUM/ALIM
     WRITE(6,33) AMEAN
     GO TO 5
  28 FORMAT(1H1)
  31 FORMAT(I3)
  32 FORMAT(F5.2)
  33 FORMAT(8H MEAN = .F8.2)
     END

Most modern programming languages seem to take inspiration from C, which took inspiration from BCPL, and that from Algol. Others took inspiration from Algol directly, like Ada, or Lua. And Python has indentation-based block structure, rather than having blocks of statements delimited by braces or or an "end" keyword.

> I would argue that imperative programming is most natural - it's what everyone gravitates to in the beginning.

Why do you believe this is anything more than an historical accident?

For example, it wasn't what Alonzo Church gravitated to when he invented the lambda calculus in the 1930s, before any programming languages or indeed general-purpose computers existed.

> 99 Bottles of Beer implemented with a loop is intrinsically going to be easier to read than an implementation with tail recursion

First, you don't need to use explicit tail recursion. See e.g. https://99-bottles-of-beer.net/language-haskell-1070.html

Second, this sounds like unfamiliarity, not anything inherent. Why is it "intrinsically easier to read"? For a tail recursive version, the main tail recursive function would look like this in Haskell:

    _99bottles 0 = printVerse 0
    _99bottles n = do
        printVerse n
        _99bottles (n - 1)

In fact, with a bit of experience you might write this as:

    _99bottles 0 = printVerse 0
    _99bottles n = printVerse n >> _99bottles (n - 1)

It's only less easy to read if you're completely unfamiliar with the concepts of pattern matching and recursion. But the same is true of any programming language.

Given the above, what's a "for loop" and why would you need one? Sounds complicated and unnatural.

OOP is imperative programming. It's just function calls where the first parameter is to the left of the function name, after all.

A better name for "non-OOP" programming is procedural programming, where you organize code in long blocks that go straight down, code duplication is accepted vs jumping all over the place, etc. Honestly underrated. It can be quite easy to understand.

Strictly-evaluated FP is also imperative. The only really different languages are the ones with different evaluation systems or that can do things besides evaluate - people like to say Haskell is the best here but I think it's actually unification languages like Mercury. Maybe even SQL with transactions.

I'd argue a FP implemenation with map (something like `[99..1].map(|n| f'{n} bottles of beer ... {n-1} bottles of beer on the wall').join('\n\n')`) is inherently as readable as the for loop, and not really more complex.

There are lots of great parts in FP, and for the last ~10-15 years imperative programming languages have made a lot of effort to add them to their syntax. You just need to leave out the more dogmatic parts that make FP popular in academia.

Assembly is imperative, so there's a lot to be said for a language that mimics how the computer actually works. Lisps always leave me saying, "oh, that's clever."

> even though the latter is generally better

Why is tail recursion better generally? I'm not familiar with FP very much, but it feels like loops more closely resemble the way computers execute them than tail recursion.

This is completely socially constructed.

Lisp was once a very popular introductory programming language and students learned it just as easily or easier than any other language.

I don't think it's been tested at all. for people who took and finished a course in Lisp as their first programming language, how many "hate parens"?

I have no trouble with lisp's parens, i like them. What I never liked though, is that the first item in the list was an operator, a verb lets say, and the rest were the nouns; whereas, you could also have nested lists say of numbers where there were no operators. Never felt right (not that I can think of a better way, not worth adding more parens)

But good college math departments teach reverse Polish notation; i.e., Hewlett-Packard over Texas Instruments. It’s demonstrably more advanced / efficient.

Lisp became very popular, then died off rapidly due to association with the AI Winter.

There's nothing natural about programming, because no ones like to be that formalized in their thinking process, especially with things that should be common sense (although ambiguity is still an issue). It's the recursive definition that get people. Especially when pointing that the things that the computer can do form a very small set. It's just that they can do it very fast.

You can see that when observing novices programming (without stack overflow or similar help). They often assumes that it will get done (magically) as soon as they call that function. And their code organization reflects the ad hoc thinking instead of a planned endeavor.

> Paul Graham also talks about macros in his well known essay

With all due respect, he is ironically probably the biggest blub programmer.

Ultimately, programming languages are tools, and different tools are appropriate for different jobs.

There's nothing stopping you from writing a massively-scaling e-commerce site in Verilog and running it on an FPGA, but it - uh - probably isn't the soundest course of action.