Language design affects how good autocomplete and error messages can be. That is hugely important.

Having said that, this article doesn’t advocate “ident: Type”, it advocates ”marker ident: Type”.

That marker is essential for ease of parsing and thus for autocomplete (it won’t try to autocomplete the ‘ident’ part by looking at variables in scope or function names, for example) and error messages (it could signal when name shadowing occurs, for example)

Actually, syntax IS important because a language has to be able to be read by both a human AND a computer, nowadays.

One of the things that using ":" does is it makes what is "type" and what is "name" unambiguous to both human and computer.

This is, famously, one of the failings of C/C++. Determining what is a type and what is a name is excruciatingly difficult.

Sure, but there's no arguing to be done there. Is the grammar context free? Ideally, can it be parsed with small constant lookahead? Yes? Cool, no further discussion needed.

I'd be more open to this kind of discussion if there was an ounce of actual research behind what makes syntax more/less readable. As it is, it's just a bunch of people arguing endlessly about their very specific preferences. Just pick something sensible and move on.

I didn't say "syntax doesn't matter, pick any ridiculous thing you want". That's what I mean by "not unimportant", though I admit it's not exactly clear that's what I meant. My point is that within the space of reasonable, comprehensible syntaxes, there are no demonstrable differences worth arguing about.

>there are no demonstrable differences worth arguing about.

That is a big claim. Is very easy to believe (I do it before, when my knowledge of programming languages was about just 3 or 4. Now is more than 12). :

But is clearly false, and is easy to prove:

   async/await
   go chan
   fn sort<T>(of:list<T>...)
   try/catch
   match

All the above are just small things that have a HUGE impact in how develop programs. Also, in matter of "small" stuff that could look insignificant:

   [1, 2, 3] + 1 = [2, 3, 4]

this one is a huge deal in certain niches, also, another "small" and insignificant thing:

    SELECT ... FROM source
    source SELECT ...

All this are just small things. Not all that obvious at the time. Remember how before the times of GOTO the idea of more specialized control flow was unthinkable in the minds of many.

Syntax MATTER MOST. Because, is OUR interface. The space of improvement is not super-big, truth, but it impact hugely.

Also, when done correctly, it make the semantics fit like a glove or not.

Another obvious example: Do concurrency whithout syntax help (just using threads). Or performant, safe, concurrency friendly, zero-gc, system-programming, etc without what rust and other langs have bridged.

I also know many languages (which is hardly some grand accomplishment) and it’s my firm opinion that syntax MATTERS LEAST. You spend some time getting used to it and it never really bothers you again. Semantics matter most - syntax is just an interface to the important stuff.

The difference between Python, C++, Haskell, Common Lisp, Prolog, and SQL isn’t syntax. If it was, everyone would pick their favorite syntax and use it all the time. What matters is how well the semantics (and their potential performance implications) match your problem. The syntax just needs to be a decent enough interface to the semantics. Frankly, it seems to me like most of your “counterexamples” are about language semantics, not syntax.

Here’s the thing. Would I like every language to have a consistent, beautifully designed syntax backed by UX research and testing? Absolutely. But language designers have bigger fish to fry. There’s little value in wasting energy talking about syntax once it reaches a basic state of acceptability.

I do amend my statement - you’re right that it’s a big, unsubstantiated claim. There are no _demonstrated_ differences. I haven’t seen an ounce of evidence that it makes a difference beyond familiarity. Furthermore, even if it did, that wouldn’t make it top priority. It would just make arguments about it sensible.

It's worth reiterating the point of my initial comment (which I admit I may not have conveyed well). I never said "syntax doesn't matter", because that's not my point. My point is that it's almost never worth arguing about. Just pick something (or accept what already exists) and move on. Language designers (and you) have more worthwhile things to do.

My issue is with unproductive, endless debates about syntax minutiae like the original post. Syntax doesn't matter enough to be worth it, and such debates devolve into everyone shouting about their personal preferences anyway (see: many of these comments).

> Do SQL without the SQL syntax

I'm not sure what you're saying here. The syntax of SQL is completely arbitrary - I'm sure you could think of a completely different syntax that works just fine. Let me know if I'm missing something, but it seems extremely obvious to me that the biggest difference between C++ and SQL programs isn't how they look - it's how they behave. One wouldn't dream of replacing one with the other and that has nothing to do with their syntaxes.

> go to the C++ community (for example) and tell them to change the syntax to lisp syntax and see how much it will succeed

Obviously it'll fail - good. Even if lisp syntax was way better, they've gotten used to C++ syntax and have much more important things to spend their time on.

> Ok, let's try: Do SQL without the SQL syntax.

    Select(`my_table`, [`column_A`, `column_B`])
         .Filter(`column_C` > 53 && `column_D` == $varA)
         .Sort_by(`column_C`)

There you go: you have the exact semantic as a traditional SQL query (1:1 mapping) and only the syntax is different. Now, one may argue that the syntax is "ugly", less familiar, that the ` are hard to type or whatever, but this is just taste. One simply get used to it. The expressiveness and semantic are the same as in SQL

> Syntax is 100% tied to paradigms, idioms, and such. Is intrinsic to the language we use.

I think then we don't have the same definition of syntax. The way i understand it is that the syntax is just the way to represent these idioms and paradigms visually. What the parent is saying is that these paradigms and idiom as what is important, but the exact way they are written, not as much (as long as it is within reason)

I was to talk about the SQL stuff, but I think it will be wasted as long we get blind to the fact syntax IS semantic.

However this:

> but the exact way they are written, not as much (as long as it is within reason)

Then what is "within reason?". Is more logical to only have GOTO than IF, is better to have ELSEIF or nest IF?, what happened if my lang say that null is the same than Option.None?, what if generics use [] and not <>?.

Whitespace matter, yes? no?

Allow unicode?

CamelCase, snake_case or what? What if all const are lowercase, types mixcase and the rest UPPERCASE?

For some, APL syntax make more sense than algol.

Talk about why, that is the point of this kind of talk.

Is VERY easy to rug this kind of stuff. VERY. I WAS in that camp before. But now, I try to build my own lang (relational), and DAMM, it start to be much clear why syntax matter, even "the exact way they are written", because switch this to that and suddenly, my lang is ANOTHER paradigm (or worse, will be CONFUSED as be).

Naming, is one the hard things in computer science.

---

I understand why is easy to dismmis this as irrelevant. Sometimes I don't see why some people are so upset about typography and font selection, or why my profesional brother complain about framing in photograph. But go and SEE what the DESIGNERS of lang say about this stuff and you will note that for them, even this apparent less-significant thing matter. you can even get a prize on the field for show the importance of syntax (http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...)!

If that mean that most will not see, GREAT! That is the mark of good design.

One thing that I've found myself doing a lot after using SQL for a while is writing SQL to produce SQL. Maybe the syntax could be more oriented towards that, which would not be just a matter of taste.