The Artima Developer Community
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

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 ... 7 8 9 10 11 12 13 14 15 | » ]
Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: The Positive Legacy of C++ and Java Posted: Mar 23, 2009 11:39 AM
Reply to this message Reply
Advertisement
>
> The fun part is that we are all good programmers and
> understand the problems and the solutions, but we are not
> doing anything to solve the problems.

Meh - we are all doing different things and what is the best solution for me would probably not be the best for you - even without taking into account subjective things like syntax. I am sure D is the dream language for Walter Bright, but it does not appeal to me at all.

Besides, even if we came up with a "perfect" language, chances of rewriting my employer's code base with it are zero :)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java Posted: Mar 23, 2009 12:37 PM
Reply to this message Reply
> > I think it's a little ironic that the three apps you
> > mention are all (AFAIK) written in C++. I'm pretty
> sure
> > Firefox is.
>
> They are (except that MS Office apps have some C left from
> olden days). It would be nice to compare similar Java
> applications, but there are none. What is your experience
> with Eclipse/NetBeans?

I don't use NetBeans but I use a low-pause concurrent collector with Eclipse and have no real issues with delays. If I leave the app running for months (as I often do) I might see a few second pause every few weeks. There are some things about Eclipse that are annoying but those are application design issues and not VM problems. Other than that, it's as responsive as any other application.

I have an application I wrote that I use for database queries. I also leave that up for months. since I forgot to start it with a concurrent collector, I get a pause once in a while after a big query (say 200K rows.)

> >
> > But the real thing that's confusing to me is that GC is
> > more efficient (in terms of CPU) than deterministic
> memory
> > deallocation. Basically GC lets the work pile up and
> then
> > cleans up in one big swoop often when there's reduced
> > load.
>
> Nothing prevents you from doing that without a GC when it
> makes sense, and plus you have actual knowledge about your
> application logic and know where is the reduced load. In
> fact I did that once.

It's just not a big deal for me. Java works fine for my needs. I'm not saying it's great for everything but it is well suited to a number of types of applications.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Mar 23, 2009 1:15 PM
Reply to this message Reply
> Meh - we are all doing different things and what is the
> best solution for me would probably not be the best for
> you - even without taking into account subjective things
> like syntax. I am sure D is the dream language for Walter
> Bright, but it does not appeal to me at all.

If we were to try a new language, it would be a language that would be programmable enough to accommodate most, if not all, styles. i.e. a better C++.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Mar 23, 2009 1:16 PM
Reply to this message Reply
> > Stroustrup's main goal was
> > performance. Objective-C dynamic dispatch method call
> will
> > never be as fast as a C++ non-virtual/virtual method
> call.
>
> It can be as fast as non-virtual method calling if you use
> imp caching on time critical portions. This, of course,
> unnatural and somewhat inconvenient, rather like giving up
> polymorphism in an alleged OO language for performance
> reasons.
>
> More about optimizing objective c:
> http://www.mulle-kybernetik.com/artikel/Optimization/opti-3
> -imp-deluxe.html
>
> > The run-time environment of C++ and many of the choices
> > make perfect sense from a performance point of view.
>
> I disagree with this. 99% of written code is not time
> critical and does not need maximum performance. If this
> were not true, Java, Ruby, Python, etc would be stillborn.
> As long as there is a means of expending a little extra
> a effort on bottlenecks to get closer to hardware and thus
> faster code, any language can be used for any real time
> application.
>
> C++'s problem is it thinks 99% of the time everything must
> be maximally performant and that just isn't true. Wrong
> tradeoff.

Doing Objective-C/Smalltalk like message passing in C++ is very easy. Here is a little piece of code I wrote in my spare time, along with a small article to explain it:

http://www.codeproject.com/KB/cpp/cppdmp.aspx

Yuval Goldstein

Posts: 1
Nickname: yuvalgo
Registered: Mar, 2009

Re: The Positive Legacy of C++ and Java Posted: Mar 25, 2009 8:20 AM
Reply to this message Reply
1. C++ enabled developers to build modular, expendable applications using Object Oriented patterns, but was still very hard to use.

2. Java (and C#) enabled even more developers to creates modular applications because it is easier to write (no memory handling).
Also, it enabled a huge amount of great application infrastructure to be used.

Still, it is not easy to write (and read).

3. Tools being built over the C# and Java are definitely the future.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The Positive Legacy of C++ and Java Posted: Mar 28, 2009 12:18 PM
Reply to this message Reply
> The fact is that hard real-time systems
> can't be implemented in software alone on a platform like
> the PC.
>
> At the risk of telling everyone what they already know,
> real-time is about time accuracy, not speed.

There are tolerances in everything. The average musician can perceive inaccuracies of a few milliseconds. Latency in MIDI performance applications is a well known annoyance in audio applications. The vast majority of the available apis make use of what would be considered high efficiency but relatively complex apis using large memory blocks filled with unions and special purpose functions called directly.

Finding these to be a PITA to work with, I put an OO layer atop it using Objective C and conventional "average performance" programming turning a block of MIDI messages into an NSArray of objects - one per message. I allowed all memory to be managed using the typical autorelease pool mechanism. I found no perceivable difference in runtime speed and frequently get compliments regarding how responsive the app is compared to most on the market.

My point remains - very little code actually needs the performance level to which C++ claims to aspire. All that inconvenience in the name of performance turns out to be a poor and unnecessary trade off and I consider C++ and Java's primitives to be the poster children for the evils of premature optimization.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Positive Legacy of C++ and Java Posted: Mar 28, 2009 12:27 PM
Reply to this message Reply
> My point remains - very little code actually needs the
> performance level to which C++ claims to aspire. All that
> inconvenience in the name of performance turns out to be a
> poor and unnecessary trade off and I consider C++ and
> Java's primitives to be the poster children for the evils
> of premature optimization.

There are many optimizations that I used 10 years ago but no longer use in code written today. However, when I first used them they were necessary to get the job done. So, for some of us at least, primitives were a necessary evil.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: The Positive Legacy of C++ and Java Posted: Mar 28, 2009 3:07 PM
Reply to this message Reply
> My point remains - very little code actually needs the
> performance level to which C++ claims to aspire. All that
> inconvenience in the name of performance turns out to be a
> poor and unnecessary trade off and I consider C++ and
> Java's primitives to be the poster children for the evils
> of premature optimization.

I never claimed that a lot of code needs to be high-performance, so I don't understand the relevance of your response. Real-time systems are usually implemented in hardware these days and, as been noted by others, MIDI is an example of it.

Just a historical note - MIDI was designed during the analog synthesizer era when synthesizer modules were voltage-controlled (e.g. voltage controlled oscillators) and keyboards produced control voltages. It's primary purpose was to avoid piping analog control voltages all over the place.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The Positive Legacy of C++ and Java Posted: Mar 28, 2009 6:58 PM
Reply to this message Reply
> > My point remains - very little code actually needs the
> > performance level to which C++ claims to aspire.

> I never claimed that a lot of code needs to be
> high-performance, so I don't understand the relevance of
> your response.

Just that every justification for C++'s flaws invariably involves some reference to how important it is for C++ to be maximally efficient at the expense of developer convenience and I'm saying that reason is simply not valid.

> Just a historical note - MIDI was designed during the
> analog synthesizer era when synthesizer modules were
> voltage-controlled (e.g. voltage controlled oscillators)
> and keyboards produced control voltages. It's primary
> purpose was to avoid piping analog control voltages all
> over the place.

It has evolved far beyond that.

The MIDI spec allows for 16 addressable devices on a single bus. Typically there was only one bus. Routing was easy - everything heard everything and discarded what wasn't addressed to it. Like early Appletalk. It doesn't scale though because it turned out to be so useful that inter-bus routing became important.

Continuous control information, synchronization, mixer automation, lots of other performance information is now part of the typical MIDI traffic stream and while originally THE MIDI bus could handle 16 devices, the average computer now juggles a dozen or more virtual MIDI buses, cross routing messages as appropriate and providing real time control over dozens of instruments and their performance parameters - all in software.

At the end of the day - it still doesn't need C++'s vaunted "high performance" annoyances to get the job done. FWIW, I also map all the render callbacks to the audio generators to objective c messages to objects using C function callback adaptors and these also perform more than adequately to provide sample accurate timing - so any slams on how dynamic languages like Objective C can't keep up are just hand waving. I have code that says otherwise.

You can write at any level of efficiency in any language you choose if you give it a little thought. These days, you don't even have to think hard.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Mar 29, 2009 2:03 PM
Reply to this message Reply
I doubt highly dynamic, completely interpreted languages will ever significantly bite into Java's market niche - static typing is good and enhances productivity for bodies of code large or critical enough or otherwise unfit to be maintainable by a single programmer. And most enterprise applications fit into this category, no matter what size they are.

While C++ is definitely the most powerful and feature rich language we have today, it carries some ballast which IMO has no way of being caused by backwards compatibility or approved after heavy thinking of experts. My favorites are two: the syntax, which is not only backwards compatible, but also awful to read, and private and protected inheritance, which IMO pervert the meaning of inheritance. You derive B from A to tell the world that B is a kind of A - if you do it publicly. If you do private or protected inheritance, your B is an A in disguise: it is actually a kind of A, but tells nobody about it, or, at best, its subclasses. What is this, programming or byzantine affairs?

IMO, for Java to continue to thrive the ppl at Sun driving Java should understand more of how a market works. If there's demand for something, somebody will put it on the market eventually, even if you don't. By not listening to what the market asks for you just make your market niche and share smaller. You don't really constrain the consumers to your offering, you just drive them away to other suppliers. So far, the JCP seems to cater to the wishes and whims of tool and platform builders, not to those of programmers. Programmers build their own tools and platforms, so there's really one and only one choice: do you want programmers to work with your stuff or not? They surely won't, if you don't give them what they ask for. (Think Spring vs. EJB for a better understanding of the issue.)

To design the perfect language we would need to have it developed as an open source project where most of the programmers of the world would have something to say. This would be a committee which would work, I think. Only, no enterprise would ever adopt this language for their projects, even if it was the best language in the world: they would not have whom to blame if they hired stupid programmers, and tool and platform builders would probably sabotage a language they can't control, or at least ignore it until it becomes mainstream.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: The Positive Legacy of C++ and Java Posted: Mar 29, 2009 6:47 PM
Reply to this message Reply
> You derive B from A to tell the world that B is a kind of
> A - if you do it publicly. If you do private or protected
> inheritance, your B is an A in disguise: it is actually a
> kind of A, but tells nobody about it, or, at best, its
> subclasses. What is this, programming or byzantine
> affairs?
>

In the era in which C++ was created there was more interest in direct reuse than there was in polymorphism. That is the primary value came from inherited functionality rather than the ability to call methods from different classes on the basis of common method signatures.

That view may have been unbalanced but I think the pendulum has swung the other way and today polymorphism is overvalued.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Mar 30, 2009 4:44 AM
Reply to this message Reply
> > You derive B from A to tell the world that B is a kind
> of
> > A - if you do it publicly. If you do private or
> protected
> > inheritance, your B is an A in disguise: it is actually
> a
> > kind of A, but tells nobody about it, or, at best, its
> > subclasses. What is this, programming or byzantine
> > affairs?
> >
>
> In the era in which C++ was created there was more
> interest in direct reuse than there was in
> polymorphism. That is the primary value came from
> inherited functionality rather than the ability to call
> methods from different classes on the basis of common
> method signatures.
>
> That view may have been unbalanced but I think the
> pendulum has swung the other way and today polymorphism is
> overvalued.

It's not the only thing that is overvalued...billions of lines of code and comments have been written on libraries and frameworks and programming languages, but little progress has actually been made in how we program stuff. Programming is as much of an art as it was in the past.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: The Positive Legacy of C++ and Java Posted: Mar 31, 2009 6:55 AM
Reply to this message Reply
>
> Just that every justification for C++'s flaws invariably
> involves some reference to how important it is for C++ to
> be maximally efficient at the expense of developer
> convenience and I'm saying that reason is simply not
> valid.
>

There are many circumstances when it is not valid, and in these circumstances you simply don't use C++. On the other hand, there are many (yes, many) circumstances when it is valid, and then C++ is useful. Why is it so hard to accept?

Not to mention that what you consider convenient (dynamic dispatch) I may consider error-prone and confusing.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Positive Legacy of C++ and Java Posted: Mar 31, 2009 7:03 AM
Reply to this message Reply
> >
> > Just that every justification for C++'s flaws
> invariably
> > involves some reference to how important it is for C++
> to
> > be maximally efficient at the expense of developer
> > convenience and I'm saying that reason is simply not
> > valid.
> >
>
> There are many circumstances when it is not valid, and in
> these circumstances you simply don't use C++.

One of the oddities is that the "maximally efficient" claim isn't really true --- you have to tell the compiler (or allow the compiler to assume) that you aren't using some (mis)features of the language.

Infernoz Infernoz

Posts: 6
Nickname: infernoz
Registered: Nov, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 1, 2009 4:00 PM
Reply to this message Reply
> > I know there is a learning curve, and that once you get
> > used to doing something, it becomes easier. But one
> good
> > thing about Java is that the curve was always short, as
> > was the "getting used to it" time.
>
> It's funny that you use 'was always short' instead of 'is
> always short'. I say that because I think Java lost a lot
> of it's main benefit when generics were added.
>
> I recently saw compile error posted on the Java forums
> where it looked like it was a compiler bug but no one was
> really sure. Everyone basically threw up their hands and
> gave up. It used to be that you'd have people
> passionately arguing about whether the compiler was right
> and trying to prove it based on the spec. Now no one even
> cares to try to explain.
>
> So I actually think Java is dying and generics is what did
> it in. But it has nothing to do with the lack of operator
> overloading or verbosity. It has to do with unwarranted
> complexity.

WTF, these must be pretty arrogant, dim, or lazy, people if they can't accept and figure out Javac errors; this suggests poor understanding, and lack of study of the Java language specification, and lazziness for systematic trial-and-error, until understanding dawns. Amateurs!

I strongly disagree, Generics, and Auto-boxing, make it much easier to write more readable type-safe code, however Sun should have explained the <? extends T> and <? super T> Generics wildcard rules much better, and removed the need for typed constructors e.g. for collection classes.

I applied Generics to two existing code projects, at work, this revealed/resolved some nasty type conflict bugs, and bad design, which could have caused hard to trace run-time bugs; so I have proved that Generics is quite a valuable feature.

The new for(type v : collection/array) syntax makes Generics even more useful, and mades the code far more readable, as does the @Override annotation, to tell the compiler to check method overides. I have also use the new Concurrency classes to replace unsafe (naively synchronized) collection code.

I also think that Java is very overdue for closures, and first class functions, they would make it far less painful to read/write visitors, filters, event handlers, and Runables; this could be compiler 'sugar' for anonymous inner classes, so even added to Javac, in earlier versions of Java.

Java is not dying, just some people like you can't be bothered to learn how to programme more effectively (e.g. learn patterns, design your own patterns/frameworks etc.), this sounds like slothful laziness, to busy professional developers like me! What chance do you stand with new langauges, if you can't be bother invest in Java wisdom.

BTW: I write enterprise data processing applications, and reasonably complicated JSP database reports, with backend classes, in Java 1.3, 1.4, and 1.5, I much prefer Java 1.5 for projects, because Java 1.3 and 1.4 are less readable, requires more typing, and lack useful packages, and features.

Flat View: This topic has 210 replies on 15 pages [ « | 7  8  9  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-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use