The english words preference is a cliché that has been argued back and forth, to heaven and hell, since Cobol. I'm sympathetic to your opinion in some cases, but ultimately it fails in my view. Terse notations requires an investment in the beginning but then pay off massively with increased bandwidth, you can hold more of the code in your head. You don't see math being done by (x.plus(y)).pow(3), you see it done by (x+y)^3, it gets even worse when expressions increase in size.

Ideally, the language should have enough syntax-bending facilities so that you can still simulate what you want, this is mostly just operator overloading and not treating custom types like second class citizens. For example, your example of byte ptr ptr can be easily done in C++ by a bytePtrPtr struct, or even better, a Ptr<Ptr<Byte>> instantiated class from the template Ptr<T> for any T. Overloading the dereference and conversion operators will completely hide any trace of the fact it's not a built in type, and compiler optimization and inlinning will (hopefully, fingers crossed) ensure that no extra overhead is being introduced by the abstraction.

As for the 'byte ptr ptr' syntax specifically, in F# generic instantiation can be done by whitespace concatenation of type names in reversed C++/Java/C# order, so the above C++ type would (if translated to F# somehow) literally be written out as you want it to be, so even what seems like it would require language support (whitespace between related identifiers, generally a tricky thing in PL design) can actually be accomplished with clever and free minded syntax.

That is a good point about typedefs, and I would hate to be using 'ADD 1, a, b TO x ROUNDED' instead of 1 + a + b + round(x). I'll also have to check out F#.

I agree, and my ideas for alternative syntax were effectively this. They were, in my opinion, a slight improvement, but still result in lots of syntax. My point is that while I might want a more "python-like" or "ML-like" syntax we often forget that it simply isn't possible in the same way those languages use it, and by the time we add all the extra things we need, it doesn't look that much less "noisy".

> It's more to type and read

I wouldn't even say that. Using words (or multi-letter symbols generally) may be more to type, but virtually everybody uses editors with completion features and those completion features tend to work better with words than symbols. Furthermore, despite there being more characters, I don't think it's actually more to read. People who are fluent in reading languages written with alphabet systems don't read letter-by-letter, but instead read word-by-word, using effortless word recognition.

Typing words is faster than symbols for most folks even without an IDE. Typing `&{% takes way longer than “static long foo”.

> People who are fluent in reading languages written with alphabet systems don't read letter-by-letter, but instead read word-by-word, using effortless word recognition.

It all adds up. Languages like COBOL, PASCAL or ADA (originally designed for terminals with very limited character sets, sometimes even lacking lowercase text - thus requiring case-insensitive syntax) make it a lot harder to survey larger code blocks.

> It all adds up.

If that's true, I would expect logographic writing systems to cause less reader fatigue than alphabetic writing system. But as far as I'm aware that isn't the case, and the two are roughly equivalent.

As far as I know, Chinese speakers read texts on average faster than English speakers

One of the most readable languages that I've ever seen is XQuery, which is also very verbose, and prefers keywords over punctuation.

Considering what XQuery does the syntax does a great job of being readable. Every time I look at React components using JSX I'm unfavourably comparing it to XQuery.