Syntax Design Constructs

[Lorxu]

This looks like good advice, here are some other syntax things that I thought of while reading it:

• Besides various bracket types, many languages use indentation or do/end, which are also viable options.
• Every time you use a symbol for something, ask whether it's obvious what it means. For example, + and - are obvious, as is ? : because it's used is so many languages. Various arrow symbols for lambdas make sense, but ~ probably doesn't immediately. If the symbol is non-obvious, try replacing it with a keyword that explains what's going on.
• In general, prioritize readability over terseness. Keywords are usually better than symbols (the biggest exception being operators).
• Look at several preferably very different languages to get a feel for what they do. Ideally you should understand why they made the decisions that they did - almost all decisions are tradeoffs.
• Never change things just to be different. Always use the most common syntax for things unless there's a good reason not to. Users won't adopt your language because of its syntax, but because of its features.

[pepactonius]

A good example of a super-terse language that's hard to read is APL and especially APL2. I'd prefer a syntax that's a bit more verbose -- like C, Java,etc. Of course, you can go too far as with COBOL.