Hacker News Reader

Comment by stack0v3erfl0w | Hacker News Reader

I recently started developing in Java and the thing I find most irritating is the lack of operators overload.

Why? Sure, overloading a "+" operator can be elegant looking. But the aesthetic gain vs. maintainability doesn't seem to be worth the tradeoff 99% of the time. I certainly wouldn't want to be the one who has to debug the thing because someone accidentally side effected one of the "operands".

Without operator overloading you cannot write an EDSL.

Nonsense. To paraphrase myself from a similar discussion on reddit:

"List.add(otherList) <-- what does this do? Why, compared to operators, would a function name be any better than an operator? Mathematics are part of computer science, and denying basic operators for a reason like "because someone might misuse them" is like denying functions because someone may implement a sum() and call it lcm() (and then we're back to goto land). You're confusing a programmer's error (bad choice of a name/operator function) with a language feature. Just because people can write bad code it does not mean we should disallow them to write great code."

Honestly, it's about time the Java crowd stops with the mantra and starts thinking from themselves. Or at least, learn why the reason you hate operator overloading is fallacious.

Absolutely agree with you. I haven't seen yet a real reason to avoid including operator overloading in any language.

There is exactly one such reason: programmers. Python programmers were given operator overloading, and did a good job with it. C++ and Scala programmers were given operator overloading, and did a bad job with it (eg << in C++'s streams, ^ in Scala's specs2).

I have never heard a convincing theory of why some language communities were careful in their use of operators, whilst others went overboard. In the absence of such a theory, it's a risky feature to add.

Well, it's time to disallow functions, since someone can misuse their names. And exceptions, since someone might use it as goto. Might as well get rid of non-primitive types, there might be a very bad person willing to name a class with a completely meaningless name.

It just seems an odd hill to die on. Just a minor little feature that most people would use only occasionally in their objects.

I disagree wholeheartedly: the verbosity caused by a lack of such an 'irrelevant' feature makes my eyes bleed.

It doesn't really matter, some people see classes/objects as a minor feature too. I agree with him: operator overloading is not a minor feature and it's probably one of the reasons I am not very fond of Java.

> Just a minor little feature that most people would use only occasionally in their objects.

Yeah until you have to work with java's Bignums one day, then you start wanting to choke people to death.

Yeah, I guess it sucks if you work with Bignums. I would be happy if BigInteger and BigDecimal were promoted String-level language support: still implemented as classes, but with compiler support. They could add indexing [] for collections, but I can live with .get() and .put().

Some people seem to think that if they don't use, then it doesn't matter. In many business applications, you don't even need floating point (you just transfer data to the database and back), anyway.

Are floats and doubles "little features"?

In computer graphics, you need lots of floating point calculations. Are ints and longs "little features"?

In embedded software, you usually don't want to use resizable strings (C doesn't even have this feature built-in), because reallocations are expensive or unavailable. Are resizable strings (or containers) "little features"?

Different programs have different needs. If you haven't stumbled upon a good use case, doesn't mean that it's useless.

This same logic can be used to defend any "little feature". Language design is all about where you draw those lines.

That logic is just a starting point (just to avoid the "I don't need it, why can't you be just like me?"), not the whole thing.

Then you have to take into account a few other criteria, such as [1] internal coherence in the language, [2] difficulty in implementation (and explaining to others) [3] what your target audience is, and what they want, [4] what competitors are doing.

I think full operator overloading would hurt [2], but special-casing Bignums would not hurt [1], [2] at all (as I said, JSP EL already have +,-,*,/, etc. , String already have +, +=).

[3] This is what this thread is all about, no need to repeat :-D

And [4]... Well in this case Java is really playing catch up.

It just seems an odd hill to die on.

There's an axiom to be found somewhere there. If it's a hill, someone will be willing to die on it.

That is what I keep repeating when people complain about operator overloading.

It is just symbolic names, like doing abstract mathematics with letters instead of numbers.

Except for C, Java and Go, all the remaining mainstream languages allow for symbolic names in the functions/methods.

I never understood what was the big deal.

the nice part about java is the legibility. I can simply start with a new instance of your object and auto complete to the method that I want. Once operator overloading joins the fray everyone is off to the races for crappy dsl of the week. "here's how you do the XXX lib way".

I'd prefer if that option stays off the table. Given that java users are on ides, autocompletion makes an api call a one character effort anyway and saves us from tons of stupid operators.

Java users are stuck with IDEs largely because it's so hard to design a decent DSL when you're confined to Java method syntax. Autocomplete doesn't make it any easier to read bulky verbose code, just gives you more of it.

It seems to me that it's a cultural problem more than anything. People know that they shouldn't take an existing, well-known method name and repurpose it for something completely different. But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example. << means bitshift. Just because it looks like arrows doesn't mean it's sane to repurpose it into a completely different "output this" operator. You wouldn't override "leftShift" to output stuff, so why do people do it with <<?

I think it depends a lot on the languages. Operator overloading is easy and common in Python, but in my (limited) experience, it's used to create new classes which respond to existing operators with existing semantics, e.g. to make new number classes. For this, it's great. There's no particular reason the types built-in to the language should get special treatment for operators, as long as programmers can resist the temptation to be idiots.

"But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example."

Do you have any data to prove such assertions? A C++ STL operator chosen more than a decade ago is not enough statistical data for one to have such a narrow-minded vision and say these bold statements. Maybe you need to check all the nice C++ libraries that make use of operator overloading.

The common example people pull off the hat with C++ is the use of << operator for streams and some UI toolkits.

Which I personally never had a problem with.

You seem to have confused the phrase "classic example" with "the worst thing out there, with data to prove it".

It's an example. Do you dispute that? It's classic. That's subjective, and I claim it by raw assertion. That's it.

There's basic language bigotry going on here: an aged internet meme declares that C++ operator overloading is bad because you can indeed, in theory, do idiotic counter-intuitive things with it. Yet the identical capability in Ruby, Scala and Haskell (inter alia) is deemed A Good Thing by the consensus.

For me, and perhaps others, this is because C++ enshrines idiotic counter-intuitive operator overloading in its standard library.

Examples ?

The use of << and >> for streams is the one that always comes to mind. So minor, and yet so awful.

Well this is clearly a matter of taste; the visual implication of movement (http://images.google.com/images?q=diversion+sign+chevrons) is quite elegant IMHO, and the precedence seems natural also. But others' mileage obviously varies ...

I disagree that the precedence is natural. Without looking it up, and without compiling it, what do the following (IMO quite reasonable in general) lines of code do?

    cout << x & y;
    cout << (x & mask) != 0;
    cout << boolVar ? "Yes" : "No";

As for the visual implication of movement, I have no objection whatsoever to using the << operator for stream operations in general. However, I strenuously object to doing this in a language which already defines them as bitshift operators. Repurposing an operator to do something completely different (and especially in this case, where a functional operator suddenly turns into one that's almost entirely about causing a side effect) is bad. Operator overloading can be useful and result in great, comprehensible code, but only if operators only mean the same thing everywhere.

Point taken, but small beer IMO; I use parens in boolean expressions because I can never remember the precedence of && vs ||, so would naturally use them here too.

And I don't buy the fact that << is somehow off limits because it's used for bitshift; the domain of usage is usually disjoint, although one would have to squint to grok the outputting of a bitshifted value to a stream - but how frequent is that?

Yes the << notation isn't perfect, but it is much nicer than named functions (and certainly superior to < (which Stroustrup initially considered)!). Adding arbitrary operators to the language would have required mechanisms to define associativity and precedence, which would have added a weight of complexity disproportionate to the reward.

I don't really see the big advantage to << over named functions here. Compare:

    cout << string << " and " << otherstring << endl;

    cout.write(string).write(" and ").write(otherstring).write(endl);

It's about as readable to me. To me, operator overloading is good when the meaning is already obvious because of shared context that everybody has. That's not the case when co-opting << for stream operators.

It's not an identical capability. Scala doesn't technically have operator overloading, it has symbolic method names and operator syntax for methods. This means you can use any valid name as an operator.

With C++, you can only overload the built-in symbolic operators. This means instead of choosing the best symbolic name to use as an operator you're forced to re-purpose some built-in operator like "<<". In Scala you can pick any name or symbol you want.

Same with Haskell, which makes it compact but not always very readable (it effectively turns many libraries into their own non-intuitive DSL).

Yes I know that, but the point is that the "operator overloading is terrible" complaint typically cites either plainly daft straw men like "what if someone overrides + to mean subtraction", or else hones in on << for streams, which as others have pointed out here is actually perfectly readable and sensible. I have yet to see a single sensible criticism that holds water (OK, MS overloading address-of & on a smart pointer, that one was stupid ..)

Conversely, there was an XML library for Scala posted on Reddit about a year ago that used things like <:<, <<? and <> as method names; clearly the freedom to concoct your own symbolic names is far more open to abuse than the oft-maligned C++ mechanism.

Two big problems with overloading << for streams are operator precedence (the precedence of << makes little sense for a stream operator) and the fact that the chained syntax can make the whole thing ambiguous (which is kind of a subset of the precedence problem), e.g.: cout << x << 3, does that shift x by 3, or output x and 3 separately?

I think it's an interesting phenomenon in the sociology of programming languages.

A powerful new feature is introduced in a niche language, and novices abuse it. The feature gets a bad reputation. Yet eventually, as new languages adopt it, the community learns how to use it and how not to use it, and people become accustomed to it, and come to agree that it's not such a bad thing.

I'd say that's happened, to some degree, with garbage collection and lambda expressions. We seem to be in the middle of the process with operator overloading, and still in the early stages with Lisp-style macros (I can hope, anyway :-).

You can't overload operators in Haskell. You can define new operators though. You're not going to change the meaning of + unless you remove the old.

>Operator overloading is easy and common in Python, but in my (limited) experience, it's used to create new classes which respond to existing operators with existing semantics, e.g. to make new number classes.

In Python, it's called "special method attributes" and they can do a lot more than just create classes. The __eq__ attribute returns a straight boolean for example in response to the "==" operator. And yes, by the way, you actually can accidentally alter attributes in the calling and callee objects if you aren't careful.

Sorry if I was unclear, but I meant that this facility lets you create classes whose instances work like built-in numbers, not that the facility itself is used to create clases somehow.

In my opinion good uses of operator overloading are ones that preserve the mathematical properties of the operator, so that the operator is in some sense "the same operation", just for different types. By this standard "+" for string concatenation isn't a great choice since string concatenation isn't commutative, but addition is. The same can be said for using "*" for matrix multiplication. If you define these kinds of operator overloads, you have to be very conservative about writing generic code that uses the operator.

Given these limitations, and the fact that most languages have relatively few built-in operators to choose from, I find that just operator overloading isn't enough. You really want the ability to define new operators as well. That's something Java (and C#, and C++, and many other languages) would really benefit from.

You mean like this? (not Java):

  multi infix:<plus>(Int $a, Int $b) {
      return $a + $b;
  }
  multi infix:<plus>(Str $a, Str $b) {
      return $a ~ $b;
  }
  
  say 10 plus 4;
  # 14
  
  say "foo" plus "bar";
  # foobar

what's that? Perl 6?

Yep. Much of the language is implemented in itself (at least in Rakudo), using such structures:

https://github.com/rakudo/rakudo/blob/nom/src/core/Int.pm#L1...

NQP in that link is "Not Quite Perl", a subset of the language which is the what actually needs to be implemented to support Perl 6. This is what's almost done being ported to Java. Again, for Rakudo, which is one implementation.

Quite a few languages allow the use of operators, or special characters if you prefer, as names.

Without any restriction, except for a few basic ones.

This is getting into blessing vs. curse territory, though. On the one hand, used well, a custom operator might enhance the benefits of allowing operator overloading in the first place. If your code is mathematical, you have an extended character set available, and you have good coding standards and keyboarding skills to match, then matching the operators/notation in the code to any related mathematical documentation has obvious advantages.

On the other hand, there are only so many obvious symbols available on most keyboards. Once those run out, you can resort to those extended characters, but they might not always be so unambiguous: most of us would recognise less-than-or-equal, but was that an empty set or just a slashed zero in the font Bill was using? The alternative is to start combining symbols, which again might make sense if say [[ ... ]] looks like whatever mathematical notation is standard in your field, but isn’t so great if you go all Haskell and define more-or-less every combination of three non-alphanumerical symbols in the universe to have some subtly different meaning... including from the same combination of symbols in the other library you’re using five lines later.

Actually I think Haskell does things pretty well on this one. People often complain about the operator-heavy nature of Haskell, but I find that after a while you're familiar with all of the popular operators and they just fade into the background, actually making the code feel much more clean than it would without them. They contribute greatly to the feeling of concise power that Haskell has.

People often complain about the operator-heavy nature of Haskell, but I find that after a while you're familiar with all of the popular operators and they just fade into the background

With the everyday operators that everyone programming Haskell will learn very early, I agree it’s not a significant problem. Familiarity will surely overcome any lack of intuitive meaning very quickly. The same applies if you’re using “made up” operators but they reflect some intuitive syntax or conventional notation in whatever field you’re working in. In all of these cases, having a concise notation for frequently occurring concepts is surely a benefit, other things being equal.

However, as you start to represent more specialised or esoteric concepts, I wonder whether there are diminishing returns and increasing risks. For example, I think it is good general advice that identifiers in code should be pronounceable, but how do you pronounce $$!? For that matter, did I just write a $$! operator and a question mark, or a $$ operator and an informal confusion/sarcasm mark?

Here’s a Stack Overflow discussion I thought was relevant:

http://stackoverflow.com/questions/7746894/are-there-pronoun...

Reply on news.ycombinator.com