Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 5 6 [7] 8
  ignore  |  Print  
  If you ever wanted a reason to use a modern langauge...  (Read 41516 times)
0 Members and 1 Guest are viewing this topic.
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #180 - Posted 2006-02-18 07:39:02 »

Wow this thread actually became useful again. What a surprise Smiley

But awfully dull isn't it.[...]

Yea, your arguments were pretty dull, but I'm sure you'll do better next time.

弾幕 ☆ @mahonnaiseblog
Offline .uj

Junior Member





« Reply #181 - Posted 2006-02-18 08:32:18 »

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.
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #182 - Posted 2006-02-18 09:47:04 »

Wow, an ignorant fool. :-D

I was having such fun with the pointless micro optimisations until then.
Good luck with the hate, and all that. *slips out of thread*

Play Minecraft!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kaffiene
« Reply #183 - Posted 2006-02-18 10:09:39 »

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.
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #184 - Posted 2006-02-18 11:48:57 »

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  
long long b = 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!

:: JOODE :: Xith3d :: OdeJava ::
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #185 - Posted 2006-02-18 12:19:24 »

This thread made me chuckel quite a few times, thanks for the entertainment .uj.

Just one thing to add:

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

Yet they have felt the need to go to C#, what an amazement. And if your brain is just a little bigger than a peanut, you'll realise how closely related C# is to Java.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline .uj

Junior Member





« Reply #186 - Posted 2006-02-18 12:42:58 »

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++.  Grin

Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #187 - Posted 2006-02-18 12:51:26 »

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

no wait, let's go like this:

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.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 793
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #188 - Posted 2006-02-18 13:51:56 »

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
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #189 - Posted 2006-02-18 16:28:57 »

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!).
From this article: http://www.joelonsoftware.com/articles/Wrong.html

Here is another one on memory management:
Quote
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.)

Article: http://www.joelonsoftware.com/printerFriendly/articles/fog0000000319.html

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #190 - Posted 2006-02-18 18:27:29 »

[...]Even a moron could easily get OpenGL to perform like 10 percent faster using C++ than the same code written in Java.[...]

Yes, a moron would use immediate mode. But this is sorta off topic, isnt it?

弾幕 ☆ @mahonnaiseblog
Offline Jeff

JGO Coder




Got any cats?


« Reply #191 - Posted 2006-02-18 19:17:05 »

[...]Even a moron could easily get OpenGL to perform like 10 percent faster using C++ than the same code written in Java.[...]

Then I suggest this moron go out and actually PROVE one of his dozens of unsubstantiated claims, since he claims he can.

And in the meantime I seriously suggest the rest of us stop feeding this idiot child the negative attention he is so obviously trolling for,.

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #192 - Posted 2006-02-18 19:33:17 »

Here is an article from an avid C++/Windows programmer. (Owns his own successful software company)
...
From this article: http://www.joelonsoftware.com/articles/Wrong.html
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.
Smiley

The example quoted applies to any language where the programmer does something stupid. For example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
class StupidMath {
   static int add(int a, int b) {
      return a - b;
   }
}

...

int i = 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 Smiley

Yes, C++ seemed to really push it when they overloaded the shift operators to do I/O Smiley... 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 Smiley

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

Offline Anon666

Junior Member




aka Abuse/AbU5e/TehJumpingJawa


« Reply #193 - Posted 2006-02-18 23:16:15 »

whoa! Carm down people!
When did this thread become so full of hate :S
Offline Breakfast

Senior Member




for great justice!


« Reply #194 - Posted 2006-02-19 00:14:36 »

Quote
When did this thread become so full of hate :S

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.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #195 - Posted 2006-02-19 00:39:16 »

just let it die, don't reply the topic anymore, doh i just replied Grin
Offline kaffiene
« Reply #196 - Posted 2006-02-19 00:58:23 »

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)
Offline kaffiene
« Reply #197 - Posted 2006-02-19 01:05:20 »

Quote
The example quoted applies to any language where the programmer does something stupid. For example:
1  
2  
3  
4  
5  
class StupidMath {
   static int add(int a, int b) {
      return a - 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.
1  
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #198 - Posted 2006-02-19 02:59:55 »

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.

Offline Jeff

JGO Coder




Got any cats?


« Reply #199 - Posted 2006-02-19 03:09:16 »

Quote
When did this thread become so full of hate :S

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline kaffiene
« Reply #200 - Posted 2006-02-19 07:06:06 »

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

Junior Member





« Reply #201 - Posted 2006-02-19 08:27:51 »

[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?

Offline .uj

Junior Member





« Reply #202 - Posted 2006-02-19 08:54:34 »

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.

Offline .uj

Junior Member





« Reply #203 - Posted 2006-02-19 10:17:16 »

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.

Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #204 - Posted 2006-02-19 15:43:23 »

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 obviously didn't read the article I posted.

Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #205 - Posted 2006-02-19 15:45:12 »

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

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.

Offline Jeff

JGO Coder




Got any cats?


« Reply #206 - Posted 2006-02-19 18:45:13 »

IMHO The one mildly interesting thing left in this thread is charcterizing how many outright logical fallacies he/she/it has attempted to use in this non-argument:

Here's a good site:
http://www.datanation.com/fallacies/index.htm\

And here's a list of the ones I've seen go by:
  • Ad Hominem attack (Attacking the peson not the argument, a favorite it seems.)
  • Slothful Induction (the conclusion of a strong inductive argument is denied despite the
    evidence to the contrary
  • False Dilemma
  • From Ignorance
  • Complex Question (and a related one, changing the subject)
  • Consequences
  • Prejudicial Language
  • Popularity
  • Appeal to Authority
  • Hasty Generalization
  • Unrepresentative Sample (acutallly NULL sample)
  • Accident
  • COnverse Accident
  • Begging the Question
  • Irellevent COnclusion
  • Straw Man
and one not even listed, but popular by today's demogogues in general, and UJ's favrite
  • Asserting facts not in evidence and with no proof

Feed and Annoy the Troll At Your Own Risk.  Im not going to bother.  Mental KILL-LISTS are a wonderful thing.





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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #207 - Posted 2006-02-19 19:28:29 »

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.

Cas Smiley

Offline kaffiene
« Reply #208 - Posted 2006-02-20 02:50:02 »

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.
Offline Jeff

JGO Coder




Got any cats?


« Reply #209 - Posted 2006-02-20 03:33:08 »


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: 1 ... 5 6 [7] 8
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (19 views)
2014-09-12 09:08:26

Norakomi (54 views)
2014-09-10 13:57:51

TehJavaDev (63 views)
2014-09-10 06:39:09

Tekkerue (31 views)
2014-09-09 02:24:56

mitcheeb (53 views)
2014-09-08 06:06:29

BurntPizza (37 views)
2014-09-07 01:13:42

Longarmx (23 views)
2014-09-07 01:12:14

Longarmx (27 views)
2014-09-07 01:11:22

Longarmx (26 views)
2014-09-07 01:10:19

mitcheeb (34 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!