I disagree with the author on operator overloading. They claim that this function in C
float foo(float a, float b) {
return a+b;
}
is perfectly clear because you know it's doing floating point addition, while this function in Python isn't
def foo(a, b):
return a + b
because you don't know if it's floating point addition, integer addition, or string concatenation, and what happens if the inputs are different types?
I think that's fundamentally mistaken. You could also ask of the C version if it's doing normalized floating point addition, denormalized floating point addition, infinity addition, or NaN propagation. What happens if you mix different types of floats? And the answer is that it doesn't matter. These are all just aspects of floating point addition. It returns the most sensible result in whatever format is best to hold that value, and you don't need to worry yourself about how floats are stored under the hood.
The same is true of the Python version. It doesn't matter if it's integer addition or floating point addition or string concatenation. Those are just different aspects of the addition operator and it returns the most sensible result in whatever type is best to hold that value.
Agreed. I think operator overloading is a necessary feature in any math-oriented or general-purpose language. Being able to write formulae the same way as they're written in the source paper is a huge boon to readability.
Totally agree, trying to use BigInt in Java sucks because there's no operator overloading
This post is overlaps ...
*This post overlaps
I am not sure I want to read the rest.
There are a ton of typos in this post, missing semicolons, "you" instead of "your", "then" instead of "than"... that's just the first sentence
Also Vector2f instead of Vector3f for the cross product example. I'll give them the benefit of the doubt that that's a typo instead of them not knowing what a cross product is.
Honestly, I did not find that particularly convincing. Lot of typos and leaps in logic. The point is probably kind of true?!?
I disagree with the author on operator overloading. They claim that this function in C
is perfectly clear because you know it's doing floating point addition, while this function in Python isn't
because you don't know if it's floating point addition, integer addition, or string concatenation, and what happens if the inputs are different types?
I think that's fundamentally mistaken. You could also ask of the C version if it's doing normalized floating point addition, denormalized floating point addition, infinity addition, or NaN propagation. What happens if you mix different types of floats? And the answer is that it doesn't matter. These are all just aspects of floating point addition. It returns the most sensible result in whatever format is best to hold that value, and you don't need to worry yourself about how floats are stored under the hood.
The same is true of the Python version. It doesn't matter if it's integer addition or floating point addition or string concatenation. Those are just different aspects of the addition operator and it returns the most sensible result in whatever type is best to hold that value.
Agreed. I think operator overloading is a necessary feature in any math-oriented or general-purpose language. Being able to write formulae the same way as they're written in the source paper is a huge boon to readability.
Totally agree, trying to use BigInt in Java sucks because there's no operator overloading
*This post overlaps
I am not sure I want to read the rest.
There are a ton of typos in this post, missing semicolons, "you" instead of "your", "then" instead of "than"... that's just the first sentence
Also Vector2f instead of Vector3f for the cross product example. I'll give them the benefit of the doubt that that's a typo instead of them not knowing what a cross product is.
Honestly, I did not find that particularly convincing. Lot of typos and leaps in logic. The point is probably kind of true?!?