Unfortunately too often those who attempt to design programming languages are ignorant about the history of programming languages, so they are not aware that there have already been programming languages that implemented better solutions for whatever problems they encounter, so their new languages end up being inferior from various points of view to old languages, even if they also incorporate some innovative and desirable features.
The problem discussed in the parent article was already solved correctly by 1965, 60 years ago, in the language CPL, the ancestor of BCPL, which is the ancestor of C.
It is sad that decades later, most programming languages remain worse from this point of view.
In CPL, a command or definition is terminated by a semicolon or by an end of line unless the end of line occurs at a point in the program where the context indicates that a command or definition cannot terminate at that point.
This means that only a minimum number of semicolons are needed, when you want to write multiple statements on a single line, and no special characters are needed to mark that a statement is written on multiple lines.
Before CPL, some languages terminated statements with semicolons, while others with new line characters. CPL was the first to allow either method of termination, and also where new line characters may terminate or not terminate a statement, depending on the context.
Thus CPL combined the advantage of ALGOL-like languages for writing statements on multiple lines with the advantage of FORTRAN-like languages for not requiring semicolons in most cases.
That does require designing the language grammar in a certain way, in particular, there should not be any optional elements in any productions used by statements on the right-hand side (otherwise it's ambiguous whether to terminate the statement or continue to the next line) that can also start a statement. Most languages violate that.
"where the context indicates that a command or definition cannot terminate at that point" is trivially unsuitable for C-like languages, `if`-`else` already violates that, since an `if` can terminate before the `else` by that definition (imagine splitting `else` to a new line).
An actually workable definition would be "unless the end of line occurs at a point where the current expression can not be terminated or the next tokens are not parseable as a separate statement", which is almost the definition of semicolon insertion in JavaScript....
But JavaScript has exactly the problem of the ambiguity since both braces (via object literals) and parentheses (via expressions-as-statements) can start a statement and those are ambiguous with eg. blocks and function calls, respectively.
You are of course right about the requirements on such a syntax, but that was precisely my point, a syntax must be designed taking into account how it should be parsed and it must be designed in such a way that the programmer will not need to write superfluous information.
C is an example of how the syntax of a programming language should not be designed and unfortunately many languages whose claimed purpose was to correct various shortcomings of C have nonetheless inherited the quirks of its syntax.
C has attempted to avoid the use of braces/parentheses/brackets in certain contexts and it has attempted to minimize the number of keywords, but the end result has been the opposite, a typical C program has much more parentheses, braces and brackets than the same program written in a language with a better syntax, like ALGOL 68, or like a non-verbose version of Ada, where the Ada abstract syntax would be preserved but most Ada keywords would be substituted with symbols (such a non-verbose Ada can easily be implemented with a source preprocessor).
In my opinion, a good syntax is of the kind usually called "fully bracketed", as popularized by ALGOL 68, where there are no ambiguities about the extent of a program structure (like the one mentioned by you with C "if", such problems do not exist in ALGOL 68, Ada and similar languages) and there are no alternatives of the kind that exist in C between using a simple statement or a compound statement, i.e. in any location it does not matter if one or more statements are written (this is the feature that makes the specification of statement termination that was used in CPL work without problems), and where several kinds of different brackets are used, not a single kind, e.g. there should be different kinds of brackets for blocks, loops and conditional statements.
Most of the problems that exist in the syntaxes of many popular programming languages are caused by the use of the ASCII character set, which has too few symbols, so it forces the use of some symbols for multiple purposes, which causes ambiguities for parsing.
When Unicode is used instead of ASCII, it is possible to use every symbol for a unique purpose, including the use of different kinds of brackets, and this makes very easy to design a syntax that avoids any kinds of parsing ambiguities.
Honestly I don't mind semicolons; so much that I even type them in Python. (Yes Python has semicolons, they are just optional.) It makes parsing a little bit simpler for both human and automated parsers, it makes statements explicit. There is not really a downside you just type them automatically when you end a statement, like you type Ctrl-S by habit after you stop typing. I find the obsession with semicolon free languages weird.
ALGOL (1960) used semicolons as separators. C made them terminators.
Every language since has had to pick a side, and "optional" always turns out to be the hardest choice.
JavaScript's ASI is what happens when a 10 day language has to live with a quick pragmatic decision for 30 years.
C was following PL/I.
Good catch, PL/I got there first. The lineage is ALGOL (separators) → PL/I (terminators) → C (terminators).
C gets the credit because it won the adoption war, but the decision was IBM's before it was Ritchie's.
Unfortunately too often those who attempt to design programming languages are ignorant about the history of programming languages, so they are not aware that there have already been programming languages that implemented better solutions for whatever problems they encounter, so their new languages end up being inferior from various points of view to old languages, even if they also incorporate some innovative and desirable features.
The problem discussed in the parent article was already solved correctly by 1965, 60 years ago, in the language CPL, the ancestor of BCPL, which is the ancestor of C.
It is sad that decades later, most programming languages remain worse from this point of view.
In CPL, a command or definition is terminated by a semicolon or by an end of line unless the end of line occurs at a point in the program where the context indicates that a command or definition cannot terminate at that point.
This means that only a minimum number of semicolons are needed, when you want to write multiple statements on a single line, and no special characters are needed to mark that a statement is written on multiple lines.
Before CPL, some languages terminated statements with semicolons, while others with new line characters. CPL was the first to allow either method of termination, and also where new line characters may terminate or not terminate a statement, depending on the context.
Thus CPL combined the advantage of ALGOL-like languages for writing statements on multiple lines with the advantage of FORTRAN-like languages for not requiring semicolons in most cases.
That does require designing the language grammar in a certain way, in particular, there should not be any optional elements in any productions used by statements on the right-hand side (otherwise it's ambiguous whether to terminate the statement or continue to the next line) that can also start a statement. Most languages violate that.
"where the context indicates that a command or definition cannot terminate at that point" is trivially unsuitable for C-like languages, `if`-`else` already violates that, since an `if` can terminate before the `else` by that definition (imagine splitting `else` to a new line).
An actually workable definition would be "unless the end of line occurs at a point where the current expression can not be terminated or the next tokens are not parseable as a separate statement", which is almost the definition of semicolon insertion in JavaScript....
But JavaScript has exactly the problem of the ambiguity since both braces (via object literals) and parentheses (via expressions-as-statements) can start a statement and those are ambiguous with eg. blocks and function calls, respectively.
You are of course right about the requirements on such a syntax, but that was precisely my point, a syntax must be designed taking into account how it should be parsed and it must be designed in such a way that the programmer will not need to write superfluous information.
C is an example of how the syntax of a programming language should not be designed and unfortunately many languages whose claimed purpose was to correct various shortcomings of C have nonetheless inherited the quirks of its syntax.
C has attempted to avoid the use of braces/parentheses/brackets in certain contexts and it has attempted to minimize the number of keywords, but the end result has been the opposite, a typical C program has much more parentheses, braces and brackets than the same program written in a language with a better syntax, like ALGOL 68, or like a non-verbose version of Ada, where the Ada abstract syntax would be preserved but most Ada keywords would be substituted with symbols (such a non-verbose Ada can easily be implemented with a source preprocessor).
In my opinion, a good syntax is of the kind usually called "fully bracketed", as popularized by ALGOL 68, where there are no ambiguities about the extent of a program structure (like the one mentioned by you with C "if", such problems do not exist in ALGOL 68, Ada and similar languages) and there are no alternatives of the kind that exist in C between using a simple statement or a compound statement, i.e. in any location it does not matter if one or more statements are written (this is the feature that makes the specification of statement termination that was used in CPL work without problems), and where several kinds of different brackets are used, not a single kind, e.g. there should be different kinds of brackets for blocks, loops and conditional statements.
Most of the problems that exist in the syntaxes of many popular programming languages are caused by the use of the ASCII character set, which has too few symbols, so it forces the use of some symbols for multiple purposes, which causes ambiguities for parsing.
When Unicode is used instead of ASCII, it is possible to use every symbol for a unique purpose, including the use of different kinds of brackets, and this makes very easy to design a syntax that avoids any kinds of parsing ambiguities.
Indeed, the author of the article even misses on xBase and BASIC, two other famous languages without semicolons.
Honestly I don't mind semicolons; so much that I even type them in Python. (Yes Python has semicolons, they are just optional.) It makes parsing a little bit simpler for both human and automated parsers, it makes statements explicit. There is not really a downside you just type them automatically when you end a statement, like you type Ctrl-S by habit after you stop typing. I find the obsession with semicolon free languages weird.