alt Hacker NewsIt is not that I cannot remember the symbols - I don't want to; I want the language to plainly explain itself to me. Furthermore every language has it's own set of unique symbols. For new readers to a language you first have to familiarize yourself with the new symbols. I remember my first few times reading rust... It still makes my head spin. I had to keep looking up what everything did. If the plain keyword doesn't directly tell you what it's doing at least it hints at it.
To be clear Ada specifically talks about all this in the Ada reference manual in the Introduction. It was specifically designed for readers as opposed to writers for very good reasons and it explains why. It's exactly one of the features other languages will eventually learn they need and will independently "discover" some number of years in the future.
Replies
I agree that the use of symbols becomes a problem when you use many programming languages and each of them uses different symbols.
This has never been solved, but it could have been solved if there would have been a standard about the use of symbols in programming languages and all languages would have followed it.
Nevertheless, for some symbols this problem does not arise, e.g. when traditional mathematical symbols are used, which are now available in Unicode.
Many such symbols have been used for centuries and I hate their replacements that had to be chosen due to the constraints of the ASCII character set.
Some of the APL symbols are straightforward extensions of the traditional mathematical notation, so their use also makes sense.
Besides the use of mathematical symbols in expressions, classic or Iverson, the part where I most intensely want symbols, not keywords, is for the various kind of statement brackets.
I consider the use of a single kind of statement brackets as being very wrong for program readability. This was introduced in ALGOL 60 (December 1958) as the pair "begin" and "end". Other languages have followed ALGOL 60. CPl has replaced the statement brackets with paragraph symbols (August 1963), and then the language B (the predecessor of C) has transitioned to ASCII so it has replaced the CPL symbols with curly braces, sometimes around 1970.
A better syntax was introduced by ALGOL 68, which is frequently referred to as "fully bracketed syntax".
In such a syntax different kinds of brackets are used for distinct kinds of program structures, e.g. for blocks, for loops and for conditional structures. This kind of syntax can avoid any ambiguities and it also leads to a total number of separators, parentheses, brackets and braces that is lower than in C and similar languages, despite being "fully bracketed". (For instance in C you must write "while (condition) {statements;}" with 6 syntactic tokens, while in a fully bracketed language you would write "while condition do statements done", with only 3 syntactic tokens)
If you use a fully bracketed syntax, the number of syntactic tokens is actually the smallest that ensures a non-ambiguous grammar, but if the tokens are keywords the language can still appear as too verbose.
The verbosity can be reduced a lot if you use different kinds of brackets provided by Unicode, instead of using bracket pairs like "if"/"end if", "loop"/"end loop" or the like.
For instance, one can use curly braces for blocks, angle brackets for conditional expressions or statements, double angle brackets for switch/case, bag delimiters for loops, and so on. One could choose to use different kinds of brackets for inner blocks and for function bodies, and also different kinds of brackets for type definitions.
In my opinion, the use of many different kinds of brackets is the main feature that can reduce program verbosity in comparison with something like Ada.
Moreover, the use of many kinds of brackets is pretty much self describing, like also in HTML or XML. When you see the opening bracket, you can usually recognize what kind of pattern starts, e.g. that it is a function body, a loop, a block, a conditional structure etc., and you also know how the corresponding closing bracket will look. Thus, when you see a closing bracket of the correct shape you can know what it ends, even when you had not known previously the assignment between different kinds of brackets and different kinds of program structures.
In languages like C, it is frequently annoying when you see many closing braces and you do not know what they terminate. Your editor will find the matching brace, but that wastes precious time. You can comment the closing braces, but that becomes much more verbose than even Ada.
So for me the better solution is to use graphically-distinct brackets. Unicode provides many suitable bracket pairs. There are programming fonts, like JetBrains Mono, which provide many Unicode mathematical symbols and bracket pairs.
When I program for myself, I use such symbols and I use a text preprocessor before passing the program to a compiler.
Rust has a complex semantics, not a complicated syntax. The syntax was explicitly chosen to be quite C/C++ like while streamlining some aspects of it (e.g. the terrible type-ascription syntax, replaced with `let name: type`).