This is overstating the case for syntax. Without any empirical evidence that syntax is important to anyone other than folks that draft up syntax rules, this is just an assertion.

Put another way, do you have evidence that it is important? Has it let people write better programs? How would you prove that?

This is akin to saying grammar is important. It is, to an extent; but over adherence to grammar is usually not an effective way to communicate.

Well, empirically, syntax is important to a large number of programmers who complain about Lisp's (lack of) syntax. That's not a rigorous empirical study, but it's the best I can do at the moment...

I assert most programmers have not been exposed to lisp. I further assert most that complain of it's lack of syntax have not used it in any capacity.

I would be interested in studies on this. Most I ever see is posturing and assertions with little to no evidence. Frustrating, because I think both sides have valid points. And I fully believe there is a learning curve both ways. I suspect they both converge on total ability. I am genuinely interested in ideas on how that could be explored.

I think it's going to be really hard to do the study in a rigorous way. Solid data would be nice, though. Then we could stop guessing.

My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Now it's on the fringe. I assert that people had been exposed to Lisp, it was widely used. It became less and less popular. It's not that industry didn't know Lisp; they knew it and turned away from it.

Of course, the big flaw in my argument is the growth of the industry. A huge number of new people came in. Did they know Lisp, even at a college level? Maybe, maybe not.

My counter-argument to that is that industry knew Lisp, even if the new programmers didn't. If industry wanted them to learn Lisp, it could have made knowing it a job requirement, or trained people.

> My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s.

Unlikely, given that TIOBE the company wasn't founded until 2000, and the TIOBE index is based on web search engine results, and there weren't any web search engines, or a web for them to search, in the 1980s.

https://www.tiobe.com/tiobe-index/ has historical data going back to 1988. (Presumably they used a different methodology for the older data.)

But I remembered wrong. They list Lisp as #2 in 1988.

In the realm of personal computing, Lisp was nothing in 1988. "Nobody" was doing any Lisp programming for affordable consumer hardware. Lisp had almost no mindshare among people who got started in computing with 8 bit microcomputers in the late 1970's and 80's and who moved on to PC's and Macs. (Speaking of Macs, there was maybe the OpenMCL exception there.) Lisp was something that you heard about that ran on "big iron" owned by exclusive institutions. Lisp machines count as that, basically.

Macintosh Common Lisp was mildly popular on Macs. Apple used it themselves in several projects and eventually bought it, hired the team and sold it into their developer channel.

Another interesting offer was MacScheme.

LeLisp had a Mac version and it was used to implement an interface builder, which was demoed to Steve Jobs, who then hired the developer to create a version for NeXT.

Both Symbolics and TI delivered Lisp Machine boards for the Mac II.

Procyon developed a Common Lisp with UI for both Macs and PCs.

ExperCommon Lisp was another Lisp for Macs.

XLisp had Mac version.

On the PC there were numerous Lisp implementations.

Agreed it would be really hard. I do want to underscore I'm interested in the question. And I don't know which way I expect it to go.

My personal hunch is that lisp was just too expensive when most industry took off. In near every way. C compilers being basically free is a ridiculous advantage. Yes, there are free lisp implementations today. However, early mover advantage is working against them, now.

I'd agree that Lisp was too expensive when things took off. Not just in terms of compilers, but also in terms of hardware requirements. C was a better match for the tight memory of the day.

My personal hunch about the experiment (based on nothing more than my intuition) is that people think differently, and that Lisp's syntax is a good match for how some people think, but not for how the majority of programmers think. But as I said, that's just my current intuition. My intuition a year ago, for example, was different...

Maybe because they don't understand it.

Lisp has syntax. More than any other programming language.

What you think Lisp syntax is, are really simple function calls like

    (+ 1 2)

which are based on the function + various args pattern.

But something like Common Lisp has a few dozen syntactic built-in forms. For example the syntax for LET is in an EBNF (extended backus naur form) form:

     let ({var | (var [init-form])}*) declaration* form*

Then Lisp has macros. Zillions. Each of them implements syntax.

Lisp has a two-stage syntax:

1. stage are s-expressions, a data format: symbols, numbers, lists, strings, ...

2. stage are Lisp forms. They are written as s-expressions. But they have to follow a defined syntax. not every s-expression is a valid Lisp form.

  (let ((a 1) (b 2))
    (declare (integer a b))
    (+ a b))

Above is a valid LET form.

  (let ((a 1) (b 2))
    (+ a b)
    (declare (integer a b)))

Above is not a valid LET form, because the syntax requires that the optional declaration is directly after the binding form.

Without parentheses it might look like:

  let (a 1) (b 2)
    declare integer a b
    a + b

You would think that it has a syntactic structure. Just because Lisp uses s-expressions as a base mechanism, does not mean Lisp has no syntactic structure - but it is on top of s-expressions.

Since Lisp has user-programmable syntax, there is basically an unlimited amount of all kinds of syntactical constructs.

Another helpful comparison is Lisp syntax versus Forth syntax. If you actually want a simple, terse, unstructured language, Forth is the way to do it: Words will consume and return any number of inputs or outputs to the stack, and you get entire classes of error when it's unbalanced that would surface as syntax errors anywhere else.

Just adding s-expressions is actually a huge jump up in syntactic complexity and structure, since now you can define a whole hierarchy statically, "on the page", instead of having to use a series of stack operations to manipulate memory from afar. And then as you lucidly put it, going from s-expressions to a practical Lisp dialect adds another level of context on top of that.

(And yeah, it's possible to bolt structure onto a Forth dialect, too, but the "Chuck Moore way" is that you do that custom every time you need it, instead of trying to generalize. Generalizing a concatenative structure leads to something like Factor.)

I really should adopt this view in my future posts.

I think the difference is most people, myself included, are looking at basically the syntax as where the capital letter and the sentence ending punctuation go. Which is really the only mostly constant thing in most sentences. You raise a vital point that that is a small part of the syntactic makeup of a sentence.

Which is funny, because so many people are convinced you get no static help in lisp. Which is demonstrably wrong.

Sure, but what's not known is whether that's primarily because the majority of programmers learn to program on languages inspired by C syntax.