4 ms·
One of the things I love about software engineering is that there are no absolute answers, only trade-offs. You can't memorize your way into software engineeri
by GMoromisato 2y ago
One of the things I love about software engineering is that there are no absolute answers, only trade-offs.
You can't memorize your way into software engineering. You can't say, "always wrap-around when an operation overflows" or "always tell the user (panic) when an operation overflows".
This article is a great example. C wraps unsigned integer addition on overflow, but Python upscales to arbitrary integer sizes. The trade-off, of course, is performance. If you're writing a real-time engine (for a rocket or a video game) and you can guarantee integer sizes, then you need to use the fastest algorithm possible. But if you're writing a general-purpose calculator, you might prefer upscaling or at least catching overflows and informing the user.
In almost any other disciple there would be a "correct" way to do it, or at least an accepted "best practice." But for software engineers, it's always, "it depends."
- cratermoon 2y ago> You can't say, "always wrap-around when an operation overflows" or "always tell the user (panic) when an operation overflows". If you were designing the flight software for the Ariane 5, which choice would you make?
- GMoromisato 2y agoI understood that reference. But it just reinforces my point that there are no absolute rules. You have to think.
- TeMPOraL 2y agoThe important choice was made elsewhere: flight termination system successfully self-destructed the rocket once it was unlikely to recover from its problem. The Wiki quotes an interesting sentence from the official report - "An underlying theme in the development of Ariane 5 is the bias towards the mitigation of random failure." It's fortunate that that bias didn't extend to flight termination system. At the point flight control software intersects with real life, it's better to destroy an expensive rocket than have it rain fiery hell on some random people somewhere else. That principle holds to this day.
- wang_li 2y ago> If you were designing the flight software for the Ariane 5, which choice would you make? I would take note of the underlying hardware and what range of inputs are allowed and code appropriately. Stop pretending that your software doesn’t have a specific purpose and will run on an actual computer. If you’re doing finance you should be using fixed point integer arithmetic with two or three decimal places. If you’re doing physics simulations you need to be aware of how many significant digits exist. If you ignore your problem space and the kind of system your code is going to run on you’re living in spherical cow world and it doesn’t matter if you over- or under-flow because your software is garbage anyway.
- gizmo686 2y agoThat is exactly what was done with Ariane. It lead to a complete failure and self destruct. In Ariane 4, they realized that an overflow was physically impossible, and so removed the check for efficiency reasons. The module containing the software ended up being reused on Ariane 5, where the overflow ended up being very possible.
- Zamiel_Snawley 2y agoSaturation arithmetic doesn’t get enough love, either. I’ve heard Zig has convenient facilities for it.
- GMoromisato 2y agoI didn't know it was called that, but I agree! Clamping is a valid option for overflow.
- IshKebab 2y agoThere are plenty of absolutes. People just don't talk about them much because there's not much to say: * binary is the best way to encode information and numbers * twos complement is the best general purpose way to encode negative integers * static typing and stronger typing lead to fewer bugs * length prefixes are better than using sentinel values and escaping > In almost any other discipline there would be a "correct" way to do it Tell me you know nothing about anything except computers without... You think there's a "correct" way to build a bridge?
- GMoromisato 2y agoI was a little sloppy. But the difference between software engineering and building bridges is that absolutes in software engineering are automated away. If there is an always correct way to do something, then the hardware/software always does it that way and we don't expose a choice to the software engineer. When a choice is exposed to the software engineer it is because there is a trade-off. In contrast, when making concrete, there are valid and invalid ratios of water/cement/etc. You have to memorize (or lookup) the correct ratios. Building a bridge is filled with things you have to look up or just compute from basic parameters. Of course there are engineering trade-offs in building a bridge. But there are also many "just follow the algorithm" procedures. In software engineering, it's all trade-offs! Almost by definition, if there is a choice, it's a trade-off that requires human judgement, otherwise, the choice would be made for you by the computer.
- poincaredisk 2y agoWell even your examples... * two's complement is the best general purpose way (tradeoffs!) * static typing leads to fewer bugs (but makes development slower - tradeoffs) * length prefixes are better than sentinels - but the largest system language uses sentinels for strings (because prefixes are not actually always better, be and sentinels were deemed better by its creators)
- IshKebab 2y ago> general purpose way (tradeoffs!) Not really I was more hedging against HN pedantry... > but makes development slower - tradeoffs No it doesn't. It makes development faster! > because prefixes are not actually always better, be and sentinels were deemed better by its creators Because they got it wrong.