Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

IEEE 754 doesn't really have anything to say about which semantics you should choose for int/int division. If you choose the semantics of casting both operands to floating point and then dividing, IEEE 754 specifies both 1) how the int->float conversion should happen, and 2) how the float/float division should happen. But if you choose the semantics that int/int division returns an int without any floating-point conversions (like C's '/' operator), then no floating point numbers enter into the question at all, and it's out of scope for IEEE 754.


Over thirty years of programming I've slowly become convinced that implicit conversions are the devil.


This devil allows high productivity though.


Not everybody is convinced that it's "more productive" to produce more bugs.


Pareto, context and objectives are importort factors in that decision.

Coding a 5 lines bash script in rust brings safety but it's not a win.


If the bash script had an incorrect value due to an implicit conversion, then yes, the rust implementation is clearly a win.


So, context.


Not everybody, but probably enough people. Actually you could even build your career around it. Some guy got into office at night time to fire estinguish the problem his buggy code created. Got appraisal from management for such extra effort. Everybody else's not so buggy code didn't get that appraisal...


Bingo. When performance is the overriding goal, it is often a matter of choosing which deals to do with which devils.


Must be down to all those idle hands he can bring to bear on a given task.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: