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.
-
Show this thread
-
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.
3 replies 0 retweets 13 likesShow this thread -
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.
2 replies 0 retweets 14 likesShow this thread -
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.
1 reply 3 retweets 30 likesShow this thread -
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.
2 replies 2 retweets 17 likesShow this thread -
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.
7 replies 0 retweets 34 likesShow this thread -
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.
5 replies 12 retweets 73 likesShow this thread -
Replying to @TimSweeneyEpic
What do you think about
#golang ? It seems to meet most (though not all) of the ideas you've expressed in these threads. Was going to wait in ask when you come by the Seattle Epic offices in Feb, but thought I might as well as here. :)1 reply 0 retweets 3 likes
A language needs to thoroughly tackle generics in order to stay on the mainline of the programming language tech tree, which undoubtedly grows to support constructive logic proofs-as-programs.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.