www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why Java Doesn't Need Operator Overloading (and Very Few Languages Do, Really)

reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Sounds like someone needs a strong dose of D!!

http://java.dzone.com/articles/why-java-doesnt-need-operator

The comments bounce between "operator overloading is always bad because you can
do idiotic things with it" and "operator overloading is essential because
sometimes you really need it".

How about a language where operator overloading is available for the cases
where you do really need it, but isn't available in general?

Hmmm...

Paul
Apr 14 2009
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Paul D. Anderson wrote:
 Sounds like someone needs a strong dose of D!!
 
 http://java.dzone.com/articles/why-java-doesnt-need-operator
 
 The comments bounce between "operator overloading is always bad because you
can do idiotic things with it" and "operator overloading is essential because
sometimes you really need it".
 
 How about a language where operator overloading is available for the cases
where you do really need it, but isn't available in general?
 
 Hmmm...
 
 Paul

How about a language where expression overloading is available, etc?
Apr 14 2009
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Paul D. Anderson wrote:
 Sounds like someone needs a strong dose of D!!
 
 http://java.dzone.com/articles/why-java-doesnt-need-operator
 
 The comments bounce between "operator overloading is always bad because you
can do idiotic things with it" and "operator overloading is essential because
sometimes you really need it".
 
 How about a language where operator overloading is available for the cases
where you do really need it, but isn't available in general?
 
 Hmmm...
 
 Paul

OT: that article mentioned one of my biggest pet peeves: ""Doesn't it make much more sense to use add() for a List and put() for a Map?"" In that case it doesn't matter too much since the interface for the two functions is different. However, adding a single element to a collection should have an add() (or +=, or whatever), so that the type of the collection can be changed/abstracted away (e.x. made a template argument). This is particularly annoying with "enqueue"/"push" and "dequeue"/"pop", since there are often times you'd want to change between stacks and queues without changing the algorithm used.
Apr 14 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
My problem with operator overloading stemmed from C++'s endorsement of 
using >> and << for stream operations.
Apr 14 2009
next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:
 My problem with operator overloading stemmed from C++'s endorsement of
 using >> and << for stream operations.

I don't see how "stream << value" is any worse than "shift_left(stream, value)". Most operators are just functions with special syntax. No more, no less. The issues with operator overloading are exactly the same as the issues with function overloading. -- Rainer Deyke - rainerd eldwood.com
Apr 14 2009
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 15 Apr 2009 02:29:33 +0200, Rainer Deyke <rainerd eldwood.com> wrote:

 Walter Bright wrote:
 My problem with operator overloading stemmed from C++'s endorsement of
 using >> and << for stream operations.

I don't see how "stream << value" is any worse than "shift_left(stream, value)". Most operators are just functions with special syntax. No more, no less. The issues with operator overloading are exactly the same as the issues with function overloading.

The problem with operator overloading as compared to function overloading is that they are generally shorter, and thus some programmers want to use them not because they make logical sense but because they lead to less typing. Also, some operators (<<, for instance) may seem to make sense in situations where many would think they do not. shift_left(stream, value) would simply not be used to output 'value' to 'stream', while stream << value is provably being used like that, even though the meaning I can glean from the two is equal. I fear C++'s '<<' was a prime example of 'look what I can do'. I read a nice text about operator overloading some time ago, that likened it to function naming. Basically, the argument that operator overloading can be abused and thus no programmer should be trusted to use it is no different from saying function naming can be abused and thus no programmer should be allowed to choose the names of functions. -- Simen
Apr 14 2009
prev sibling next sibling parent hasen <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 My problem with operator overloading stemmed from C++'s endorsement of 
 using >> and << for stream operations.

You know, I never knew << meant bit shifting until my assembly course at university!!
Apr 14 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 My problem with operator overloading stemmed from C++'s endorsement of 
 using >> and << for stream operations.

I saw someone who wrote a database library, and used << and >> for stream operations. Then he needed a second form of stream operations, so he overloaded > and <. db < x < y; // stores x and y in the database (db < x) < 7; // stores x and 7 in the database db < (x < 7); // stores a bool in the database. if (db > x) { zzz; } // gets x from the database, then does zzz. What fun!
Apr 15 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Walter Bright wrote:
 My problem with operator overloading stemmed from C++'s endorsement of 
 using >> and << for stream operations.

I saw someone who wrote a database library, and used << and >> for stream operations. Then he needed a second form of stream operations, so he overloaded > and <. db < x < y; // stores x and y in the database (db < x) < 7; // stores x and 7 in the database db < (x < 7); // stores a bool in the database. if (db > x) { zzz; } // gets x from the database, then does zzz. What fun!

Adding in < and > for templates just makes it all worth while!
Apr 15 2009
prev sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Don wrote:
 Walter Bright wrote:
 My problem with operator overloading stemmed from C++'s endorsement of
 using >> and << for stream operations.

I saw someone who wrote a database library, and used << and >> for stream operations. Then he needed a second form of stream operations, so he overloaded > and <. db < x < y; // stores x and y in the database (db < x) < 7; // stores x and 7 in the database db < (x < 7); // stores a bool in the database. if (db > x) { zzz; } // gets x from the database, then does zzz. What fun!

db<x> y; // copy x to y :D -- Daniel
Apr 16 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Paul D. Anderson:

Having some operator overload is good if you write some numerical/scientific
code. Try working with bignumbers or vectors in Java, and you will see how
quickly some otherwise simple expressions become an unreadable mess.

Bye,
bearophile
Apr 14 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Paul D. Anderson wrote:
 Sounds like someone needs a strong dose of D!!
 
 http://java.dzone.com/articles/why-java-doesnt-need-operator
 
 The comments bounce between "operator overloading is always bad because you
can do idiotic things with it" and "operator overloading is essential because
sometimes you really need it".
 
 How about a language where operator overloading is available for the cases
where you do really need it, but isn't available in general?
 
 Hmmm...
 
 Paul

The number of operators that you can overload is very small and each of them is attached to very specific semantics that makes little sense outside the realm of scalars and of a few other specialized mathematical concepts (e.g. matrices). Bingo! That's what operator overloading is for. **Don't overload arithmetic operators unless you are doing arithmetic.** I think the main problem with operator overloading in C++ is that that point wasn't explained well at all. The D spec could probably do a better job of it, but at least the ~ operator removes the temptation for people to use + to mean concatenation.
Apr 15 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:
**Don't overload arithmetic operators unless you are doing arithmetic.**<

Are there few non-arithmetic operators (that will support operator overloading too) with a clear semantics that can be added to D? The main problems here are that such operators are very few, they may end being used only in special situations, so may be unworth being added to the language, and of course ASCII has very few symbols fit for such purpose. For example I have implemented in D the Python sets with (almost) the same semantics (it's not equal because the operator overlading of D is a bit less powerful than the Python one. No one has so far given me an answer about this silly limit). Some of their operators/methods are: s.issubset(t) s <= t test whether every element in s is in t s.issuperset(t) s >= t test whether every element in t is in s s.union(t) s | t new set with elements from both s and t s.intersection(t) s & t new set with elements common to s and t s.difference(t) s - t new set with elements in s but not in t s.symmetric_difference(t) s ^ t new set with elements in either s or t but not both So you end using <= => | & ^ - for set operations too, but in real math you want to use a different set of symbols here. And such standard set of symbols is more readable (and unambiguous) compared to that ASCII mapping. APL (and the following languages like J/K/etc) is unreadable also because the symbols it uses are not standard outside the language. Bye, bearophile
Apr 15 2009
next sibling parent Don <nospam nospam.com> writes:
bearophile wrote:
 Don:
 **Don't overload arithmetic operators unless you are doing arithmetic.**<

Are there few non-arithmetic operators (that will support operator overloading too) with a clear semantics that can be added to D? The main problems here are that such operators are very few, they may end being used only in special situations, so may be unworth being added to the language, and of course ASCII has very few symbols fit for such purpose.

Not many. I did look through all the unicode symbols, and even there, there's not many you'd want. Generally, unary operations aren't necessary (a function call looks quite OK). __dot, __cross would be the most useful. They are arithmetic, of course. Set operations. __union, __intersection, __subset, __superset, __subseteq, __superseteq. After that things get really obscure and pretty hard to justify. But __dot would be extremely valuable, I think. Especially since we have array operations in the language, and a[]*b[] is defined as element-wise multiplication. An IDE/text editor could translate __dot into the relevant Unicode character.
 
 For example I have implemented in D the Python sets with (almost) the same
semantics (it's not equal because the operator overlading of D is a bit less
powerful than the Python one. No one has so far given me an answer about this
silly limit). Some of their operators/methods are:
 
 s.issubset(t) s <= t test whether every element in s is in t 
 s.issuperset(t) s >= t test whether every element in t is in s 
 s.union(t) s | t new set with elements from both s and t 
 s.intersection(t) s & t new set with elements common to s and t 
 s.difference(t) s - t new set with elements in s but not in t 
 s.symmetric_difference(t) s ^ t new set with elements in either s or t but not
both 
 
 So you end using <= => | & ^ - for set operations too, but in real math you
want to use a different set of symbols here. And such standard set of symbols
is more readable (and unambiguous) compared to that ASCII mapping. APL (and the
following languages like J/K/etc) is unreadable also because the symbols it
uses are not standard outside the language.
 
 Bye,
 bearophile

Apr 15 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
bearophile wrote:
 Are there few non-arithmetic operators (that will support operator overloading
too) with a clear semantics that can be added to D?

a ♥ b
Apr 15 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 15/04/2009 18:25, Jarrett Billingsley wrote:
 On Wed, Apr 15, 2009 at 10:31 AM, Robert Fraser
 <fraserofthenight gmail.com>  wrote:
 bearophile wrote:
 Are there few non-arithmetic operators (that will support operator
 overloading too) with a clear semantics that can be added to D?


opLove.

sounds silly to me. Why not simply generalize and allow defining in-fix functions like in functional languages? that also includes allowing any unicode character[s]. for example, why not allow: if (M ⊨ a ∨ b) { ... } or: (a concat b concat c) [same as (a ~ b ~ c)] or: if (A dated B || B dated A) { .. } the current system is too limiting, maybe that's why it's more susceptible to being abused? if C++ had this, I'm sure that the awful << for streams wouldn't have been used.
Apr 15 2009
parent reply BCS <none anon.com> writes:
Hello Yigal,


 sounds silly to me. Why not simply generalize and allow defining
 in-fix functions like in functional languages? that also includes allowing
 any unicode character[s].

lexing and (more importantly) parsing become a major problem if you allow that
Apr 15 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 15/04/2009 18:50, BCS wrote:
 Hello Yigal,


 sounds silly to me. Why not simply generalize and allow defining
 in-fix functions like in functional languages? that also includes
 allowing
 any unicode character[s].

lexing and (more importantly) parsing become a major problem if you allow that

not impossible to implement. I don't think Scala is that much more troublesome to lex/parse.
Apr 15 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Yigal Chripun wrote:
 On 15/04/2009 18:50, BCS wrote:
 Hello Yigal,


 sounds silly to me. Why not simply generalize and allow defining
 in-fix functions like in functional languages? that also includes
 allowing
 any unicode character[s].

lexing and (more importantly) parsing become a major problem if you allow that

not impossible to implement. I don't think Scala is that much more troublesome to lex/parse.

That's not a very good argument. Lots of things are possible; doesn't mean they're a good idea. Operator precedence determines how expressions are parsed. Having user-defined operators would require the code to be parsed once to get the operator definitions, then re-parsed with a different meaning. Euch. That said, I'm OK with adding operators with well-defined meanings to the language on an as-needed basis. opDot, opUnion, opCross, etc. -- Daniel
Apr 16 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
On 16/04/2009 15:47, Daniel Keep wrote:
 Yigal Chripun wrote:
 On 15/04/2009 18:50, BCS wrote:
 Hello Yigal,


 sounds silly to me. Why not simply generalize and allow
 defining in-fix functions like in functional languages? that
 also includes allowing any unicode character[s].

you allow that

it's not impossible to implement. I don't think Scala is that much more troublesome to lex/parse.

That's not a very good argument. Lots of things are possible; doesn't mean they're a good idea. Operator precedence determines how expressions are parsed. Having user-defined operators would require the code to be parsed once to get the operator definitions, then re-parsed with a different meaning. Euch. That said, I'm OK with adding operators with well-defined meanings to the language on an as-needed basis. opDot, opUnion, opCross, etc. -- Daniel

say we have the expression (2 + 3 foo 4) (foo is infix function). Scala parses this as: 2 + 3.foo(4) so there is no parsing problems with this. see http://www.scala-lang.org/node/118 Eiffel is similar (also an OOP approach): 2 + 4 is the same as 2.plus(4) the definition of plus is (alias is used to specify the operator):
 plus alias "+" (other: INTEGER): INTEGER
         -- ... Normal function declaration...
     end

from wikipedia for Eiffel:
 The range of operators that can be used as "alias" is quite broad;
 they include predefined operators such as "+" but also "free
 operators" made of non-alphanumeric symbols. This makes it possible
 to design special infix and prefix notations, for example in
 mathematics and physics applications.

 Every class may in addition have one function aliased to "[]", the
 "bracket" operator, allowing the notation a [i, ...] as a synonym for
 a.f (i, ...) where f is the chosen function. This is particularly
 useful for container structures such as arrays, hash tables, lists
 etc.

in Haskell you can define both precedence and associativity for operators. I don't know Haskell but found this link which explains the syntax: http://www.haskell.org/tutorial/functions.html I guess we need someone who knows Haskell to explain how they implemented this.
Apr 17 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Apr 15, 2009 at 10:31 AM, Robert Fraser
<fraserofthenight gmail.com> wrote:
 bearophile wrote:
 Are there few non-arithmetic operators (that will support operator
 overloading too) with a clear semantics that can be added to D?

a =A2=BE b

opLove.
Apr 15 2009
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Don wrote:
 Paul D. Anderson wrote:
 Sounds like someone needs a strong dose of D!!

 http://java.dzone.com/articles/why-java-doesnt-need-operator

 The comments bounce between "operator overloading is always bad 
 because you can do idiotic things with it" and "operator overloading 
 is essential because sometimes you really need it".

 How about a language where operator overloading is available for the 
 cases where you do really need it, but isn't available in general?

 Hmmm...

 Paul

The number of operators that you can overload is very small and each of them is attached to very specific semantics that makes little sense outside the realm of scalars and of a few other specialized mathematical concepts (e.g. matrices). Bingo! That's what operator overloading is for. **Don't overload arithmetic operators unless you are doing arithmetic.** I think the main problem with operator overloading in C++ is that that point wasn't explained well at all. The D spec could probably do a better job of it, but at least the ~ operator removes the temptation for people to use + to mean concatenation.

This reminds me of something I did at work. C# 2.0 has no builtin syntax for associative arrays, and we needed to create a lot of dictionaries of string -> object. We came up a little class with operator overloads: operator[string,object] added a dictionary entry and returned the dictionary builder. But when you're done with that, you still need to convert to a dictionary. So we added an operator overload for this. Now we format strings like: _formatter.Format("${hello} ${world}", -Using.Values["hello", helloObject]["world", worldObject]);
Apr 15 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 The number of operators that you can overload is very small and each of 
 them is attached to very specific semantics that makes little sense 
 outside the realm of scalars and of a few other specialized mathematical 
 concepts (e.g. matrices).

Exactly right.
 Bingo! That's what operator overloading is for. **Don't overload 
 arithmetic operators unless you are doing arithmetic.** I think the main 
 problem with operator overloading in C++ is that that point wasn't 
 explained well at all.

Even worse, by standardizing the << and >> for streams, C++ implicitly endorsed non-arithmetic usages.
 The D spec could probably do a better job of it, 
 but at least the ~ operator removes the temptation for people to use + 
 to mean concatenation.

Yeah, does + mean vector addition or concatenation? There's no solution to that problem if you don't have ~.
Apr 15 2009
parent reply The Anh Tran <trtheanh gmail.com> writes:
<Begging/crying inside>

Dear Mr Bright,

"iostream <<" is BAD; but for something else, it is not very terrible.

So, please give us the operator Freedom as in C++ !!!!!

The compiler could throw scary error:
"operator abuser spotted!!! Need "-opAbuser" to compile this file"

</end>

;-D
Apr 15 2009
parent reply The Anh Tran <trtheanh gmail.com> writes:
The Anh Tran wrote:
 <Begging/crying inside>
 
 Dear Mr Bright,
 
 "iostream <<" is BAD; but for something else, it is not very terrible.
 
 So, please give us the operator Freedom as in C++ !!!!!
 
 The compiler could throw scary error:
 "operator abuser spotted!!! Need "-opAbuser" to compile this file"
 
 </end>
 
 ;-D

Clarification: I mean something else is expression template. Current solution is mixin("blahblahblah"), like Andrei's newest piece of art std.algorithm. I think we could write nicer code than mixin if we have more operator. Best regards.
Apr 15 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
The Anh Tran wrote:
 Clarification:
 
 I mean something else is expression template.
 Current solution is mixin("blahblahblah"), like Andrei's newest piece of 
 art std.algorithm.
 
 I think we could write nicer code than mixin if we have more operator.

You can still do expression templates in D.
Apr 16 2009
prev sibling parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Paul D. Anderson wrote:
 Sounds like someone needs a strong dose of D!!
 
 http://java.dzone.com/articles/why-java-doesnt-need-operator
 
 The comments bounce between "operator overloading is always bad because you
can do idiotic things with it" and "operator overloading is essential because
sometimes you really need it".
 
 How about a language where operator overloading is available for the cases
where you do really need it, but isn't available in general?
 
 Hmmm...

Java's lack of operator overloading is the most idiotic language decision which I have ever encountered. The arguments against operator overloading are equivalent to "if we allow feature X, programmers might not use it the way we have decided it should be used, therefore we won't allow it". "Idiotic" is not even a strong enough word to describe the retrograde thinking of the Java fanatics, and Sun, who have decided to tell programmers what is good for them, whether they want to swallow that pill or not. Java is the only major language I use which does not have operator overloading. C++, Python, Ruby, C#, and D all have operator overloading. Among other things this means that while 1 + 2 in Java is valid, if I write a BigInteger Java class I must write: BigInteger a = 1; BigInteger b = 2; BigInteger c = a.Add(b); or some such other nonsense rather than the completely natural BigInteger c = a + b;. To say that the lack of operator overloading in Java somehow makes the language "better" or "clearer to use" is so ludicrous it needs no further comment. Eventually Java will add operator overloading, since Sun's fanaticism is clearly earning them a quick exit into buyout land ( if not IBM today it will be someone else tomorrow ). Then everyone from the Java fanatic camp will smile and say "wasn't that a brilliant decision Sun made", as if it hadn't been made by everyone else ages ago. Sorry for the non-D related diatribe but someone else started this thread and I can't help remarking how stupid a language must be in this day and time which does not support operator overloading for ease of syntax use.
Apr 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Edward Diener wrote:
 Paul D. Anderson wrote:
 Sounds like someone needs a strong dose of D!!

 http://java.dzone.com/articles/why-java-doesnt-need-operator

 The comments bounce between "operator overloading is always bad 
 because you can do idiotic things with it" and "operator overloading 
 is essential because sometimes you really need it".

 How about a language where operator overloading is available for the 
 cases where you do really need it, but isn't available in general?

 Hmmm...

Java's lack of operator overloading is the most idiotic language decision which I have ever encountered. The arguments against operator overloading are equivalent to "if we allow feature X, programmers might not use it the way we have decided it should be used, therefore we won't allow it". "Idiotic" is not even a strong enough word to describe the retrograde thinking of the Java fanatics, and Sun, who have decided to tell programmers what is good for them, whether they want to swallow that pill or not. Java is the only major language I use which does not have operator overloading. C++, Python, Ruby, C#, and D all have operator overloading. Among other things this means that while 1 + 2 in Java is valid, if I write a BigInteger Java class I must write: BigInteger a = 1; BigInteger b = 2; BigInteger c = a.Add(b); or some such other nonsense rather than the completely natural BigInteger c = a + b;. To say that the lack of operator overloading in Java somehow makes the language "better" or "clearer to use" is so ludicrous it needs no further comment. Eventually Java will add operator overloading, since Sun's fanaticism is clearly earning them a quick exit into buyout land ( if not IBM today it will be someone else tomorrow ). Then everyone from the Java fanatic camp will smile and say "wasn't that a brilliant decision Sun made", as if it hadn't been made by everyone else ages ago. Sorry for the non-D related diatribe but someone else started this thread and I can't help remarking how stupid a language must be in this day and time which does not support operator overloading for ease of syntax use.

This has happened before. Somehow Java has this penchant for attracting odd groupies. Pretty much every feature that Java didn't have was vilified by zealots until adoption, when all of a sudden it became a brilliant decision. Andrei
Apr 18 2009
parent reply grauzone <none example.net> writes:
 This has happened before. Somehow Java has this penchant for attracting 
 odd groupies. Pretty much every feature that Java didn't have was 
 vilified by zealots until adoption, when all of a sudden it became a 
 brilliant decision.

D has this too.
Apr 18 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 This has happened before. Somehow Java has this penchant for 
 attracting odd groupies. Pretty much every feature that Java didn't 
 have was vilified by zealots until adoption, when all of a sudden it 
 became a brilliant decision.

D has this too.

Probably a lot of language enthusiasts do this at some point or another. For some reason this NIH syndrome is more prevalent in Java communities. Andrei
Apr 18 2009