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.
-
-
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.
Show 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.
Show this thread
End of conversation
New conversation -
-
-
It already is, through integer promotion
We need the CPUs to be able to handle overflow and expansion to higher bitwithdths natively while still being able to perform bit-fitting operations on the original level.
Ruby, Python and many libs for different languages provide this -
but you are paying a huge overhead for every operation
End of conversation
New conversation -
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.