6 ms·
You see similar issues with e.g. Haskell or a lazy FP languages where certain idioms behave wildly different from each other. Ultimately I'm not sure what his
by snagglegaggle 7y ago
You see similar issues with e.g. Haskell or a lazy FP languages where certain idioms behave wildly different from each other.
Ultimately I'm not sure what his complaint is. He says "If it takes too long, or takes no time at all, that’s not the language’s concern, strictly speaking." Would you trade correctness for speed? Would you make programs maintain poor performance in the face of hardware upgrades?
What is the point of either?
- _bxg1 7y agoI don't think he's complaining so much as pointing something out. All programming is abstraction. Even binary could be seen as obscuring the analog physical properties of the chip. What you have to decide is what level of abstraction best presents the things you care about, and sets aside the things you don't. I personally always lean towards abstractions that are strong when it comes to correctness, even if that means they're leaky when it comes to performance. You can always go back and optimize later. This is why I hate writing C(++). At the language level they may enforce correctness assumptions well enough, but abstractions written in them are incredibly leaky in terms of correctness.