4 ms·
Extreme take, but the older I get the more I start thinking that the very concept of operators was a mistake, overloadable or otherwise, especially in a systems
by kibwen 3y ago
Extreme take, but the older I get the more I start thinking that the very concept of operators was a mistake, overloadable or otherwise, especially in a systems language. Even for something as simple as addition there's just too many actual operations that I might want to invoke (wrap on overflow, saturate on overflow, crash on overflow, raise exception on overflow, flag on overflow so I can raise later, return boolean to indicate overflow, return tuple of wrapped result and overflowed remainder on overflow).
- wwalexander 3y agoPerhaps operators could only be overloaded, without any defined by the language itself. Then projects could define useful operators for their specific case to make things more terse/infix/etc. while still requiring awareness of their implementation.
- knome 3y agoNo. Haskell made me decide that operators should not be definable by users. It is truly a miserable affair to read terse point free code riddled with operators from a half dozen libraries ( or one overly clever library ). Cleverness is a register that is easy to overflow, and too many don't have to good taste to avoid doing so. Give me names every time.
- hollerith 3y agoDo you consider them as bad as user-definable Lisp or Scheme macros?
- j16sdiz 3y agoIt depends on what you tries to do. Doing linear algebra without any operator overloading is just unreadable
- layer8 3y agoI think GP meant users should not be able to define new operators (as is possible and fairly common in Haskell), but may still be allowed to overload the existing operators.
- wwalexander 3y agoThat’s a good point. I suppose I was imagining something like internal-only operators that could be defined within the scope of a single module but not exported; though I suppose with any sufficiently large module with enough orthogonal pieces you’d still run into arcane and overly-terse operators.
- golergka 3y agoAnd each library will end up with its own semantics.
- lmm 3y agoDon't make "operators" a special case - make them just functions following the normal rules. Scala gets close to this (though sadly it still has some operator precedence rules). To define a function called "plus", you do "def plus" (or "fun plus" or whatever your syntax is). To define a function called "+" you do "def +". It's so much nicer and more consistent. Yes, some library authors abuse it to write functions or classes with dumb names, but you can write dumb names with letters as well.
- phaedrus 3y agoThis is especially well illustrated by the << operator for ostreams in C++.
- whiterknight 3y agoUnfortunately life is complex and all of those semantics are useful. You have to read and write documentation and follow well established conventions (like math).
- kibwen 3y agoBut that's the problem, even the mathematical operations in programming languages don't follow the established conventions of mathematics. And even mathematics overloads operators all the time to mean subtly different things. And even if it didn't, mathematics notation was optimized over centuries for terseness, not for readability, so optimizing programming languages for familiarity with mathematics is optimizing for the wrong thing anyway. We can do better than standard mathematic notation, and that "better" probably looks like "just use properly-named methods or functions that communicate their intent in plain English, not in forbidding moon-runes".
- whiterknight 3y agoThat’s my point. symbols and names are merely suggestive mnemonic devices. They can’t ever specify actual behaviors. Accept it and supplement with English. That’s what math does. You have to read the context. > optimized to tersness That is a form of readability. If you think there is a conflict you need to explain mathematicians wouldn’t care about readability.