Weblogs Forum - The Positive Legacy of C++ and Java

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
The Positive Legacy of C++ and Java

210 replies on 15 pages. Most recent reply: May 8, 2009 11:50 PM by Daesung Park

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 210 replies on 15 pages [ « | 1 ... 9 10 11 12 13 14 15 | » ]

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 7, 2009 5:44 AM

> I'm afraid it wouldn't cut it for my application. I've
> just looked up the documentation for Java's
> Interface and I can say quite categorically that it
> does not address the functionality required by my image
> class iterators. It's just far too simplistic. Random
> access? Reverse iteration? Indexing?

ListIterator permits reverse iteration, and List has random access. I could only guess at your precise needs.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 7, 2009 5:56 AM

> Threat!!?
>
> I don't want to get into any sort of flame war over Java v
> C++, but that argument does seem to imply a language that
> was designed to accommodate the lowest common denominator
> of competence.

It isn't really about Java vs C++, although it appears that many of those who can't stand operator overloading at all have moved to Java. In almost all cases the reason they give for disliking overloading is C++.

As for competence, regardless of language it is desireable to use advanced features very sparingly because those who follow you may be rather less competent.

I find it rather frustrating that every time a modest overloading proposal is suggested for Java, legions immediately wave the demon of C++. It has gone way beyond rational discussion and become religious: "Thou shall not overload operators".

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 7, 2009 6:49 AM

> I don't want to get into any sort of flame war over Java v
> C++, but that argument does seem to imply a language that
> was designed to accommodate the lowest common denominator
> of competence.

I made this point early on in this thread but that's really got nothing to do with the reasoning. It's basically the same reason that traffic laws exist. It's not that the people making these rules think you need to be told how to drive, its that no single driver can manage the complexity of all the different drivers on the road. If there was only one car driving around at any given moment (and no pedestrians), we wouldn't need traffic rules. I could just drive around any damn way I please. I'd probably get where I need to go quicker too. But when you have a bunch of people doing that bad things are guaranteed to happen.

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: The Positive Legacy of C++ and Java

Posted: Apr 7, 2009 9:39 AM

Operator overloading when used judiciously can be a great simplifier of interfaces. For my image iterators, they are moved forward one pixel with the increment operator and backward one pixel with the decrement operator. Adding 'x' moves the iterator 'x' pixels forward, subtracting does the opposite. Not too hard to understand really! It also has the advantage of decoupling them from the algorithms, as the only requirement is for the iterator to support the ++ and -- operators, They don't care what interfaces the iterators were derived from and I don't see why they should. I don't understand the attitude that, because some junior coders may abuse it, no one can have it. Trapping bad code is what code reviews are for. Are junior coders left to their own devices in most companies?

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 7, 2009 10:24 AM

> As for competence, regardless of language it is desireable
> to use advanced features very sparingly because those who
> follow you may be rather less competent.

IMO the best reason for not using operator overloading often is that it most often isn't useful. But this doesn't mean you have to leave it out - you cripple the language for the situations where operator overloading _is_ useful.

IMO, your arguing is more or less in favor of those who don't want to include them at all: why add them, if we add danger? My thinking is different: programmers should know their stuff, it shouldn't be that stuff is tailored to programmer ignorance. Survival of the fittest will see that programmers not being able to cope with overloaded operators even in places where they are useful will be elliminated from those parts of the programming market.

IMO, as with many things, the first time a programmer who likes what he's doing gets his hands on operator overloading, he exaggerates and uses it wherever he can, even where it's not useful. It's the same with patterns, generic programming, classes, whatever. After a while, he gets to know the new stuff, and falls back into his lazy habits of doing things in a minimalist way. Then he starts using operator overloading appropriately. Yet another argument against the opinion that operator overloading is more dangerous than any other language feature.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 7, 2009 10:33 AM

> It'snot that the people making these rules think you need
> to be told how to drive, its that no single driver can
> manage the complexity of all the different drivers on the
> road. If there was only one car driving around at any
> given n moment (and no pedestrians), we wouldn't need
> traffic rules. I could just drive around any damn way I
> please. I'd probably get where I need to go quicker too.
> But when you have a bunch of people doing that bad things
> are guaranteed to happen.

Right, but I don't think your comparison is valid. Everybody who wants to do so can get a driver's license and something to drive. Whereas getting a job as a programmer is selling something in a competitive market. Why would you make the rules of a competitive market in such a way that really good merchandise has no competitive advantage? I mean, it's obvious that programmers being able not only to cope with operator overloading but also to use it in a smart way are probably able to provide better code with less effort for the people hiring them. But this competitive advantage is elliminated by the language designers. Not only do they harm me as a programmer eager to use operator overloading sometimes, and able to do so, but they also harm my customes, since they make it impossible for me to provide the best possible code. This will slowly but surely drive customers away, to other JVM-based languages, which are less stupidly managed. Therefore I think operator overloading isn't far away.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 7, 2009 12:04 PM

> Right, but I don't think your comparison is valid.

It's an analogy more than a comparison. It's an attempt to illustrate an idea. I'm not saying that traffic and development are the same in every way.

> Everybody who wants to do so can get a driver's license
> and something to drive. Whereas getting a job as a
> programmer is selling something in a competitive market.

A development team is not a competitive market. Or, I don't think it should be anyway.

> Why would you make the rules of a competitive market in
> such a way that really good merchandise has no competitive
> advantage? I mean, it's obvious that programmers being
> able not only to cope with operator overloading but also
> to use it in a smart way are probably able to provide
> better code with less effort for the people hiring them.

Let me clarify that I am conflicted over operator overloading. I don't completely understand why it's seen as such a problem. On the other hand, I rarely miss it. Maybe I'm just used to not having it.

What I am trying to address is this idea that because a given feature is restricted, it's because the language is geared to the lowest common denominator. So again, the main idea behind these restrictions is to make team development go more smoothly. I don't buy the argument that it's about dumbing things down because there are features in Java that are pretty hard for most people to get their heads around. It seems to me that a lot of people who think Java is a 'common denominator' language don't seem to have a clue that these features exist. Some old C and C++ guys struggle when they review my Java code. They can't understand what it does or why it compiles. I think it is fair to suggest that the direction of Java is too conservative and that bad decisions have been made. But the whole lowest common denominator thing is just pure bunk.

> But this competitive advantage is elliminated by the
> language designers. Not only do they harm me as a
> programmer eager to use operator overloading sometimes,
> and able to do so, but they also harm my customes, since
> they make it impossible for me to provide the best
> possible code.

This is circular logic. You are assuming that this feature improves effectiveness which is the subject of the debate. Many people think that allowing operator overloading reduces their ability to provide the best possible code in a team setting. A lot of people would say that the fact that people are "eager" to use operator overloading is the reason it should not be allowed. These people see Java's lack of operator overloading as an advantage. You can disagree (I'm not sure I agree either) but there's no proof in your argument.

Your argument is about you as an individual and your desire to have this feature. Note that I am talking about how the feature affects a development team.

Try this experiment. Think of a language feature that you don't like (there's got to be at least one) from any language you know of. Let's say goto. Maybe you are a big goto guy, but you haven't expressed disgust that java doesn't allow gotos so I'll guess you don't like them, for now.

Now imagine you have a coworker who loves gotos. He's a goto master and thinks that any language that eliminates gotos is dumbed-down for the lowest common denominator. Any competent developer knows how to use gotos properly, right? He thinks that not having gotos will mean he can't deliver his best quality work. How would you feel about that. Would you be OK with him using gotos all over the place when no one else on the team does that? Imagine you will often be responsible for maintaining his code and you will have to do code reviews forcing you to follow the goto based logic in explicit detail.

> This will slowly but surely drive customers
> away, to other JVM-based languages, which are less
> stupidly managed. Therefore I think operator overloading
> isn't far away.

Java became successful without operator overloading, why are things different now?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 7, 2009 1:42 PM

> Operator overloading when used judiciously can be a great
> simplifier of interfaces. For my image iterators, they are
> moved forward one pixel with the increment operator and
> backward one pixel with the decrement operator. Adding 'x'
> moves the iterator 'x' pixels forward, subtracting does
> the opposite. Not too hard to understand really! It also
> has the advantage of decoupling them from the algorithms,
> as the only requirement is for the iterator to support the
> ++ and -- operators, They don't care what interfaces the
> iterators were derived from and I don't see why they
> should. I don't understand the attitude that, because some
> junior coders may abuse it, no one can have it. Trapping
> bad code is what code reviews are for. Are junior coders
> left to their own devices in most companies?

As I said in another response, I don't really have strong opinion either way on operator overloading. It seems quite useful to me in certain scenarios but it's not a huge deal and I kind of get why people think it's bad. I think perhaps IDEs may make these concerns outdated.

But I'm addressing more the false logic or "if you restrict a feature, you are dumbing down to the lowest common denominator". The reason features are restricted has to do more with team development issues and not so much about trying to protect people from themselves. Many companies have policies and guidelines about what features can and cannot be used in languages like C++. They don't exist because they want to dumb down C++. These rules exist to make the code more consistent and allow developers to make certain assumptions about the code.

The reasoning behind not adding features in Java is similar. The advantage is that with Java, companies don't have to develop as many of these rules themselves or enforce them. And when developers move from place to place, the rules stay pretty much the same. Java code is easy to maintain.

Again, I don't necessarily agree that operator overloading is a sports car on the highway to hell. But, the 'lowest common denominator' argument is just rhetoric.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 7, 2009 10:41 PM

...which is strange, considering that operator overloading in c++ is not evil at all.

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: The Positive Legacy of C++ and Java

Posted: Apr 9, 2009 1:12 AM

After reading this long thread and drawing on personal experience I would say the legacy of C++ and Java includes two things for future language designers.

From C++
Giving your language backward compatibility with an ancestor language may boost the initial uptake, but in the long run can be a curse as it becomes a restriction on the development of a logical syntax. For example, in C++ there are a number of situations where the same syntax means different things according to the context; a 'feature' that can cause newcomers to C++ much confusion. I for one would welcome a descendant/alternate syntax of C++ that keeps its power and flexibility whilst abandoning oddities imposed on it because of compatibility with C.

From Java
Don't act like an over protective parent and refuse the users of your language facilities just because 'some dumb coders can misuse it, therefore no-one can have it'. I find that attitude a little insulting. It forces you to use constructs that may not be ideally suited to the problem domain. I rarely use operator overloading and multiple inheritance in C++, but when I do, it's because it is the most logical and succinct solution from the many alternatives.
I read a lot of forums and blogs on various programming languages and I have noticed on Java sites the phrase 'workaround' seems to pop up a little too often for my liking. When you find yourself often having to do a 'workaround' to force the language to match the design of your solution, it would indicate that it has certain limitations.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 9, 2009 9:50 AM

> > Right, but I don't think your comparison is valid.
>
> It's an analogy more than a comparison. It's an attempt
> to ...

I think good teams can only be teams made of people with comparable skills and knowledge, besides a common professional culture earned over a long time - whether they do programming or something else. If one person in a team is OK with operator overloading and uses it where appropriate, the others should at least be able to understand the concept, as long as they aren't a lot less skilled programmers.

Team members should of course not compete against each other. However, the team has no choice but to compete against other teams. If other teams, made of similarly skilled programmers as those in my team, use tools which allow them to deliver better code, maybe in just 10% of all cases, just due to operator overloading, they have a competitive advantage over my team.

Of course, it may be that operator overloading doesn't help at all in most of the code, but I don't like the idea of Sun or the JCP making the decision that it never helps for me or my team, especially since Sun has no way of knowing what code my team and I are working on, or will be working on in the future. If they do, they give me reason to give up Java in favor of some other language, also compiled for the JVM, but which doesn't make decisions for me wihtout knowing what I am working on or what I will be working on.

What I don't like about languages is cryptic syntax - C++ excels at this.

In general, I like languages to provide me with any language feature somebody could come up with, provided it doesn't excessively complicate the syntax, or it doesn't use a cryptic syntax itself. Generics, which I think are a good thing, except for for the stupid implementation they got in Java, are far worse for the syntax than operator overloading, not just in Java but in C++ too. As long as you think of operators in general as just another method to a class, I can see no more obfuscation potential in them than properties in .Net or preprocessor macros in C++. Properties in .Net are very convenient and everybody loves them, while C++ cannot exist without the preprocessor. As for the syntax, in C++ you have nothing added or removed from the syntax with or withoug operator overloading.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 9, 2009 9:59 AM

> you think of operators in general as just another method
> to a class, I can see no more obfuscation potential in

However they are methods with unusually short names --- much shorter than are usually considered acceptable. There should be a strong relationship between the usual meaning of an operator and its overloaded meaning.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 9, 2009 10:43 AM

> Team members should of course not compete against each
> other. However, the team has no choice but to compete
> against other teams. If other teams, made of similarly
> skilled programmers as those in my team, use tools which
> allow them to deliver better code, maybe in just 10% of
> all cases, just due to operator overloading, they have a
> competitive advantage over my team.

Of course. But if operator overloading causes your team to deliver worse code, you have a competitive advantage by not using it.

Again, I'm not sure whether operator overloading is such a bad thing. I've never had it affect me adversely. But some people think the downsides are not worth the benefits.

One thing you need to realize too is that in IT shops, people tend to not be able to make decisions for themselves. That is, they either can't figure it out or are not allowed to. Even if you can, coming to a decision will take 100s of man-hours of meetings. Not having a choice is often advantageous to these teams. For example, where I work now we have all kinds of contractors writing code. We have to ensure that they follow our standards (in theory) but if we used a language that allowed all kinds of things that we didn't want them doing, we'd constantly be accused (by the contracting firms) of causing cost over-runs. Often, we' be overruled because the delays rewrites would cause. It's a hell of a lot easier to just use something like Java where they can't cause too much trouble.

Java (prior to 1.5) had a fairly good set of features for this kind of environment. On the other hand, for developing software for sale, I would definitely not choose Java given the options that exist today. My experience writing software for external customers was that we had a much better handle on what we would accept and what we would not.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 9, 2009 10:53 AM

> > you think of operators in general as just another
> method
> > to a class, I can see no more obfuscation potential in
>
> However they are methods with unusually short names ---
> much shorter than are usually considered acceptable. There
> should be a strong relationship between the usual meaning
> of an operator and its overloaded meaning.

This is what I like about operator overloading in Python. The definitions of operators are named with text.

The thing about operator overloading that I would think would be a little tricky is that we tend to think of operators based on their mathematical meanings. e.g. '+' should be symmetric: 3 + 4 = 4 + 3. Often overloaded operators break these rules "a" + "b" != "b" + "a". And when you throw inheritance and polymorphism into the mix, it becomes harder to maintain these expected behaviors.

Not that that means they should be banned. But I think overloaded operators require more thought than most methods.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java

Posted: Apr 12, 2009 5:32 AM

> One thing you need to realize too is that in IT shops,
> people tend to not be able to make decisions for
> themselves. That is, they either can't figure it out or
> are not allowed to. Even if you can, coming to a decision
> will take 100s of man-hours of meetings. (...)

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

Flat View: This topic has 210 replies on 15 pages [ « | 9 10 11 12 13 14 15 | » ]

Previous Topic

Next Topic