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, bu

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.