Weak ordering only makes sense when you have two ways to determine equality. A filesystem can be "equal as a string" or "equal as a location". This pair of strong ordered set of operations/measurements are much easier to deal with. If only we had C++ syntax to support that. Do equality as a string on 2 filepath objects. Or do equality as a "location" on 2 filepath objects. You get that with static cast, but this sloppy notation is what drives program designers to make mistakes because they aren't thinking about types. It's the same problem as he quoted Knuth stating, at 9:21 - not thinking about objects/operations with different mathematical rules causes errors. If it was a helpful thing to read, especially to the uninitiated, then it would be used more. (Auto actually helps with this as it eschews the need for unnecessary declarations of type - it increases the signal to noise ratio for types) Rust, with it's "object as i32" notation surely is the same thing as "static_cast(object)", but one's a lot closer to what my thoughts already are. Even if C++ can't fix that situation, we can goddamn work around it with strong and weak ordering. Syntax and making it natural expressions of thought is really important. It was a huge discovery that the 1956 compiler made apparent. Even the brightest minds will make mistakes in translating thought to code when the code doesn't map perfectly to thought. Not "well", but "perfectly". I don't think strong and weak order will every map perfectly to human thought. I think they need to be in C++ though, because it has to respect backwards compatibility.
The fact that enforces sane-ness between < > != with such ease is the best argument for it, to me. He makes it sound so simple!
I usually am able to follow talks like this, but this one was way over my head. Opened my eyes to weird maths stuff I never knew about.
More talks from Ben please.
Weak ordering only makes sense when you have two ways to determine equality. A filesystem can be "equal as a string" or "equal as a location". This pair of strong ordered set of operations/measurements are much easier to deal with. If only we had C++ syntax to support that. Do equality as a string on 2 filepath objects. Or do equality as a "location" on 2 filepath objects.
You get that with static cast, but this sloppy notation is what drives program designers to make mistakes because they aren't thinking about types. It's the same problem as he quoted Knuth stating, at 9:21 - not thinking about objects/operations with different mathematical rules causes errors. If it was a helpful thing to read, especially to the uninitiated, then it would be used more. (Auto actually helps with this as it eschews the need for unnecessary declarations of type - it increases the signal to noise ratio for types)
Rust, with it's "object as i32" notation surely is the same thing as "static_cast(object)", but one's a lot closer to what my thoughts already are. Even if C++ can't fix that situation, we can goddamn work around it with strong and weak ordering.
Syntax and making it natural expressions of thought is really important. It was a huge discovery that the 1956 compiler made apparent. Even the brightest minds will make mistakes in translating thought to code when the code doesn't map perfectly to thought. Not "well", but "perfectly". I don't think strong and weak order will every map perfectly to human thought. I think they need to be in C++ though, because it has to respect backwards compatibility.
What about getting overloaded with operators?
My eyes are widened.
Great talk
% is the percent sign which wikipedia tells me has been in use since the 17th century, just sayin.
But not as a binary modulus operator, which was his point.