In the follow up article, I wrote something like this in the conclusion:

> Designing a language is more than just getting the syntax right, and denotation semantics are a lot more important in most ways, but that does not mean syntax does not matter. When you get syntax right, people won’t even know you’ve done anything at all. But when you’ve got it wrong (and have actually tried using the language), they will complain instantly.

Follow-up Article: https://www.gingerbill.org/article/2026/02/21/does-syntax-ma...

I was trying to be EXTREMELY clear I am talking specifically about DECLARATION syntax only and how for the most part, the concrete syntax for the DECLARTAION syntax is not that important in many languages.

However concrete syntax matters a heck of a lot and cannot be trivially interchangeable.

I had to write a follow-up article to clarify this because of people like yourself wrongly interpreting the article: https://www.gingerbill.org/article/2026/02/21/does-syntax-ma...

I tried my best to be very clear within this article that I am talking about two specific things: DECLARATION SYNTAX and SEMICOLONS. This does not extend to anything else. In fact I got so frustrated with people like yourself who are wrongly interpreting the article that way and extrapolating too much that I had to write a new article: https://www.gingerbill.org/article/2026/02/21/does-syntax-ma...

"Does Syntax Matter?" And the first one is "Yes."

And all languages can have their declaration syntaxes categorized into one of the three I mention. This is not limited to ALGOLs. And I have come across "really interesting language syntax". I am not talking about that in this article.

----

Ergonomics does matter and it's not just about optimizing for typing either. It's actually all about coherency and consistency, something I go into depth into the following article on syntax.

----

I am not "conflating" a semicolon with statement terminators, I am using that as shorthand as most languages that most people encounter (not all languages, obviously) will use semicolons. Python's approach to parsing is a form of automatic semicolon insertion, even if most people don't think of it that way.

----

And I do not like Python's approach requiring significant whitespace of "blocks" through indentation. I much prefer using something like braces, or an `end` keyword, etc, literally because it prevents the problems that significant whitespace introduces. I am not getting into that argument here; please don't start it.

Hello again. That's not my position in the slightest. The point of the article is to express how people will shallowly and naïvely judge something. It might be naïve conception of "aesthetics" but it's not even a good one.

It has nothing to do with people disagreeing with me, I have seen people dismiss numerous languages (not just my own) based on that declaration syntax. Things like "why does Rust not use `type name = value`? why did they have to change things so much from C++?".

Do you think these people are actually serious programmers or just having shallow and dumb opinions on things they know little to nothing about?

> Do you think these people are actually serious programmers [...] ?

I can't possibly tell? The surface aesthetic impression is only that.

> I never got why compilers don't have pluggable syntaxes.

Because then you've created dialects and produced the Curse of Common Lisp all over again.

Syntax matters a heck of a lot, and you want consistency and coherency across codebases of the same language, otherwise you don't have a language at all. So wanting it "pluggable" is in fact the worse possible choice you want.

It's also a naïve view to think that concrete syntax can be trivially swapped out with the abstract syntax remaining. For certain things it can usually work (like declaration syntax in the article) but for most things it cannot.

Yes it does. You can even type `;` anywhere too, go an try it.

Because of how good the rules are for Python's needs, most people never know that semicolons even exist in Python.

This isn't quite right. Go and JavaScript use semicolons pervasively throughout their formal grammars, and mostly don't use newlines; then, on top of that, they have special rules that allow the semicolons to be omitted in many cases depending on newline placement. Python uses newlines pervasively throughout its formal grammar, and only allows semicolons to be used in a couple specific places (at the end of a simple statement or to separate multiple simple statements on a single line).

The two systems have in common that you can either include or omit a semicolon when you've got a simple statement on its own line, but under the hood they're different; the missing semicolon at the end of a line in idiomatic Python is not "automatically inserted by the parser", it is simply not needed at all. There are also behavioral differences; for example, in Go and JavaScript a semicolon on a line by itself is legal and does nothing, while in Python it's a syntax error.

This might might sound weird but I think that's a distinction without a difference.

Those "newline tokens" are effectively the equivalent to a semicolon in the parser. They are statement terminators. The way that Odin or Python handles them is effectively the same except when I tokenize the newlines, they are treated as semicolons but with the "text" being "\n". Thus the distinction here is a matter of what you call it, not how it is treated.

That is the same as a form of "automatic statement-terminator insertion" where that statement-terminator is whatever you want it to be. And to me, that is as form of "semicolon" (which is being used as a generalization for statement-terminator) insertion.

Did you even read the article, even the heading of that section? You know there is a huge majority that do not want semicolons whatsoever, so saying people should just suck it up is actually a determent to the adoption of the language because of people's general tastes.

That sidestepping only introduces significant whitespace, which may not be what people want in the first place. It can be quite common to align call expressions by the parentheses if they span multiple lines for clarity, and you preventing might not be desireable.

The article does no such thing and just focused on declaration syntaxes and semicolons. I can class literally any language into the three categories for declaring variables.

* Haskells are name-focused languages. * Smalltalk is a name-focused language. * LISPs are qualifier-focused languages.

I think you might have a blinkered viewpoint in how you have interpreted the article.

I think you oversimplify things a bit.

Are those names erased during compilation? It has a massive impact.

If you have indirect calls, how are those resolved? That matters a lot.

What is even the language, after the code is compiled/interpreted. Does it disappear like in many languages? Do you have some parts available, but not all (like in PHP)? Or do you have full runtime at hand and you can mold it like in Smalltalk? There are languages with no runtime, languages with some runtime, and languages with full image in place. Each has massively different pros and cons.

When you say Haskell and Smalltalk are name focused, you are technically right, but developer experience is extremely different.

> * Haskells are name-focused languages. * Smalltalk is a name-focused language. * LISPs are qualifier-focused languages.

First, I reject the idea that all languages can be classified according to this metric. The fact that you think that they can reveals how little experience you have with different languages.

Second, your proposed classification of these languages, even by the naive standards of the article, is wrong. You've proved my point.

First, tell me languages which have named value declarations which don't fit into that category. I'd love for my hypothesis to be proven wrong.

Second, how are they wrong? You haven't proved any point as you were extremely vague.

You're missing the point. Your categories are irrelevant. It's like if I announced proudly "All cars can be divided three categories: those with rear lights angled up, those with rear lights angled down, and those with rear lights straight." True but useless.

But if you're going to categorize, your categorization is wrong. Just because a language puts a qualifier first in no way means that it is qualifier focused.

The categorizes are useful for understand how people perceive a language. It's a human psychology category, and just because you think it is "irrelevant" misunderstands why I made the categorical distinctions in the first place.

People actually talk this way about languages, and they already have this conception.

And I've just realized what your psychological hang-up is now too, the word "focused". I originally didn't use this term when I wrote the article in 2018, but a friend suggested the term instead because it was probably a little more "neutral". I honestly cannot remember what I used before now since I have just absorbed this arbitrary term "focused", even if the distinctions are useful.

You might not think this way about languages. I know I don't when I program. But I know this is how others things, and that's the entire aspect of design. Design is just so much about understanding humans. How they function, mentally and physically. Perception, psychology, sociology, physiology, ergonomics, needs, desires, etc. It's all about being able to put yourself in other people's shoes, more than making _the thing_.

And that's what I've been trying to understand and that categorization has been helpful for understand other people. I don't care if you think the categorizes are "irrelevant" but you are not "everyone".

Those syntax examples are literally just general examples, not the only way you have to write them. But to categorize the ones you wrote:

* Clojure is qualifier-focused * Prolog is name-focused * Forth is qualifier-focused (`:` is the qualifier in this case)