it's terrible advice for actual programmers though because often 0 is a sentinel value with special meaning for systems that you don't have control over (sometimes because of pre-digital conventions that shouldn't be lightly fucked with).
This is usually done by PL's that want to avoid crashes at all costs, but "turning crashes into subtle logic errors" seems like a really bad idea.
"As mentioned before, this is not a post about what’s practically a good idea. All I’m arguing is that mathematically, we can extend division in this way without leading to a contradiction. Programming languages are different from mathematical formalisms, and should be different. I prefer that 1/0 is an error, because I’m not using my program to prove theories."
Please do yourself a favor and actually read it.
Besides, 0 as a sentinental value on disk or on the wire is fine, but once you have values in a programming language, use option types. This is not 1980s anymore, you don't need to use 0 or -1 or 0xffff to express something special which sooner or later just falls on your feet.
I read the article. As someone who was a math major I get why it's "fine". But nowhere in the article does hillel explain WHY it's bad for a real pl. (And defenders of e.g. pony gleam point to this article too to say it's okay. It's not.) I am adding context.
> This is not 1980s anymore, you don't need to use 0 or -1 or 0xffff to express something special which sooner or later just falls on your feet.
No. You missed the whole "real world systems". E.g. like stock trading, where zero stock trades are tombstones.
Ah, that's apprecitated. Indeed, he didn't provide that "why" and tbf that wasn't the point of the article. But thanks for adding that context.
> You missed the whole "real world systems". E.g. like stock trading, where zero stock trades are tombstones.
Hm I don't think I missed that. This counts as "on the wire". Externally, there are surely good reasons for that representation, though I'd argue that internally it's better to represent this in the type system instead of special casing 0 everywhere which can be forgotten and then you get your (potential) division-by-0 issues. Avoiding them by construction is even better than failing explicitly (which I agree is in turn still better than silently returning 0).
you dont have control over it. if you emit a zero stock trade your broker's account (a system outside of your control) it might get zeroed instead of having "no shares bought". this could happen for example if you periodically buy a quantity of shares based on some average of some measurement and zero measurements got taken over the time window. and you can't make that "irrepresentable in the type system" if you didn't know that in advance. did you know that it is a convention that zero stock trades were tombstones?
or imagine your are building something that flies a plane and airspeed is measured as an average of some measurements, and the instrument flakes over your sampling interval. all of a sudden your system thinks you are at a stop. erroring is better because no further instructions based on incorrect data will propagate and shit in the pool.
1/0=0 does not immediately make you stop and think well wait a second, and it could even be hidden behind an function like avg(...)
if you want a nocrash division that's fine but it shouldn't be "/"
This is usually done by PL's that want to avoid crashes at all costs, but "turning crashes into subtle logic errors" seems like a really bad idea.