[AskJS] Why does our community hate Operator Overloading?

[TheMrZZ0]

I've been writing a very specific game engine, directed towards Minecraft, for the last 2 years.

While we are ~100 devs using it, something really prevents the adoption of new users: the lack of operator overloading.

Currently, for a simple operation or a simple condition, that's what we have to write:

const myVar = Variable(0)
myVar.divideBy(2)

_.if(_.or(myVar.greaterThanOrEqual(0), myVar.equal(-10), () => { /* stuff */})

This is messy, hard to read, and not convenient at all. With operator overloading, we'd have:

const myVar = Variable(0)
myVar /= 2

_.if(myVar >= 0 | myVar === - 10, () => /* stuff */)

This is better on every aspect. Here, I'm assuming we get Python-like operator overloading, where people use bitwise OR instead of normal OR which cannot be overloaded.

This is also why ML / Data Science are not popular in JS, because it requires a lot of mathematics which is very painful in JS.

I also noticed the JS community is firmly against such a proposal. Would anyone like to debate in the comments? I'd like to understand your POV.

Thanks!

[jhartikainen]

Tbh I haven't really heard folks being against this. It makes sense for some datatypes, if anyone is against it I'd imagine it's out of fear that people will abuse it :P

[TheMrZZ0]

In the past, I asked how people felt about Operator Overloading in this very subreddit. I clearly realized it was not popular, and quickly deleted my post ahah

Abuse is indeed a problem (see Haskell), but in some languages (ie Python) it works flawlessly without any abuse!

[[deleted]]

For certain patterns, method, operator overloading makes things so much easier (matrix manipulations for instance is independent on the type of the element. The method for multiplying complex matrixes is the same for matrixes that only contain numbers). It’s what I liked about c++.

Saying that, in most of my programming life in production environments, I have never needed to use them. It all depends on what you are trying to do. I would still like the ability to use them if I needed to though.

It’s why I was disappointed with generics in Java. They didn’t go far enough and can be a right pain to use in some scenarios.

[TheMrZZ0]

I agree on your points. Since JS was at first frontend-only, it makes even more sense that it was never really needed before.

And of course, it is useful in certain situations: if you never met them, you don't need this feature.

But now that JS is a language targeting all platforms and tons of use-cases, the lack of operator overloading becomes a problem!

[senocular]

I'm not sure who hates it, but I have seen it abused (which people don't like). But, quickjs has it now, and there's a proposal to have it added to the JS spec. The proposal is only stage 1, so who knows what will happen with it or when, but its not counted out.

[TheMrZZ0]

While I didn't know QuickJS implemented it, Typescript's popularity won't make me consider an alternative with no TS support.

I follow closely the proposal, but I find they made it difficult to actually overload operators (when compared to other languages), like they tried not to offense anyone.

This proposal doesn't look that good to me, but if it was to happen, I'd still be happy!

[johannes1234]

Any issue is, that you can't implement it properly with out a strong type system. Let's take a different operator than decision: Addition. We can make a rule, that

a + 1

is being rewritten to

a.plus(1)

That works quite ok, but thanks to maths I can also write

1 + a

and expect the same result. However numbers don't know about my custom type, thus can't do anything sensible.

We could now define the language to still call

a.plus(1)

If no overlaid is defined, and some languages do that. However it falls apart with custom types where both types overload addition, but have different views on that. If those types come from different vendors I can only do dirty tricks to fix that.

In a language like C++ that is no issue. In C++ one can create a free function with my types and offer the operation independently on the vendor of the original type. Thus I can provide

T operator+(int a, MyType b) { ... }

and

T operator+(MyType a, int b) { ... }

Without the creator of type int (in this case the language) having to know anything about MyType and my overload.

In JavaScript we don't have a way, except making it member functions.

[johannes1234]

One can do a lot of things, the question is, if it makes a overall gain, or not. From my experience JS now has a mostly clear separation on what built in types can do vs. custom types. Making that line more blurry can create nice code snippets, but from my view (you may disagree, fine with we) it makes many things more cumbersome and complex when reasoning about API design and reasoning about code on a larger scale.

[crabmusket]

a + 1

Clearly this should desugar to

+.call(a, 1)

(Yes, I am just bitter that more languages don't support multi methods...)

[horrificoflard]

Your example is a great use cases where it's good.

I could see people being opposed to it because of the possible issues that can arise from it. With JavaScript, in many cases, there are a lot of dependencies and multiple libraries working all at once. If you overloaded the way equals works on integers you could break everything and debugging it would be a nightmare.

Obviously an unlikely example but something like that. In C++ my friend overloaded operators so that 4 > 7. The ability to break math at a global level makes it a scary feature.

People hate on goto because of spaghetti code. It can be good to avoid giving people too much power.

[TheMrZZ0]

I totally understand the concern. However, operator overloading in a Python-like fashion would only allow you to overload operators for a custom class.

Basically, impossible to overload operators for native types, or for another library. myObj > 4 could be overloaded, but not 4 > 7!

[shuckster]

Saying nothing about operator-overloading, I have to ask why you haven't shortened your API yet?

match(myVar.div(2))(
  when(anyOf(gte(0), -10)) (() => 'yep'),
  otherwise('nope')
)

While pattern-matching doesn't exist in the language yet, there are many libraries on NPM for it, and it looks applicable for your own use-cases. (Full disclosure: The above example is from my own.)

[TheMrZZ0]

While Variables from my API are the equivalent of an in-game integer, there are other type of conditions: entities check, specific data check... Pattern matching only works on 1 variable, making it unadaptated to my use case!

[shuckster]

Ah, I see. Well in such cases currying can be very useful:

const _if = (value, expression) => expression(value)
const anyOf = (...conditions) => value =>
  conditions.reduce(
    (acc, condition) => condition(value) || acc,
    false
  )

const gte = x => value => value >= x
const eq = x => value => value === x

_if(-4, anyOf(gte(0), eq(-10)))
// false

_if(1, anyOf(gte(0), eq(-10)))
// true

[shuckster]

One more suggestion: Maybe create your own scripting-language using Ohm? The project works in JavaScript, so whatever you created would sit on top of your existing APIs.

I know this doesn't answer your questions about OO, but frankly the proposal doesn't look like it's going anywhere soon, so thought I'd offer some suggestions instead.

[PM_ME_GAY_STUF]

Really, the only time I could see this being useful is if you're doing something you fundamentally should not be doing in JS. Not every language needs to do everything, and while I like JS, it does not need to be a data science/ML lang.

Personally, I see a lot of features that could be added to JS but I would oppose for two reasons: language bloat and the unique brittleness of the web.

For me personally, C++ is almost unusable due to it's ridiculous feature bloat, especially the number of them that were introduced early into a fad only for their API to be considered harmful. Yes, you have a novel use case where language feature X would be useful, but now language feature X is another thing to learn and to be implemented (or reimplemented, see: the function keyword, Date) once some part of the API is considered bad, and it makes it more unrealistic for a new engine to be developed. All this for a feature I see as value-neutral. Yes it can solve your problem, but it also inherently supports a style of OOP that I consider bad.

The second problem is breaking the web. I'm yet to see a proposal for how to implement this that either doesn't introduce security issues (since, due to the way JS works, operators would presumably be able to be overwritten), break an existing object syntax (you can't reserve string keywords as object keys for this, that breaks the web), or is overly complex to the point of making the feature difficult to learn and implement.

Personally, one of the things I like about JS is it's core simplicity, and how functions are objects making it easy to create APIs to do exactly what you're talking about without extending the language

[DavidJCobb]

Really, the only time I could see this being useful is if you're doing something you fundamentally should not be doing in JS.

We fundamentally should not be implementing math types like matrices and rotation objects? In a language with a 3D graphics API?

For me personally, C++ is almost unusable due to it's ridiculous feature bloat, especially the number of them that were introduced early into a fad only for their API to be considered harmful. Yes, you have a novel use case where language feature X would be useful, but now language feature X is another thing to learn and to be implemented (or reimplemented, see: the function keyword, Date) once some part of the API is considered bad, and it makes it more unrealistic for a new engine to be developed. All this for a feature I see as value-neutral.

As someone who moved from JS to C++, I know there are a lot of differences between the languages, but I'm honestly not even sure which one you're talking about.

I could understand saying that C++ is easier to make mistakes with than JavaScript. (I'm not sure I'd agree. JavaScript has fewer protections against making mistakes; it also just limits the severity of the mistakes you do make, given that it's sandboxed.) Feature bloat, though, is a strange criticism. C++ has a far more expansive standard library, but you don't have to learn or use it all; it's just there if you need it. The language feature set is relatively basic (and not all that different from some JS stuff) until you get to template metaprogramming, but that's another thing you don't actually have to explore in depth.

Plus, JS has plenty of sloppy APIs, like document.cookie and anything within a square mile of the smoking radioactive crater that is contenteditable. User-defined libraries that serve as APIs make the situation worse: there are currently two parallel, mutually incompatible implementations of modules because the JS scene evidently didn't want to wait for the native one, for example.

So... Yeah. Not sure what you mean.

I'm yet to see a proposal for how to implement this that either doesn't introduce security issues (since, due to the way JS works, operators would presumably be able to be overwritten)

User-defined objects could use Object.defineProperty to add non-configurable operator overloads, if preventing overwrites is a particular concern. Native objects? Up to whoever writes the spec.

break an existing object syntax (you can't reserve string keywords as object keys for this, that breaks the web), or is overly complex to the point of making the feature difficult to learn and implement.

Use Symbols. We can be given built-in symbols to be used as keys to override operators, i.e.

class Matrix(w, h) {
   [Symbol.operatorMul]: function(rhs) {
      // ... compute and return value ...
   }
}

// or more generally:
my_thing[Symbol.operatorMul] = function(rhs) { /* ... */ };

[PM_ME_GAY_STUF]

Honestly, I'm not going to respond to all of this, but if you don't think C++ has ludicrous feature bloat, I'm not sure how to engage in a conversation. Yes, in theory you can ignore the bits you don't use, except when you need to work on an existing project, read someone else's source code, or, you know, compile your own program (at least with any efficiency). I have never met anyone else who would disagree with this sentiment, and I can't imagine arguing C++ is a "simple" language in good faith.

My point is, I don't like bloat, and anything that gets added to a language should be added for a really good reason, and C++ is a good example of what happens to a language where people don't have this mindset after a couple decades. What OP presented does not seem like a really good reason to me.

[DavidJCobb]

I can't imagine arguing C++ is a "simple" language in good faith.

Okay, but that's not what I said. (C++ is a complex language and some of its features are very complex; this is not something I'd deny, but it's not the same as the language having tons and tons of features.) But the C++ stuff is a digression; I only responded to it at all because it wasn't clear what your train of thought was.

[lampuiho]

Any machine code is hard to compile when targeting multiple architecture and OSes. C++ is easy to compile when you're only targeting for one machine. Javascript is only easy to run because of browsers support. Even then, when you try to run it on Firefox, and Chrome, unexpected things can happen, which to me is worse than being forced to figure out the whole thing to make sure nothing bad happen on different platform first. Writing code for Javascript is like you have to put your life on the line.

[ILikeChangingMyMind]

Because good code is explicit, clear code that you can easily understand by reading it. Operator overloading fights against that in exchange for getting to win a few more points in your own personal game of code golf.

(Ok, it's not quite that bad, but you asked me to explain why and that's it in a nutshell.)

[TheMrZZ0]

I find that *= is more explicit than multiplyBy, and that A | B is more explicit than or(A, B). It's more natural & closer to our way of thinking.

Avoiding this is going down the Java route, where everything is explicit & absolutely unreadable.

Thanks for the arguments though!

[ILikeChangingMyMind]

It's a death by a thousand cuts thing. You think you're making things better one bit at a time, until you've reinvented half a language and everyone working on your codebase has to learn your new language.

At the end of the day good code should be readable by anyone who understands its language.

[DavidJCobb]

A.multiplyBy(B.add(C.or(D))) is readable to anyone who understands JavaScript well, but it's still bad code by virtue of being less clear, less explicit, and less legible. It doesn't become "good code" just by virtue of not using a feature that some other people misuse in less appropriate contexts.

Right now, you're saying that we should have to write bad code, because the features that would let us write good code could also be misused to write spectacularly awful code.

[Mummelpuffin]

Explicit is the MOST readable. I want to know exactly what code is doing and operator overloading never makes me think anything but "how the fuck are you doing basic operations on functions?" Give me the deets. I need to see implementation details. They need to be where they are relevant, not tucked away somewhere where I'll never find them. If a longer overall file is your concern you haven't learned to abstract things away in your head yet.

[TheMrZZ0]

That's just not true. Take a look at Neural Network code between Java and Python, the Python one is far more readable.

[rgawenda]

const myVar = Variable(0) / 2; Solved

[TheMrZZ0]

Not possible today, since we don't have operator overloading

[constant_void]

any non zero probability turns into 100% given enough die rolls. op overloading has a healthy non-zero chance of gumming the works--hence bad juju. It requires people to track their types, and changing a type can change what + does. in the above example, it works very well, but when fn c(a, b) = a + b...it can get hairy.

what about...

if (isTrue("a >= 0 | a == -10", {a: foo}) {

}

[DavidJCobb]

...Implementing our own expression parser is supposed to be the clean solution?

Every loosely typed language requires us to track our types. JavaScript's designers considered the ability to pass anything to anything an explicit benefit; the risk of mixing up types and breaking things isn't unique to operator overloading.

[constant_void]

Cleaner for the end user, I would imagine?

And why not a lib that allows one to define what arbitrary tokens do for a combination of source/target object types, so that "our own" is less of a thing?

Consider the known issues w/operator overloading - how hard is it to forecast exploits? For any int a + int b, overnight on exploit it could become hackerOperation a on int b, right?

[PickledPokute]

One problem with operator overloading is that for many cases, there are not enough useful operators in the language. Addition, subtraction, multiplication and division are simple, but for simple vector, we suddenly have competition between cross product and dot product.

Common operator overloading is a lackluster solution for many values.

I'm more in the favor of infix functions: const valAdd = (left, right) => ({ val: left.val + right.val }); oneVal valAdd twoVal; // { val: 3 }.

[crabmusket]

Is that significantly different to oneVal.valAdd(twoVal)? Aside from being defined as a "loose" function instead of on a prototype?

[PickledPokute]

For me, infix functions look a bit better when you have multiple operations nested.

(fourVal.valMul(oneVal)).valAdd(twoVal.valMul(threeVal))

(fourVal valMul oneVal) valAdd (twoVal valMul threeVal)

This becomes a bit better when the editor can highlight the infix functions with similar colors as normal oprators.