Playing devil's advocate is fine when you use sound arguments. Most of the arguments you have made against Java are old, misgiuded and outdated.

Such as? You say so because you so very much want to believe that any argument against Java is old, misguided and outdated.

I've mentioned Java's lack of value semantics for objects. It tends to make people lower the abstraction level in time challanged code. So the idea that Java would be more high-level than C++ turns out to be wrong. In practice for efficiency reasons people tend to lower the abstraction. The problem can be relaxed by optimization techniques of the runtime system, but it's still inherent to the language.

What about arrays in Java? You cannot turn off bounds-checking of arrays. This is a real disadvantage in "algoritm type" code. It's another disadvantage inherent to the language. Java will never be able to scan an array as quickly as C++.

I could go on and on but in an environment like this where everybody wears blinkers it's hardly meaningful. Everybody else knows that C++ is a modern language with many inherent advantages over Java. So dear OP, the above in combination with Java's track-record of hype in combination with weak delivery, is why people hasn't felt a desperate hurry to abandon C++ for Java.

I think many who are reluctant to Java are like me. We're neither starry-eyed evangelists nor 15 year old geeks, just plain middle-aged engineers familiar with both Java and C++. We have experienced the development of Java firsthand since its birth. And I can honestly say that's it not until now with version 6 I feel fully confident in Java on the desktop and would recommend it to a friend.

What about arrays in Java? You cannot turn off bounds-checking of arrays. This is a real disadvantage in "algoritm type" code. It's another disadvantage inherent to the language. Java will never be able to scan an array as quickly as C++.

I could go on and on but in an environment like this where everybody wears blinkers it's hardly meaningful. Everybody else knows that C++ is a modern language with many inherent advantages over Java. So dear OP, the above in combination with Java's track-record of hype in combination with weak delivery, is why people hasn't felt a desperate hurry to abandon C++ for Java.

I think many who are reluctant to Java are like me. We're neither starry-eyed evangelists nor 15 year old geeks, just plain middle-aged engineers familiar with both Java and C++. We have experienced the development of Java firsthand since its birth. And I can honestly say that's it not until now with version 6 I feel fully confident in Java on the desktop and would recommend it to a friend.

You're a moron. I'm neither an evangelist nor 15 years old. I'm 35 years old, I've been coding since I was 15. I know Java, C, C++ like the back of my hand and countless other languages (LISP, C#, Asm68k, Delphi, BASIC, ADA, Pascal, Python.... and probably a few more I forgot). Java is a very good language in general and plenty fast enough for games. *You* are the misguided fanboy when you come in and start spouting utter rubbish like that crap about bounds checking - I benchmarked a bunch of array thrashing tasks back at Java 1.3 (versus MS visual C++) and even *then* the performance was pretty much identical.

Your "everyone knows" argument is what I'd expect of a troll. I have *actually* benchmarked Java versus C++. I have *actually* written an Open GL gameloop in C++ and ported the code to Java for exactly the same performance. Unlike your pulled-out-of-your-arse opinion, I have actualy done the work, written the code and benchmarked the buggers. And I can tell you that you are full of shit.

speed gets totally unimportant, when something like printing a variable to standart out modifies a variable in your code behind your back and your code then simply stops working!!! I know this is the case, because when I comment out the line that says something like:

1

cout << a<<endl;

It starts working!!!!

a is of type long long (don't tell me you can't print long long to cout!), so even if I do

1 2

longlongb = a;cout << b <<endl;

it still does not work. It *ofcourse* prints the correct value of a or b, also if I print both.

Not working *fast* C++ code is much more useless as *extremely slow* Java code. (Java is not slow, but I don't want to start with that again).

System.out.println() never does such a crap!!!

C++ is not only outdated, it is also crap!

PS: Don't tell my I'm a C++ n00b or something like that (even if it might be true), but even n00bs shouldn't be able to get such errors!

You're a moron. I'm neither an evangelist nor 15 years old. I'm 35 years old, I've been coding since I was 15.

I don't care if you've programmed since before conception. Your arguments are weak. Your benchmarks only test your own abilities as a programmer and you obviously aren't as good as you think. Even a moron could easily manage to get say a matrix multiply microbenchmark in C++ to perform like 10 to 30 percent better than Java. Even a moron could easily get OpenGL to perform like 10 percent faster using C++ than the same code written in Java.

I suggest you modify your attitude a notch. Nobody buys arguments based on - I did this and I did that and what I found is the ultimate truth because I'm so god damn good I can hardly believe it myself and everybody who thinks otherwise is a troll. You're oozing of low credibility. You couldn't even convince Gosling that Java is better than C++.

It tends to make people lower the abstraction level in time challanged code. So the idea that Java would be more high-level than C++ turns out to be wrong. The problem can be relaxed by foo, but it's still inherent to the language.

It tends to make people lower the abstraction level in time challanged code. So the idea that <Programming language foo> would be more high-level than <Programming language bar> turns out to be wrong. The problem can be relaxed by <solution>, but it's still inherent to the language.

forget about java, c++ and all that, your argument doesn't make sence in any possible way.

And I can honestly say that's it not until now with version 6 I feel fully confident in Java on the desktop and would recommend it to a friend.

Who am I to say your wrong, however I do wonder how you rhyme it with your 'arguments' and what barign they have of version 6 what they actually have to do with desktop specific things? perhaps I'm the only one seeing a contradiction here.

Even a moron could easily manage to get say a matrix multiply microbenchmark in C++ to perform like 10 to 30 percent better than Java.Even a moron could easily get OpenGL to perform like 10 percent faster using C++ than the same code written in Java.

Well, a moron or not, the funny thing is that a 10% slowdown in 1 thing, will rarely drop the whole engine-speed 10%.Even a performance-drop of 10% for a whole engine, is perfectly acceptable IMHO, if your development-time is cut in half, and even a "moron" can code it.

That may sound like me being a moron in your ears (I bet it does), but would you notice the difference between 60 and 54fps? I wouldn't care less.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Here is an article from an avid C++/Windows programmer. (Owns his own successful software company)

Quote

In general, I have to admit that I’m a little bit scared of language features that hide things. When you see the code

i = j * 5;

… in C you know, at least, that j is being multiplied by five and the results stored in i.

But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it. And i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called. And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere, because now you have to traipse all the way up the class hierarchy all by yourself trying to find where that code really is, and if there’s polymorphism somewhere, you’re really in trouble because it’s not enough to know what type i and j are declared, you have to know what type they are right now, which might involve inspecting an arbitrary amount of code and you can never really be sure if you’ve looked everywhere thanks to the halting problem (phew!).

That opens another whole can of worms: memory allocators. Do you know how malloc works? The nature of malloc is that it has a long linked list of available blocks of memory called the free chain. When you call malloc, it walks the linked list looking for a block of memory that is big enough for your request. Then it cuts that block into two blocks -- one the size you asked for, the other with the extra bytes, and gives you the block you asked for, and puts the leftover block (if any) back into the linked list. When you call free, it adds the block you freed onto the free chain. Eventually, the free chain gets chopped up into little pieces and you ask for a big piece and there are no big pieces available the size you want. So malloc calls a timeout and starts rummaging around the free chain, sorting things out, and merging adjacent small free blocks into larger blocks. This takes 3 1/2 days. The end result of all this mess is that the performance characteristic of malloc is that it's never very fast (it always walks the free chain), and sometimes, unpredictably, it's shockingly slow while it cleans up. (This is, incidentally, the same performance characteristic of garbage collected systems, surprise surprise, so all the claims people make about how garbage collection imposes a performance penalty are not entirely true, since typical malloc implementations had the same kind of performance penalty, albeit milder.)

While Joel writes interesting articles and I like to think they make sense a lot of the time, his "successful software company" produces some really shitty software... so when Joel says something, I tend to use that fact to put what he says in perspective.

The example quoted applies to any language where the programmer does something stupid. For example:

1 2 3 4 5 6 7 8 9

classStupidMath {staticintadd(inta, intb) {returna - b; }}

...

inti = StupidMath.add(j,k);

Hmm. seems Java can be just as dumb. The extension to operator overloading does add some risk... but it isn't a problem in the "real world" because only poor programmers would do something so dumb, and if you are dealing with code done by such a programmer then THAT is just a tiny issue in the big picture

Yes, C++ seemed to really push it when they overloaded the shift operators to do I/O ... but how many C++ coders really run into problems?

Anyway, there is no sense arguing with .uj because she doesn't understand when her argument has been defeated (hint: several pages back). It's like trying to fight a war against suicide bombers.. when the enemy blows themselves up... they just aren't playing the same game

Sadly, her strategy is not uncommon... the whole group she represents is destined for a Darwin award.

When .uj started trolling it back down from something quite interesting into the same tired and pointless argument that everyone who cares about it has already been through numerous times. The Java vs C++ argument continues to be an irrelevance. It will not stop being one.

You're a moron. I'm neither an evangelist nor 15 years old. I'm 35 years old, I've been coding since I was 15.

I don't care if you've programmed since before conception. Your arguments are weak. Your benchmarks only test your own abilities as a programmer and you obviously aren't as good as you think. Even a moron could easily manage to get say a matrix multiply microbenchmark in C++ to perform like 10 to 30 percent better than Java. Even a moron could easily get OpenGL to perform like 10 percent faster using C++ than the same code written in Java.

I've probably been coding C longer than you've been alive. I KNOW how to make it go fast.

If *you* think Java/OpenGL is so much slower that C++/OpenGL then why done *you* code a comparsion, provide the source code and *prove* it. Or are you just full of hot air? (and yes, I know that's a rhetorical question because clearly you are too chickenshit to put up)

The example quoted applies to any language where the programmer does something stupid. For example:

1 2 3 4 5

classStupidMath {staticintadd(inta, intb) {returna - b; }}

The difference is that in java you see "a.add(b)" but in C++ you see "a + b". In the former, you 100% know that a method call is occuring, with the latter, you don't know without trawling the code. As you say, there's no helping stupidity (.uj proves that) but a language in which you can read a line of code and see what's happening is clearly better than one where you read the line of code and have to know the rest of the code base to understand it.

The difference is that in java you see "a.add(b)" but in C++ you see "a + b". In the former, you 100% know that a method call is occuring, with the latter, you don't know without trawling the code. As you say, there's no helping stupidity (.uj proves that) but a language in which you can read a line of code and see what's happening is clearly better than one where you read the line of code and have to know the rest of the code base to understand it.

1

Quote

True, but another way of looking at it is you could assume a method is ALWAYS being called for operators in C++ and that there are intrinsic built-in methods for the default operations. Not much different than .toString() or something else that is standard but can be overridden.

When .uj started trolling it back down from something quite interesting into the same tired and pointless argument that everyone who cares about it has already been through numerous times. The Java vs C++ argument continues to be an irrelevance. It will not stop being one.

+100

But I think it long ago pased the point of pointlessness and thus is best just abandoned.

** wishing he hadnt done away with "Land of the Trolls" **

JK

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

The difference is that in java you see "a.add(b)" but in C++ you see "a + b". In the former, you 100% know that a method call is occuring, with the latter, you don't know without trawling the code. As you say, there's no helping stupidity (.uj proves that) but a language in which you can read a line of code and see what's happening is clearly better than one where you read the line of code and have to know the rest of the code base to understand it.

1

Quote

True, but another way of looking at it is you could assume a method is ALWAYS being called for operators in C++ and that there are intrinsic built-in methods for the default operations. Not much different than .toString() or something else that is standard but can be overridden.

...but if you assume that a method is ALWAYS being called for operators in C++, you will *still* be wrong a large portion of the time and you *still* don't know what the truth is until you've read the code ( (a) check elements are objects and if so, (b) see if they overload operators)

[Well, a moron or not, the funny thing is that a 10% slowdown in 1 thing, will rarely drop the whole engine-speed 10%.Even a performance-drop of 10% for a whole engine, is perfectly acceptable IMHO, if your development-time is cut in half, and even a "moron" can code it.

That may sound like me being a moron in your ears (I bet it does), but would you notice the difference between 60 and 54fps? I wouldn't care less.

You're making a common mistake. You're confusing the technical issue with the implications it may have in a certain context..

The technical issue is neutral and can be discussed in isolation. For example the bounds checking of arrays in Java makes some code say 10% slower than the equivalent in C++ without such checking. A totally different questions is what consequenses this has in a certain situation and if it matters to you?

Here is an article from an avid C++/Windows programmer. (Owns his own successful software company)

I don't quite follow you. You seem to suggest that C++ has issues too? Well of course! C++ is vastly more complex than Java and that's one of the main advantages of Java in my view. Its simplicity.

But that doesn't change the issues with Java I've mentioned. C++ allows you to keep up abstractions better in time challanged code. C++ allows you to switch off bounds checking of arrays. There are more of these and there's no use in predending they don't exist. If they matter to you is one thing but you cannot wish away everybody's right to decide whether they matter to them or not. That's what I call weak argumentation. You confuse your wishes with arguments.

The difference is that in java you see "a.add(b)" but in C++ you see "a + b". In the former, you 100% know that a method call is occuring, with the latter, you don't know without trawling the code. As you say, there's no helping stupidity (.uj proves that) but a language in which you can read a line of code and see what's happening is clearly better than one where you read the line of code and have to know the rest of the code base to understand it.

You started out by claiming you know both languages and are a very competent programmer of both but I understand now that you've been exaggerating quite a lot.

Java has a split type system with primitives on one hand and classes on the other. C++ has the same but goes to great lengths trying to bridge the gap sporting both value semantics for objects and operator overloading. Java has another strategy introducing an increasing number of "special support" for selected classes. I could mention the + operator of String and autoboxing of the wrapper classes. I don't think the Java way necessarily leads to a "better knowledge of what's happening".

Well designed so called concrete classes in C++ are as easy to use as primitives in Java and that's the purpose. If you accept doing a + b on primitives in Java what's so strange about doing a + b on say a Complex or a Point3D in C++? If you don't know how the method/operator is defined you have to check it up. This applies equally to both Java and C++.

With your ramblings you have only demonstrated your ignorance. My point remains. In Java you're more likely to discard a Point3D abstraction and use the individual floats in time challanged code. In C++ you wouldn't have to if you had a well designed concrete Point3D class at your disposal, with or without operator overloading.

The difference is that in java you see "a.add(b)" but in C++ you see "a + b". In the former, you 100% know that a method call is occuring, with the latter, you don't know without trawling the code. As you say, there's no helping stupidity (.uj proves that) but a language in which you can read a line of code and see what's happening is clearly better than one where you read the line of code and have to know the rest of the code base to understand it.

You started out by claiming you know both languages and are a very competent programmer of both but I understand now that you've been exaggerating quite a lot.

Java has a split type system with primitives on one hand and classes on the other. C++ has the same but goes to great lengths trying to bridge the gap sporting both value semantics for objects and operator overloading. Java has another strategy introducing an increasing number of "special support" for selected classes. I could mention the + operator of String and autoboxing of the wrapper classes. I don't think the Java way necessarily leads to a "better knowledge of what's happening".

Well designed so called concrete classes in C++ are as easy to use as primitives in Java and that's the purpose. If you accept doing a + b on primitives in Java what's so strange about doing a + b on say a Complex or a Point3D in C++? If you don't know how the method/operator is defined you have to check it up. This applies equally to both Java and C++.

With your ramblings you have only demonstrated your ignorance. My point remains. In Java you're more likely to discard a Point3D abstraction and use the individual floats in time challanged code. In C++ you wouldn't have to if you had a well designed concrete Point3D class at your disposal, with or without operator overloading.

While Joel writes interesting articles and I like to think they make sense a lot of the time, his "successful software company" produces some really shitty software... so when Joel says something, I tend to use that fact to put what he says in perspective.

I can't argue that point because I haven't tried his software yet. But, it can't be that bad, or he wouldn't be in business for 7 years and making more than $2million a year.

But that doesn't change the issues with Java I've mentioned. C++ allows you to keep up abstractions better in time challanged code. C++ allows you to switch off bounds checking of arrays.

.uj, you really need to do some reading on whitepapers about current and recent VM techniques and thinking (and stuff going forward too for that matter). You'd know for example about bounds check hoisting, and you'd know also that one of the main reasons we choose Java is because it has bounds checking, which means that some fool's library can't give us a security leak from a buffer overrun, and that we can absolutely trust memory not to get buggered. You'd also know about RFE 4820062 and be looking to the future. You'd know about escape analysis, and concurrent collectors, and lock elision, and intrinsics, and so on. You'd probably realise that all of these things are why we aren't worried about that last 10% because we're going to get that 10% back in fairly short order and at the same time keep our guaranteed safe code. Etc. I know you're concerned about the OP's surprise that this hasn't happened yet for mainstream devs but the fact is we're at 90% already and that's been good enough for 99% of titles for some time now.

Now please go and research this stuff because you're not doing a great job of representing your point of view here in public armed with none of this knowledge.

The difference is that in java you see "a.add(b)" but in C++ you see "a + b". In the former, you 100% know that a method call is occuring, with the latter, you don't know without trawling the code. As you say, there's no helping stupidity (.uj proves that) but a language in which you can read a line of code and see what's happening is clearly better than one where you read the line of code and have to know the rest of the code base to understand it.

You started out by claiming you know both languages and are a very competent programmer of both but I understand now that you've been exaggerating quite a lot.

Java has a split type system with primitives on one hand and classes on the other. C++ has the same but goes to great lengths trying to bridge the gap sporting both value semantics for objects and operator overloading. Java has another strategy introducing an increasing number of "special support" for selected classes. I could mention the + operator of String and autoboxing of the wrapper classes. I don't think the Java way necessarily leads to a "better knowledge of what's happening".

Well designed so called concrete classes in C++ are as easy to use as primitives in Java and that's the purpose. If you accept doing a + b on primitives in Java what's so strange about doing a + b on say a Complex or a Point3D in C++? If you don't know how the method/operator is defined you have to check it up. This applies equally to both Java and C++.

With your ramblings you have only demonstrated your ignorance. My point remains. In Java you're more likely to discard a Point3D abstraction and use the individual floats in time challanged code. In C++ you wouldn't have to if you had a well designed concrete Point3D class at your disposal, with or without operator overloading.

You completely failed to understand my post. Nothing you have said speaks against the point I made.

As for C++, I've been programming it since the time when the only implementations were C preprocessors. But you probably knew than since you know everything a priori and without resort to actual experience.

As for C++, I've been programming it since the time when the only implementations were C preprocessors. But you probably knew than since you know everything a priori and without resort to actual experience.

Another C-front veteran! cool!

jk

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org