The Artima Developer Community
Sponsored Link

Weblogs Forum
The Positive Legacy of C++ and Java

210 replies on 15 pages. Most recent reply: May 9, 2009 2:50 AM by Daesung Park

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 210 replies on 15 pages [ « | 1 ... 10 11 12 13 14 15 | » ]
Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: The Positive Legacy of C++ and Java Posted: Apr 12, 2009 10:46 AM
Reply to this message Reply
Advertisement
Operator overloading is a topic that never fails to generate very passionate responses, and this monster thread on Artima is no exception.

First of all, I'd like to address a common complaint heard from people who dislike operator overloading, and which usually goes along the lines of:

"In Java, when I see a + b, I know exactly what is going on. If Java supported operator overloading, I would have no idea what + means."

I have very little sympathy for this argument because this example is hardly different from a method call such as o.init(). When you read such code in Java, you don't necessarily assume that it's the method init on o's class that is being invoked. You know that you will have to look at how this object is created in order to determine its effective type before you can find out which method init is being invoked.

Operator overloading is no different, and if you knew that the language that you are reading supports it, you are just going to extend this mental path to operations that involve overridable operators.

Very often, I find that operator overloading is being demonized because its uses in other languages has led to excesses. I have found that many people who dislike operator overloading can trace it back to some personal experiences where they once had to deal with code that was clearly abusing this feature. This is unfortunate, but I still think that Java is doing fine without it and that overall, it only leads to clearer code in very few and uncommon cases.

Here are a couple of objections I have with operator overloading:

* 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).

* In exchange for infix notation, operator overloading severely restricts my freedom to name my methods in a meaningful way.

The most common operators that people want to overload are + and -, and they are also the operators that probably make the most sense outside simple arithmetics. I can see these two operators make sense for types that represent a collection of elements (java.util.Collection obviously, but also strings or streams). However, even in this ideal case in favor of operator overloading, the metaphor quickly breaks down when you realize that you need to supplement these two methods with ones that have slightly different meanings, such as addAll(). Would you rather have an interface that contains add() and addAll() or +() and addAll()?

Of course, there are more operators that can be overloaded, such as * or /, but I find that even strong advocates of operator overloading quickly run short of arguments when trying to justify why one would even want to overload them outside of specific algebras.

I am a big fan of clear names, and I dislike the name + for the simple reason that it doesn't carry enough meaning to explain to me what is going on. This operator is very clearly defined when it is used in a mathmatical sense but it becomes very vague when you start to extend it to concepts that supports the idea of addition in a more vague sense. For example, adding to a List is very different from adding to a Map since the latter can produce an object that's equal to the one you started with, even though the object you added is not zero. And what is zero in the sense of a collection, anyway? Doesn't it make much more sense to use add() for a List and put() for a Map?

Overall, I find that code that makes heavy use of operator overloading is harder to read and harder to maintain because it is severely restricted syntactically (forced to use specific names taken from a very small pool) and semantically (since you are using symbols that have very precise mathematical definitions, it is very unlikely that your usage will match the mental model that people who read your code have of their meaning).

I would love to see some good examples of operator overloading, if you have any to share...

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 12, 2009 12:21 PM
Reply to this message Reply
Nobody said operator overloading is useful except in some very particular cases.

But these particular cases become soooo much clearer with operator overloading than without it, that I simply see no point in not having operator overloading.

Think about collections with overloaded [], + and -, for instance, then you probably get a glimpse of how many nice things can be done with operator overloading.

You often have problems in the business domain which get a much friendlier implementation using operator overloading.

Several months ago I had to implement a small library which worked with collections of ranges of time - for instance the opening times of a shop are perfectly modeled by such an object. The collection had to implement various operations on these collections, such as adding two collections, substracting one from the other, calculating lengths of a collection, and the like. IMO, it's not something so exotic. It could be that your objects are truckloads with various weights of various freights, or collections of accounts in various currencies. Years ago I had to implement a library mixing time ranges, flow speeds and cross section areas of pipes. Without operator overloading, such libraries, which always solve an immediate business problem, and aren't abstract, useless algebras, poresent ugly looking interfaces to the world.

IMO, the key point is overhead generated by reading potentially more complicated code vs. simplicity of writing the code. In theory, since you read a piece of code thousands of times for each time you touch it for changes, whatever complicates the reading should not be used. But that's a stupid argument: whether I have a.add(b) or a + b, I still have to write it in some way, and not allowing the form a + b only makes reading that code more complicated. a.add(b) is harmless, but what about a.add(c.times(d.minus(x).add(y)))? I even have trouble matching parantheses with this.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 13, 2009 8:18 AM
Reply to this message Reply
And a language is not orthogonal when its creators are allowed to overload operator + for strings, but not its users.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 13, 2009 9:02 AM
Reply to this message Reply
> And a language is not orthogonal when its creators are
> allowed to overload operator + for strings, but not its
> users.

Bullseye!

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 13, 2009 3:18 PM
Reply to this message Reply
> You definitely work for a large company, and have probably
> done so for a very long time. Right? 'Cos this is in no
> way how things work in smaller companies, where more often
> than not programmers also take on consultancy work and
> project management (which is what makes life in a small
> company more fun - if you're serious about what you do,
> you get to learn a lot).

I've worked in varied environments which you would already know were you paying attention. In smaller companies, programmers tend to do whatever they want. This doesn't seem like a problem until later when someone else needs to understand what was done. These prima donnas often are unwilling to consider how their choices will affect others and get angry when someone tries to prevent them from making a huge mess of things. They are sure they know best and refuse to learn from others. This is also a personality trait of a lot of consultants/contractors. Unfortunately, since many (most?) people confuse being an asshole with being smart, these people are given free reign to terrorize other developers.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 14, 2009 8:40 AM
Reply to this message Reply
> In smaller companies,
> programmers tend to do whatever they want.

It all depends. IMO, in small companies were mostly average programmers with some good will are left to do what they want they tend to do so as a group/team/quite well functioning social system, not as individuals. Which usually leads to agreed upon and reasonable processes and standards, and what's more important, to a healthy no BS attitude. But I have also seen small companies where management interferes, or where big egoes collide, and where the type of work performed favours a way of working that you describe. Each programmer does what he wants the way he wants. Code reuse is not even an afterthought, there are no defined standards and processes, and quality assurance is missing completely. But I think the issue of operator overloading is orthogonal to the issue of whether a team chooses to work as a team or is split into individuals by internal or external influences. Good programmers working individually are still able to deliver better code with operator overloading than without. Well-knit-together teams can easily train the less well prepared members to understand operator overloading.

> This doesn't
> seem like a problem until later when someone else needs to
> understand what was done. These prima donnas often are
> unwilling to consider how their choices will affect others
> and get angry when someone tries to prevent them from
> making a huge mess of things.

This argument is in some way supporting my statement. Programmers left to their own devices tend to isolate and elliminate prima donnas. Which is something unlikely to happen in larger companies, because ordinary programmers don't get involved into HR decisions. In small companies, it's unlikely that the manager of maybe two or three specialzed teams will risk blowing up one of his teams just in order not to react to the problem of having hired a primmadonna.

> They are sure they know
> best and refuse to learn from others. This is also a
> personality trait of a lot of consultants/contractors.

Consultants/contractors are also a trait of large companies, from what I've seen. Small companies hire consultants for trainings or the like, and even this they do seldomly. Small companies do the actual programming work 100% in house, and allow programmers to research and learn new technologies and applications on their own. In a normal small company, there will always be a few people which will bring technical novelties into the team, and teach others. In a large company, even if there are such people, introducing new technology is always a management decision.

> Unfortunately, since many (most?) people confuse being an
> n asshole with being smart, these people are given free
> reign to terrorize other developers.

Programmers don't make this confusion. In general I think it's not "most". Most people cannot tell the difference between an asshole, a smartass and a really smart guy when it's about something they don't really understand, but they do very well make the difference when it's about something they know about. Especially in larger companies management usually has no clue about the technical aspects of stuff upon whoch they decide (they usually never got to work as workers before becomming managers), but gets to make all or allmost all decisions, which is another reason why larger companies are less capable of making good decisions than smaller ones.

My conclusion: there might be issues with more advanced language features, potentially not easily understandable by all programmers in some environments, but IMO this is no reason to leave such features out of languages, especially when there are plenty of reasonable good uses for those features. From your take on the problem, I understand that what may look as organizational or political reasons are likely just the reflection of non-technology problems elsewhere in the organization, and to try to solve them through technology is unlikely to work.

Toyota's way comes to mind: fix any problem at the source. Based on this principle, I think that trying to fix programmer stupidity by giving them only tools that limit how stupid they can be is stupid. It's like getting only pain killers for a broken bone: it won't fix your bone, but it will make you feel better. The source of programmer stupidity is bad HR policy, bad working processes, bad working environment, or whatever makes smart programmers leave, average programmers be unwilling to learn, or bad staying on a team they're too stupid for (it may sound offensive, but nevertheless it happens). Trying to fix this by giving smart programmers an additional reason to leave or to work less well than they are capable of will only make things worse, IMO.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 14, 2009 9:02 AM
Reply to this message Reply
Florin, I don't disagree with anything you are saying in particular. I will note that running a large team of developers is harder than running a small team and it's not feasible for everything to be developed by small teams. I also believe that in general, IT and software management is extremely bad but that is a different discussion. My main point is that not every team has the same needs. If Java doesn't meet those needs, then don't use it. Honestly, I think Java is past it's prime. It's OK for a default language for the VM but there are better languages (on the JVM and off) for almost any task.

I'm curious whether you believe no feature should be excluded from a language. For example, do you believe goto should be excluded from modern languages?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 14, 2009 1:32 PM
Reply to this message Reply
> I'm curious whether you believe no feature should be
> excluded from a language. For example, do you believe
> goto should be excluded from modern languages?

That may seem like a trap but it's not. I just thought of an example that's more provocative. In Java, we are allowed to overload methods e.g. foo(String) and foo(Object). This provides no significant value because there's no runtime different between calling my methods that and fooString(String) and fooObject(Object). It's less redundant and arguably prettier.

Now, I would argue that this feature is problematic. For one, it's a huge source of confusion for beginners because they expect that if the call foo() with a String object at runtime, it will call the foo(String) version. But it really depends on the type of the variable their String was referenced by. It can also cause code modifications in one class to silently change the meaning of other parts of the code base that is being compiled. In my opinion, the benefits of this feature are far outweighed by the downsides and if I had my way, I would strike it from the language.

Do you think that's reasonable? Remember that even if I am able to restrict the use of this feature in my organization, I can't prevent 3rd parties (e.g. Sun) from using it. And given how much Java code depends on 3rd party libraries, there will be no way to avoid dealing with this.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 14, 2009 2:58 PM
Reply to this message Reply
> I will note that running a large team of
> developers is harder than running a small team and it's
> not feasible for everything to be developed by small
> teams.
Of course my experience is limitted, but it tells me that something that cannot be developed by many small teams that collaborate but don't mix is badly architected. Managing a team of teams is the same as managing one team - has said Sun Tzu cca. 2000 years ago, and I tend to agree with him. I never worked on OS code for jet fighters, for example, but a large SW+HW project of a security system for a prison was partly outsourced to us, and the only problems were management problems, not technical ones.

> I also believe that in general, IT and software
> management is extremely bad but that is a different
> discussion. My main point is that not every team has the
> same needs. If Java doesn't meet those needs, then don't
> use it.
Yes and no. I'd gladly use something smarter, if customers accepted it. On the other hand, since technology is often forced upon me by customers, I need that technology to provide what I need. Sun never declared Java to be a language specifically designed for dumb programmers organized in large, badly managed teams. Would they have done so, I'd stand a chance to talk customers into using something else.

> Honestly, I think Java is past it's prime. It's
> OK for a default language for the VM but there are better
> languages (on the JVM and off) for almost any task.
1) Right, but if Sun doesn't develop Java (the language) further, since most customers regard almost any other language that compiles to bytecode for the JVM as exotic, and don't want to get any other source code than Java, the JVM is doomed if programmers switch to other languages.

2) One of the (few) bad things about working for a small company is that customers force many technical decisions upon you. As long as the customer dictates Java, and pays for the source code, I have no other choice but to give him Java. As long as I'm stuck with Java, I'll do what I can to get the language features I deem useful into the language.

> I'm curious whether you believe no feature should be
> excluded from a language. For example, do you believe
> goto should be excluded from modern languages?
I think I stated it before: any feature should be accepted into a language, unless it makes the language's grammar overly complex, at least in relation to the benefits brought about by that feature. I can see no way in which operator overloading would make a mess out of Java's syntax, but I can see many uses for it. Does goto's syntax, which typically requires labels to also be added to the syntax, add enough value to compensate for the more complicated syntax? I would say no. But I'm not alone in this world. As long as somebody comes up with an argumented justification for goto's usefulness, I don't have anything against it being added to the language - nobody forces me to use it, even if it's there. But I would consider myself a stinker if I would argue against adding it to the language only because I don't want/need/know to use it properly, or in ways other ppl would want to use it.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 14, 2009 3:20 PM
Reply to this message Reply
> Of course my experience is limitted, but it tells me that
> something that cannot be developed by many small teams
> that collaborate but don't mix is badly architected.
> Managing a team of teams is the same as managing one team
> - has said Sun Tzu cca. 2000 years ago, and I tend to
> agree with him.

I'm not familiar with the quote but as you have stated it could be interpreted as meaning that a team of teams is one really big team and that the subteams are irrelevant to your management of them. And given the subject (war) you obviously need all teams to follow a lot of the same conventions (uniforms, signals, etc.)

> I never worked on OS code for jet
> fighters, for example, but a large SW+HW project of a
> security system for a prison was partly outsourced to us,
> and the only problems were management problems, not
> technical ones.
>
> > I also believe that in general, IT and software
> > management is extremely bad but that is a different
> > discussion. My main point is that not every team has
> the
> > same needs. If Java doesn't meet those needs, then
> don't
> > use it.
> Yes and no. I'd gladly use something smarter, if customers
> accepted it. On the other hand, since technology is often
> forced upon me by customers, I need that technology to
> provide what I need. Sun never declared Java to be a
> language specifically designed for dumb programmers
> organized in large, badly managed teams. Would they have
> done so, I'd stand a chance to talk customers into using
> something else.

You keep invoking the "Java is for dumb programmers" fallacy. Why?

> > Honestly, I think Java is past it's prime. It's
> > OK for a default language for the VM but there are
> better
> > languages (on the JVM and off) for almost any task.
> 1) Right, but if Sun doesn't develop Java (the language)
> further, since most customers regard almost any other
> language that compiles to bytecode for the JVM as exotic,
> and don't want to get any other source code than Java, the
> JVM is doomed if programmers switch to other languages.

I think that there will be a shift away from this but I could be wrong. There are real gains to be had by moving away from Java. Right now none of the languages are enticing enough to IT shops but that will change, I expect.

> 2) One of the (few) bad things about working for a small
> company is that customers force many technical decisions
> upon you. As long as the customer dictates Java, and pays
> for the source code, I have no other choice but to give
> him Java. As long as I'm stuck with Java, I'll do what I
> can to get the language features I deem useful into the
> language.

A little off-topic but if the only reason to support Java is for your customers, have you considered pre-processors or IDE extensions?

> I don't
> have anything against it being added to the language -
> nobody forces me to use it, even if it's there. But I
> would consider myself a stinker if I would argue against
> adding it to the language only because I don't
> want/need/know to use it properly, or in ways other ppl
> would want to use it.

Even if you don't have to use a feature, it affects you. If gotos were allowed, you would have to understand how they are being used in any code that you had to deal with that used them. This is a huge problem when you have teams of teams. You might say no gotos on your team but then another team allows them. That's really the issue here. The illusion of control. You think that you can ignore features you don't use but it's not true.

Krisztian Sinka

Posts: 30
Nickname: skrisz
Registered: Mar, 2009

Re: The Positive Legacy of C++ and Java Posted: Apr 15, 2009 3:57 AM
Reply to this message Reply
> I would love to see some good examples of operator
> overloading, if you have any to share...

Strings already mentioned.

But look for a more complicated example: Boost's Spirit library.
It's a parsing library and due to overloading possibilities you can write a parser in legal C++ code. It is true that the syntax is not true EBNF, but are close to it. When you use a different tool (for example Flex / Bison) you also need to learn their own syntax and specialities.

Moreover having the possibility to write it in legal C++ it opens many new possibilities: having a parser that can modify its working in runtime easily, type checking at compilation time, etc.

So I am using this library to write a parser, and after reading about 20 pages and some trials the syntax is natural for me, however it is heavily overloaded.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 15, 2009 7:15 AM
Reply to this message Reply
> I would love to see some good examples of operator
> overloading, if you have any to share...

1) arithmetic operators for custom types of numbers/matrices.
2) associative containers.
3) message passing (overloading of operator ->*, rarely used in c++, but it is there).
4) smart pointers.
5) iterators with pointer syntax.
6) boost::spirit, as someone said above.

There are numerous cases where operator overloading is useful, by providing a more natural syntax and also shortening the code.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 15, 2009 8:48 AM
Reply to this message Reply
> I would love to see some good examples of operator
> overloading, if you have any to share...

While everyone is on this subject... Python has a lot of goo examples of operator overloading. overloading [] for list and map style objects is a really good example. On the other hand the * operator for Strings seems contrived to me but it might be useful to some.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 15, 2009 9:51 AM
Reply to this message Reply
> > I would love to see some good examples of operator
> > overloading, if you have any to share...
>
> 1) arithmetic operators for custom types of
> numbers/matrices.
> 2) associative containers.
> 3) message passing (overloading of operator ->*, rarely
> used in c++, but it is there).
> 4) smart pointers.
> 5) iterators with pointer syntax.
> 6) boost::spirit, as someone said above.

Some of these would really be better with their own unique operator rather than overloading an existing operator. My list of bad choices would include:

1. Java's overloading of '+' for string concatention.
2. <<, >> for IO in C++

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: The Positive Legacy of C++ and Java Posted: Apr 15, 2009 6:18 PM
Reply to this message Reply
When I was asking for examples, I was really hoping to see some code instead of English :-)

It's clear that anything that looks like a scalar can benefit from operator overloading, so no need to mention BigDecimal or matrices. I'm interested in areas that are less mathematical (such as the intriguing messaging example mentioned above).

I concede that overloading [] for maps makes the code a bit easier to read, although put() is not particularly hard to decipher either.

Flat View: This topic has 210 replies on 15 pages [ « | 10  11  12  13  14  15 | » ]
Topic: Should I use a netbook as my main development platform? Previous Topic   Next Topic Topic: Social Newsfeeds: The Next Big Thing


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us