Comment by cubefox | Hacker News Reader

Comment by cubefox | Hacker News Reader

Parent Full thread

Setting aside the the elephant in the room (modern coding LLMs are in some sense indeed compilers for natural language -- except they still "compile to" ordinary programming languages) it nonetheless seems to me that even conventional programming languages use too little, not too much, natural language.

Example:

- "&&" rather than "and",

- "||" rather than "or",

- "if (A) B" rather than "if A then B"

This only makes the code harder to read for beginners without apparent benefit. I'm not sure whether Dijkstra would have agreed.

Thankfully though, programming languages already use mostly explicit (English) language in function names. Which is a much better situation than in mathematics, where almost every function or operator is described by a single nondescript letter or symbol, often even in Greek or in a weird font style.

There is a tradeoff between conciseness and readability. Mathematics has decided long ago to exclusivly focus on the former, and I'm glad this didn't happen with programming. If we read Dijkstra as arguing that only focusing on readability (i.e., natural language) is a bad tradeoff, then he is right.

I suspect Dijkstra would have disagreed with you about "and" and "or", judging from his criticism of the technical report which had the line "even the standard symbols used for logical connectives have been avoided for the sake of clarity".

Personally I think one advantage of '&&' and '||' is that it's clear they're a notation that you need to know the syntax and semantics of. For instance typically '&&' is "short-circuiting" and will not evaluate its RHS if the LHS is true; a natural-language "if a and b then ..." doesn't suggest that critical detail or necessarily nudge you to go and check. (Not that Dijkstra was in favour of short-circuiting logical operators, to judge by https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD100... point 4...)

More generally, I'm not sure of the benefit of tailoring the language syntax for beginners rather than experienced practitioners; the advantage of '&&', '||' and the rest of the "C-like" syntax stuff in a new language is that it's familiar to a wide base of existing experienced programmers.

We could have "and" and "cand" (conditional and, his terminology), which would be more explanatory. Or we use "and" (conditional) and "ncand" (non-conditional and). Depending on which should be the default.

> More generally, I'm not sure of the benefit of tailoring the language syntax for beginners rather than experienced practitioners; the advantage of '&&', '||' and the rest of the "C-like" syntax stuff in a new language is that it's familiar to a wide base of existing experienced programmers.

At one point in time every awkward and outdated syntax was the more familiar option, but that's of course not a good argument not to improve it, otherwise we would be stuck with it forever.

Working a bit with some old programming languages that are very natural language like (FORTRAN’s .and. and .or. or COBOL’s IS GREATER THAN) I don’t think the readability increases that much, maybe the benefit is more approachability. In a more symbolic language skimming code is much easier because the symbols provide visible distinction between more syntactic control flow and the declared functions, variables etc.

Note that only about 1/3 of this critique (the last example, and with slightly different actual syntax in place of the preferred syntax) of "conventional programming languages" applies to the #1 language on the Tiobe index, which does, in fact, use and instead of && and or instead of || but uses ":" instead of "then" in if statements.

Yeah that was more a criticism of the common C syntax. The use of the colon in Python is pretty good as it mirrors the usage in ordinary text. Though it still follows the pattern "if (A): B else: C" with parentheses around A. That seems superfluous.

(Unfortunately Python also follows the herd in using "=" for assignment and "==" for equality. It should arguably be "<-" or ":=" for assignment and "=" for equality. But that's a matter of asking for better symbols rather than of asking for better English operator names.)

> The use of the colon in Python is pretty good as it mirrors the usage in ordinary text. Though it still follows the pattern "if (A): B else: C" with parentheses around A.

Python doesn't require parens for the condition in an if-statement, and the default settings of black or Ruff formatters will remove them if present where not needed. (They can be needed if, e.g., you are breaking a condition across multiple physical lines.)

> Unfortunately Python also follows the herd in using "=" for assignment and "==" for equality. It should arguably be "<-" or ":=" for assignment and "=" for equality.

Note that Python uses ":=" for the assignment expression operator as well as "=" for the simple assignment statement operator.

For && and || I disagree: they are 'shortcircuiting' operators and as such they deserve a différent name than just 'and', 'or'. That said &| should have been named and,or which would have freed &| to use for the shortcircuit operators.

Friend, this filter is a feature not a bug.

Reply on news.ycombinator.com