The ideal performance property we should ask of a high-level programming language and library is that it minimizes runtime and compile-time combinatorial complexity. We can accept constant overheads, but not higher-order overheads. This has many implications.
One is that containers should be designed to minimize asymptotic complexity of operations. If concatenating strings is O(m+n), we’re doing it wrong. This means we can’t expect nice linear arrays in memory, but must pay some sort of dynamic control flow cost for accessing them.
The other is we should never copy a non-constant-sized data structure, but ensure it can be used in all contexts as-is or with the help of a constant sized adapter.
Next, we have to abandon manually synchronized memory concurrency. The combinatorial complexity here isn’t in performance but in programmer reasoning. We must either stay single-threaded or adopt purely functional programming or transactions.
Finally, types should obey the mathematical properties expected of them. This means we must adopt mathematical integers, and if we support smaller integer storage formats, they are still just for storage. The byte 255 plus the byte 1 is not the byte 0, it’s the integer 256.
If we support floating point, then the float 1.0f can’t be equal to integer 1, because there exist functions f where f(1.0f) is unequal to f(1), and a==b implies that for all f, f(a)==f(b). We must either say 1 is not equal to 1.0f, or that we aren’t allowed to compare them.
Programming languages should be built on principles first and foremost, and avoid conveniences that violate principles. So much of what’s wrong today is the result of design by “wouldn’t it be nice if” without an earnest enumeration of guiding principles.
