3 ms·

> it's criminal that you can write 1/2 and get values nowhere near one-half This is a foolish argument and Guy Steele should know better. What makes 1/2, which

by kibwen 3y ago

> it's criminal that you can write 1/2 and get values nowhere near one-half This is a foolish argument and Guy Steele should know better. What makes 1/2, which has an accurate floating point representation, any more important than 1/10, which doesn't? Every novice programmer, every single one, trips over floating point, and pretending that floating point numbers match our intuition from mathematics doesn't do anyone any favors.

deleted 3y ago
[deleted]
tinco 3y ago
I don't think his attention was specifically to have 1/2 be a floating point number, like for example Javascript does, but to call to attention the fact that we design programming languages for a specific audience, not realising that if we widened our perspective it could be intuitive for a much wider audience. For example, Ruby was designed for experienced software developers. Experienced software developers expect that if you divide an integer by another integer, that it performs integer division, and 1/0 would be 0 in integer maths. If the creator of Ruby had broadened their horizon, and instead realised that outside the world of experienced software developers, the expression "1/2" means something totally different, maybe they could have chosen a different behaviour. In a different universe perhaps any numeric literal in Ruby would always be a `Number` (like in Javascript), that for division would instead return a `Rational`. So that the end user could at the end simply call `.to_i` or `.to_f` or `.to_s` according to their needs. I don't know if that would be a better universe though. I agree with your point that every programmer eventually needs to learn about floating point numbers and their sometimes surprising properties. And in the end Ruby was designed for programming computers, and the goal of any programming language is to expose the abilities of a computer, which include at the core integer maths, however surprising that maths might be to a novice.
- nordsieck 3y ago
  > If the creator of Ruby had broadened their horizon, and instead realised that outside the world of experienced software developers, the expression "1/2" means something totally different, maybe they could have chosen a different behaviour. IMO, that would be a tragedy. In every language that does it implicit type coercion is the cause of a litany of bugs. It's the cause of many problems in php. It's why people are told not to use == in javascript. Maybe it is more difficult for beginners. But people are only beginners for a couple of weeks. It makes no sense to design the language to make those couple of weeks a little better and the rest of their programming lives a lot worse.
  - tinco 3y ago
    I agree, but I didn't suggest implicit type coercion. The bugs in Javascript are because of type coercion, but that has nothing to do with the fact that numbers in typescript are all floats. I don't think there are many bugs in Javascript that are due to numbers being floats, though I bet there's some companies who decided to build their backend in Javascript that might eventually run into problems. There's ways to design a number class that doesn't suffer from any of these problems (obviously it would have to sacrifice performance to some degree).
- igouy 3y ago
  > In a different universe "Cuis-Smalltalk computes with rational numbers." https://cuis-smalltalk.github.io/TheCuisBook/Writing-your-first-scripts.html https://cuis-smalltalk.github.io/TheCuisBook/Writing-your-fi...
MrJohz 3y ago
That's an argument for being more careful with floating point operations, and perhaps not using them as a default numeric value, but it's not what Steele is talking about there. After all `1/10` in Python is still pretty close to one tenth, even if it's not quite there. The question here is whether or not we should assume integer semantics for numerical values.
regularfry 3y ago
I suspect that the real answer to this should be that the representation should remain as a rational until it can't. Forcing it into either float or int at the point of entry is the mistake.

by kibwen 3y ago

deleted 3y ago

[deleted]

tinco 3y ago

I don't think his attention was specifically to have 1/2 be a floating point number, like for example Javascript does, but to call to attention the fact that we design programming languages for a specific audience, not realising that if we widened our perspective it could be intuitive for a much wider audience. For example, Ruby was designed for experienced software developers. Experienced software developers expect that if you divide an integer by another integer, that it performs integer division, and 1/0 would be 0 in integer maths. If the creator of Ruby had broadened their horizon, and instead realised that outside the world of experienced software developers, the expression "1/2" means something totally different, maybe they could have chosen a different behaviour. In a different universe perhaps any numeric literal in Ruby would always be a `Number` (like in Javascript), that for division would instead return a `Rational`. So that the end user could at the end simply call `.to_i` or `.to_f` or `.to_s` according to their needs. I don't know if that would be a better universe though. I agree with your point that every programmer eventually needs to learn about floating point numbers and their sometimes surprising properties. And in the end Ruby was designed for programming computers, and the goal of any programming language is to expose the abilities of a computer, which include at the core integer maths, however surprising that maths might be to a novice.

nordsieck 3y ago
> If the creator of Ruby had broadened their horizon, and instead realised that outside the world of experienced software developers, the expression "1/2" means something totally different, maybe they could have chosen a different behaviour. IMO, that would be a tragedy. In every language that does it implicit type coercion is the cause of a litany of bugs. It's the cause of many problems in php. It's why people are told not to use == in javascript. Maybe it is more difficult for beginners. But people are only beginners for a couple of weeks. It makes no sense to design the language to make those couple of weeks a little better and the rest of their programming lives a lot worse.
- tinco 3y ago
  I agree, but I didn't suggest implicit type coercion. The bugs in Javascript are because of type coercion, but that has nothing to do with the fact that numbers in typescript are all floats. I don't think there are many bugs in Javascript that are due to numbers being floats, though I bet there's some companies who decided to build their backend in Javascript that might eventually run into problems. There's ways to design a number class that doesn't suffer from any of these problems (obviously it would have to sacrifice performance to some degree).
igouy 3y ago
> In a different universe "Cuis-Smalltalk computes with rational numbers." https://cuis-smalltalk.github.io/TheCuisBook/Writing-your-first-scripts.html https://cuis-smalltalk.github.io/TheCuisBook/Writing-your-fi...

MrJohz 3y ago

That's an argument for being more careful with floating point operations, and perhaps not using them as a default numeric value, but it's not what Steele is talking about there. After all `1/10` in Python is still pretty close to one tenth, even if it's not quite there. The question here is whether or not we should assume integer semantics for numerical values.

regularfry 3y ago

I suspect that the real answer to this should be that the representation should remain as a rational until it can't. Forcing it into either float or int at the point of entry is the mistake.