macOS Java or C? Which is better?

[poobah]

Perhaps a different slant, actually getting a job...

If I needed a good general purpose "programmer guy" (with apologies to the ladies), and you told me I could hire one of 2 programmers, one who was a good C programmer, and one who was a good (pick any of the high level abstract away every detail languages... java, ruby, whatever), I will take the C programmer every time.

I can teach a C programmer the other stuff, because the C programmer has a solid foundation. Like it or not, C is the underlying structure on which many of the higher level languages are built. Once you know C, it is a simple matter to "get spun up" on the higher level stuff.

It's easier to teach a mechanic to drive, than to teach a driver how to repair an engine. The mechanic understands the systems, how they work, what the implications and interactions are, etc. The driver knows the big pedal makes the car go faster.

If all you know is how to make calls on a massive library, you are missing fundamentals. If you have no understanding of how these libraries accomplish their tasks, you are ill prepared to choose the appropriate one.
Oh, and when I need to have a micro-controller talk to your application, I have to hire someone else to program it.

(caveat.... I'd really like a programmer who knows C *and* has a good grasp of OOP concepts. Those 2 skills cover a vast swath of programming requirements in the real world.)

 

[talmy]

I can teach a C programmer the other stuff, because the C programmer has a solid foundation. Like it or not, C is the underlying structure on which many of the higher level languages are built. Once you know C, it is a simple matter to "get spun up" on the higher level stuff.

If all you know is how to make calls on a massive library, you are missing fundamentals. If you have no understanding of how these libraries accomplish their tasks, you are ill prepared to choose the appropriate one.
Oh, and when I need to have a micro-controller talk to your application, I have to hire someone else to program it.

You've "got it" but C really has nothing to do with it. What's needed is a background in the fundamentals -- data structures, algorithms, OOP, design patterns... And it doesn't really matter which language you use. Now it may be true that a C programmer knows more about these fundamentals than someone who has only used, say, Perl, but it's not necessarily so. The language is just a tool and you use whatever is available.

My personal history -- wrote my first program in 1968 in a Basic-like language and later in Fortran, first C program in 1980, Java in the late 1990s. Writing programs is part of my occupation as an Electrical Engineer and always has been. I use C for embedded code, C, C++ (with Qt4), and Java elsewhere. A well used set of Knuth's Art of Computer Programming is on my shelf as well as Design Patterns by the GoF, and a first edition of The C Programming Language (among other books).

 

[mrichmon]

C++ is by far the most powerful language with proven concepts decades old. Once a sufficient level has been reached it is virtually IMPOSSIBLE to write badgood C++ code.

There, I fixed that for you.

C++ is a useful and powerful language. It is widely used and also widely abused. Writing good, reliable, and maintainable C++ code requires strong programmer discipline. Without careful use, C++ ends up being developer-hostile.

 

[mrichmon]

Sure, but you had to think about it. And if you had accidentally typed i<=30 instead of i<30, you're now executing 31 times. On the other hand, a Ruby statement like "30.times" will execute, well, 30 times.

This is a trivial example, though. Let's say you have a function that collects sensor data and stuffs it into an array of indeterminate length. After collecting the data, you then want to print out the results, one per line.

In C, your code would look something like this:

	float data_array[ARRAY_SIZE] ; /* The array that will hold our sensor data */
	int sensor_measurements ; /* Holds the return value of collect_sensor_data(), which indicates how many measurements were collected */
	int i;
	sensor_measurements = collect_sensor_data(data_array, ARRAY_SIZE) ; /* collect_sensor_data() takes the maximum number of measurements so we don't overrun our buffer */
	for(i=0 ; i < sensor_measurements; i++) {
		printf("Measurement %i: %f\n", i+1, data_array[i]);
	}

The equivalent code in Ruby would be:

sensor_data().each_with_index{ |value, index| puts "Measurement #{index + 1}: #{value}" }

The Ruby code is not only simpler and more compact, ...

The Ruby code shown is not a direct equivalent of the C code shown.

The C code is calling a separate function that may be in a separate library to obtain the data values. Once the values are obtained then the C code prints out each of the data values.

In comparison, the Ruby code assumes that the data values are already available and just prints out the data values one by one. As such, the Ruby code only implements half of the work performed by the C code. Assuming the work is defined as:

1. Obtain the data values
2. Print the data values

There are also several ways that the C code can be shorten to be more compact. There are also similar ways that the Ruby code can be expanded to have a more natural equivalency with the C code.

For example (using C99):

	float data_array[ARRAY_SIZE] ;
	int sensor_measurements = collect_sensor_data(data_array, ARRAY_SIZE) ;
	for(int i=0 ; i < sensor_measurements; i++) {
		printf("Measurement %i: %f\n", i+1, data_array[i]);
	}

 

[poobah]

You've "got it" but C really has nothing to do with it. What's needed is a background in the fundamentals -- data structures, algorithms, OOP, design patterns... And it doesn't really matter which language you use. Now it may be true that a C programmer knows more about these fundamentals than someone who has only used, say, Perl, but it's not necessarily so. The language is just a tool and you use whatever is available.

My personal history -- wrote my first program in 1968 in a Basic-like language and later in Fortran, first C program in 1980, Java in the late 1990s. Writing programs is part of my occupation as an Electrical Engineer and always has been. I use C for embedded code, C, C++ (with Qt4), and Java elsewhere. A well used set of Knuth's Art of Computer Programming is on my shelf as well as Design Patterns by the GoF, and a first edition of The C Programming Language (among other books).

Completely agree. My definition of "good C programmer" includes the fundamentals. Without them, you are a bad C programmer

My bookshelf looks like yours, though I have Code Complete next to my 'gang of four' book. I also require any new team members to read "The Design of Everyday Things". The not so good programmers always say "well these things are obvious", then give me code that violates several of the ideas.

 

[macsmurf]

Perhaps a different slant, actually getting a job...

If I needed a good general purpose "programmer guy" (with apologies to the ladies), and you told me I could hire one of 2 programmers, one who was a good C programmer, and one who was a good (pick any of the high level abstract away every detail languages... java, ruby, whatever), I will take the C programmer every time.

I can teach a C programmer the other stuff, because the C programmer has a solid foundation. Like it or not, C is the underlying structure on which many of the higher level languages are built. Once you know C, it is a simple matter to "get spun up" on the higher level stuff.

I disagree. It's not a sliding scale. It's different paradigms. Different languages promote different ways of thinking about solving problems.

It's easier to teach a mechanic to drive, than to teach a driver how to repair an engine. The mechanic understands the systems, how they work, what the implications and interactions are, etc. The driver knows the big pedal makes the car go faster.

It's easier to teach anyone how to drive than how to repair an engine.

If all you know is how to make calls on a massive library, you are missing fundamentals. If you have no understanding of how these libraries accomplish their tasks, you are ill prepared to choose the appropriate one.
Oh, and when I need to have a micro-controller talk to your application, I have to hire someone else to program it.

Being a good C programmer does not give you any special insight into how a library accomplishes its tasks, as opposed to being a good * programmer.

Lucene, for example, is a search engine library for Java. In order to get a deep understanding of that library you need some knowledge of the approaches for searching through text. Whether or not those approaches have been implemented in C is utterly irrelevant.

(caveat.... I'd really like a programmer who knows C *and* has a good grasp of OOP concepts. Those 2 skills cover a vast swath of programming requirements in the real world.)

Why? You just said it was easy to teach him. Just give him a week to read through GoF

 

[macsmurf]

The Ruby code shown is not a direct equivalent of the C code shown.

The C code is calling a separate function that may be in a separate library to obtain the data values. Once the values are obtained then the C code prints out each of the data values.

In comparison, the Ruby code assumes that the data values are already available and just prints out the data values one by one. As such, the Ruby code only implements half of the work performed by the C code. Assuming the work is defined as:

1. Obtain the data values
2. Print the data values

Huh? In the Ruby program, sensor_data() (a function) obtains the data values. each_with_index then performs some action on each of the values, where the action in this case is printing.

Although I disagree with the poster's conclusion, the point I believe he was trying to make was that a rather large part of the C program is about managing the array of values and not actually about the task at hand (printing the values collected from somewhere else). In the Ruby program all that is abstracted away. We don't really care what the underlying data structure returned from sensor_data() is, nor do we need to manage it.

 

[ytk]

The Ruby code shown is not a direct equivalent of the C code shown.

The C code is calling a separate function that may be in a separate library to obtain the data values. Once the values are obtained then the C code prints out each of the data values.

In comparison, the Ruby code assumes that the data values are already available and just prints out the data values one by one. As such, the Ruby code only implements half of the work performed by the C code.

That's incorrect. I should know—I wrote the code!

As macsmurf explained, sensor_data() is a function that collects and returns the value of the sensor data, which can then be operated on directly with no need to store it in an interim variable.

Of course, I only put in the parentheses for this example to make it clear that sensor_data was a function. Most Ruby programmers would leave them off, writing sensor_data.each_with_index... I didn't do that because I thought someone might raise the objection you raised if I did, that the data was assumed to be there and never collected. But that's one of the things that's really cool about Ruby—it doesn't matter either way! sensor_data might be a variable or a function that returns a value, and the programmer accessing it would neither know know care which it was, as long as it returns the correct data when you reference it.

 

[throAU]

Ruby. Lol.


It might be easier, but I know of no real projects written in ruby. It is simply not as commonly used as either Java or C.

If you learn either C (and then ObjC is a superset) or Java you'll have plenty of work available.

As I said previously, Java is probably more versatile in terms of actual employment (cross platform apps), but C gets you closer to the hardware and can be used for lower level stuff.

Lower level stuff though is mostly a solved problem these days (just use the OS libraries from a higher level language) unless you're involved in a few specific industries, like game development, for example.

 

[tr!pf!3]

C is just so much faster.

 

[kthomp]

So out of Java and C which has the most uses, what are they, and which is easier as a sort of gateway language for learning others?

Which is better and/or which has the most uses? Neither. Both. Each is better than the other depending on the problem you're trying to solve. To put it a different way, there is no Golden Hammer.

Which is easier as a gateway language? I would say Java would be easier for a novice to pick up, but C is probably better as a precondition for learning Objective C.

What are their uses? Impossible to list. Both are exemplars of particular kinds of languages, and frankly, approaches to programming. I think anyone interested in programming should be familiar with both.

 

[VinegarTasters]

You should learn C, then migrate to C++. If you can, learn assembly as well. .NET, JAVA, Python, Ruby, and all interpreted languages are going out of style. As things get more mobile, battery life and limited memory are more of a factor than the benefits you get from dumbing down via abstraction from actual hardware. There IS one golden hammer... assembly. Speed will prevent you from using Java or C#, etc, to make AAA games. You can use C, as that is fairly low for drivers (things close to the kernel), but even people go towards assembly for inner loops in AAA games when they code in C.

There was a brief period of time where webservers in Java were ok, but their benefits were gotten via loading tons of things inside main memory, regurgitating rather than processing. If you do research and speed or memory size is not important, then slow chugging Java, C# is ok. Simple web apps like html widgets are ok in these slow languages, but even then they will slow down your OS so much people rather not use them, and download apps instead. (look at the number of widgets in osx from developers).

 

[Cromulent]

If you do research and speed or memory size is not important, then slow chugging Java, C# is ok.

I hope you realise that Java JIT compilation allows for optimisations of the code that are simply not possible in a statically compiled language such as C or C++. Thus in some circumstances Java can actually outperform C or C++.

Speed of the language though is often not the problem. The thing that most often makes a program slow is the algorithm used to implement it. If you have a ****** algorithm it doesn't matter if you implement it in assembly, it will still be dog slow.

 

[softwareguy256]

Java is dog slow for many reasons. you sound like a college kid who has no clue of the business. I'd send you home if I was interviewing you.

I hope you realise that Java JIT compilation allows for optimisations of the code that are simply not possible in a statically compiled language such as C or C++. Thus in some circumstances Java can actually outperform C or C++.

Speed of the language though is often not the problem. The thing that most often makes a program slow is the algorithm used to implement it. If you have a ****** algorithm it doesn't matter if you implement it in assembly, it will still be dog slow.

 

[talmy]

Java is dog slow for many reasons. you sound like a college kid who has no clue of the business. I'd send you home if I was interviewing you.

Then I might hire him. I had a fairly complex simulation which was originally written in C++ back in 1998 that I recoded into Java which I was just learning at the time, and it was, indeed, faster. And there were good reasons for this, mainly because the language was better suited for what I was trying to accomplish and I found better ways to implement the algorithms because of it. Sometimes the "efficiency" of a compiled language (or assembler) doesn't get you faster operation, or faster implementation. I was selling Forth systems I developed in the 1980s which outperformed C (a financial system where they had to figure out how to embed the Forth calculation engine in a larger system because their attempt to implement it in C was half the speed) and even assembly (a stepper motor controller where the assembler code was using a poor algorithm for advancing motor position).

 

[kthomp]

You should learn C, then migrate to C++. If you can, learn assembly as well. .NET, JAVA, Python, Ruby, and all interpreted languages are going out of style. As things get more mobile, battery life and limited memory are more of a factor than the benefits you get from dumbing down via abstraction from actual hardware.

Java is the primary target language and environment in Android development, dropping down into native when necessary. So the most popular mobile O/S uses one of your examples of a language which is "going out of style", which makes me question your argument

 

[VinegarTasters]

Java is the primary target language and environment in Android development, dropping down into native when necessary. So the most popular mobile O/S uses one of your examples of a language which is "going out of style", which makes me question your argument

Yes, Java WAS Android's primary language, forcing everyone to use it. Then they realized how slow it was, and how few hardcore action games are on it, they had to release the NDK, where you can program in C/C++, but still stuck in their slow Java wrappers. If Java could do anything, NDK wouldn't have been needed. Even Chrome mobile and jellybean OS shows they are moving away from Java to keep up in speed. Do you know why Android mobile phones usually have double or quadruple the amount of ram than iOS devices? Because Java is a memory hog. Same with C# and all interpreted languages. The common yardstick is this: Java/C# 10 times slower than C. 5-10 times more memory than C. Java was so slow, in benchmarks they had to use so much tricks to make it meet or barely faster than C/C++. But if you do the same tricks in C/C++ you end up being 10 faster again. (things like unrolling loops, table lookups, etc).

Same thing with C# (that Java copied language) and the .NET interpreted stuff. I don't know what Oracle was thinking when they bought SUN. If they start putting everything in Java, they will surely lose to SAP. The performance is so slow., while speed is so critical in databases. Even Google bypassed slow harddrive and putting everything into RAM. (YES, they would rather pay millions buying RAM than save money buying harddrives).

Now does this mean Java or C# is bad? No. But in mobile devices yes, they sure are. Even in desktop, the slowness from LLVM technology in Lion and Mountain Lion and the huge increase in minimum RAM makes them laughing stocks. While doing some work, I pressed the file open from TextEdit. It took 10 seconds for the stupid dialog to pop up. I can almost guaranteed this was a virtual machine JIT. The second time, it popped up quicker. There are so many of these spinning circle sessions. This was in Mountain Lion. I don't know what they are thinking, but I am sure if they end up being like Corel, not putting performance in their design and implementation specs, they have no one else to blame but themselves. Just because it is the latest thing (like the rewritable optical disks in NeXT) doesn't mean it is the best. Performance is critical in OS. It limits what apps do on top of them if the OS is the bottleneck. EVERYONE know Windows games run faster then OSX games on same hardware. Why is this common knowledge? SLOW OS. Even Objective-C is slower than C/C++. I don't even know why it is even necessary to use it just because at the time it was released they thought it was the greatest technology... No, you choose appropriate behavior for appropriate situations. The OS being the lowest layer, MUST RUN FAST, or it will slow everything ABOVE it. Performance is critical in that situation.

Now someone will now come in and say, well, I did this thing in slow language, but it ended up faster than C or assembly! Yes, if you do something using a slow algorithm in a faster language, it may be slower than a faster algorithm using a slow language. If you did the same algorithm in both languages, then of course C or assembly will be faster almost 1000% faster. For example, bubble sort versus quicksort.

 

[Cromulent]

Java is dog slow for many reasons. you sound like a college kid who has no clue of the business. I'd send you home if I was interviewing you.

You obviously have no idea what you are talking about. Frankly I'd be worried if you were interviewing me. Get a clue before making stupid posts.

Oh and if you are going to make a claim that "Java is dog slow for many reasons" then you need to back up your claim with facts. Otherwise you just look like a fool.

 

[VinegarTasters]

You obviously have no idea what you are talking about. Frankly I'd be worried if you were interviewing me. Get a clue before making stupid posts.

Oh and if you are going to make a claim that "Java is dog slow for many reasons" then you need to back up your claim with facts. Otherwise you just look like a fool.

I think you are out of your league.

http://stackoverflow.com/questions/...-sharp-benchmark-questions-code-and-results-i


You are talking microseconds versus milliseconds.

http://wiki.answers.com/Q/What_is_smaller_micro_or_milli

Yes, C is micro. Java is milli. C# is even slower.

 

[Cromulent]

I think you are out of your league.

http://stackoverflow.com/questions/...-sharp-benchmark-questions-code-and-results-i


You are talking microseconds versus milliseconds.

http://wiki.answers.com/Q/What_is_smaller_micro_or_milli

Yes, C is micro. Java is milli. C# is even slower.

I think you are the one who is out of their league. Rather than quoting Q&A links from unverified sources or a page from Wiki answers. How about some real academic papers?

Since you seem incapable of actually providing decent evidence to support your claims I will do it for you.

http://www.philippsen.com/JGI2001/finalpapers/18500097.pdf

Here is a quote:

We tested four Java environments under Linux. Of these, the IBM 1.3 JDK gave the best performance on all the benchmarks except MolDyn. In almost all cases of execution are less than for the NT version of the same JDK. The Blackdown 1.3 and the two versions of the Sun 1.3 were roughly comparable overall, though there are significant differences on individual benchmarks.

Comparisons with C compilers on the system are very favourable. The IBM 1.3 JDK is on average slightly faster than KAI C++ and only 15% slower than GCC. The mean ratio of fastest Java to fastest C execution times in only 1.07. At this level of difference there is no case for preferring C to Java on grounds of performance.

That means that Java is faster than one C++ compiler and only slightly slower than another C++ compiler. Also to add these benchmarks were conducted using 1.3 of the JDK. Since that time significant improvements have been made which will increase performance even more.

So until you can show some proper evidence to back up your claims (and that means academic peer reviewed papers not something you have found on Stackoverflow or Wiki Answers) please stop posting because you clearly have no idea what you are talking about.

 

[VinegarTasters]

I think you are the one who is out of their league. Rather than quoting Q&A links from unverified sources or a page from Wiki answers. How about some real academic papers?

Since you seem incapable of actually providing decent evidence to support your claims I will do it for you.

http://www.philippsen.com/JGI2001/finalpapers/18500097.pdf

Here is a quote:



That means that Java is faster than one C++ compiler and only slightly slower than another C++ compiler. Also to add these benchmarks were conducted using 1.3 of the JDK. Since that time significant improvements have been made which will increase performance even more.

So until you can show some proper evidence to back up your claims (and that means academic peer reviewed papers not something you have found on Stackoverflow or Wiki Answers) please stop posting because you clearly have no idea what you are talking about.

Look, if you want to win the argument, you should try a newer paper (1998? holy). At the time that paper was released, Java is even slower than todays Java (before the maturation of JIT, etc). All those people are doing is taking someone super good in Java doing extreme optimization on it and testing it with C. Read my previous comments. If the same optimization are done in C we are back to 10 times faster.

Ask Android why there are no AAA games in Java. It is just too slow. And the effort to do it (using all tricks of Java) is just not worth it when you can simply do a simple non-tricks version in C and beat it. You could have taken the Quake in Java beating C/C++ benchmark, where they went though all sort of tricks. (if you do the same thing in C, goes back to square one) I'm not here to argue with you. Just go ahead and make something in Java and C yourself using the same algorithm and come back.

Look at the first link. It is the SAME algorithm for all languages. No tricks. Compile it, in Java. Compile it in C. Run them both. 1000 times faster! For large programs, you get average 10x faster (where you can get variance because of classes, compared to functional). But just for some simple small loop Java 1000 time slower! Thats 1000000% slower! 10 times slower is 1000% slower. I know it may feel sad at these figures, and maybe you have some experience in Java. But just ask around people who have created software like games on them. Ask them what the main problem is. IT IS DAMN SLOW! It takes so much memory too for the virtual memory. And the garbage collector kicks in, screwing up the framerate at odd times, forcing you to keep everything in global memory if possible.

In other words, if someone is super good in Java tricks, and someone is super good in C. Bet your life on the C guy. If someone is super good in C and someone is super good in assembly. Bet your life on the assembly guy. If you eventually work with a supercomputer, where speed and memory is no problem, go ahead, do work in Java. Otherwise, find benchmarks with SAME algorithm, no tricks. If you allow different algorithms, then it is experience in of one guy against experience of another person which ends up skewing it. Google added C/C++ to placate the Android developers. Apple actually force Java and interpreted languages off iOS (then they went back to allow emulators). One is to speed up, the other is to speed up.

If after you read the above and you STILL are not convinced...

Read this: 2011 (NOT 1998!)
http://bruscy.republika.pl/pages/przemek/java_not_really_faster_than_cpp.html

C++ is slower than C. So if you code it in C even faster. A fast C loop is VERY FAST. Faster than object oriented method with all the C++ overhead. Assembly is even faster.

If you STILL need convincing...

http://shootout.alioth.debian.org/

Play with that. If you want to make a Java benchmark faster than C, simply find weakest in C code, and code the Java using their strong points. If you want experience on the topic, peruse all the benchmarks in that link. (note they remove the first loop, where JIT is compiling, which is actually helping Java, so if you include it, it is STILL DAMN SLOWER) On average with the first loop it is 10x+ slower in practical use. Experience is greater than theory. Again, I'm not here to argue with you. So either you take it as it is, or you can be like the emperor with no clothes story guy.

 

[talmy]

The higher level languages give more abstractions that make programming more productive and less error prone. You can off course write anything in assembler, since ultimately everything is running machine code anyway. And because of this you can always write more optimal code in assembler or a low level language like C. Heck, the first C++ compilers were translators that converted C++ to C for compilation.

I remembered another example (besides my Java vs C++ one). I was working at Tektronix which had a license to produce Smalltalk systems (speaking of "dog slow"?). We had one product where the interpreter was written in 68000 assembler, but some people were interested in a version that would run on the IBM PC (with an 80386 processor). I took on the challenge in in a few months did an implementation entirely in C except for graphics primitives ("bitblt" and line drawing) and bytecode dispatching. The 68000 proponents were smug that this quickly cobbled, high level language implementation would be awful, however it ran twice as fast as the 68000 code.

You keep talking about "AAA games" and I really don't know what they are but can imagine that for games speed is the top criterion. So you are willing to invest more time (and money) crafting the code particularly in assembler for maximum speed. I'm much more concerned with implementation time and program correctness. Embedded programming moved from assembler to C some years ago. There is no way we could afford to use assembler. It was used for compactness, but the microcontrollers have far more capacity than they used to have so space is not a problem. Programs running on Linux and Windows are all C++ or C# now. I don't use Java here but as I mentioned, used it for many years. It has hooks for assembly language that I've used to interface with hardware but never used it for performance enhancement. Algorithms are always the most important factor in performance.

 

[497902]

Java Sucks

 

[VinegarTasters]

The higher level languages give more abstractions that make programming more productive and less error prone. You can off course write anything in assembler, since ultimately everything is running machine code anyway. And because of this you can always write more optimal code in assembler or a low level language like C. Heck, the first C++ compilers were translators that converted C++ to C for compilation.

I remembered another example (besides my Java vs C++ one). I was working at Tektronix which had a license to produce Smalltalk systems (speaking of "dog slow"?). We had one product where the interpreter was written in 68000 assembler, but some people were interested in a version that would run on the IBM PC (with an 80386 processor). I took on the challenge in in a few months did an implementation entirely in C except for graphics primitives ("bitblt" and line drawing) and bytecode dispatching. The 68000 proponents were smug that this quickly cobbled, high level language implementation would be awful, however it ran twice as fast as the 68000 code.

You keep talking about "AAA games" and I really don't know what they are but can imagine that for games speed is the top criterion. So you are willing to invest more time (and money) crafting the code particularly in assembler for maximum speed. I'm much more concerned with implementation time and program correctness. Embedded programming moved from assembler to C some years ago. There is no way we could afford to use assembler. It was used for compactness, but the microcontrollers have far more capacity than they used to have so space is not a problem. Programs running on Linux and Windows are all C++ or C# now. I don't use Java here but as I mentioned, used it for many years. It has hooks for assembly language that I've used to interface with hardware but never used it for performance enhancement. Algorithms are always the most important factor in performance.

Come on... you are not being fair. Comparing Motorola and Intel chip speed in ADDITION to your experience coding C versus assembly? (you were wise to keep the graphical blits and interpretation in assembly though). Yes, I agree algorithm is important. No argument there. That is why you should compare languages using same algorithm. Quicksort in slow language can beat bubble sort in fast language depending on language.

As for AAA games, things like Battlefield 3 and Call of Duty or any high selling games on Sony Playstation3, like GTA5 , MGS4. Especially GT5. Only the menu or loading screens can you probably tolerate using higher level languages. The engine you won't find them running on Java. The closest Java came is probably Runescape and Minecraft. They can be played because their graphics are not that high or demanding compared to todays AAA titles. I put Minecraft as a casual game.

I have nothing against productivity and Java/C# etc. Its just that in mobile devices, there is limited battery life, which means limited power consumption, limited space, limited memory. Interpreted languages are the opposite. They suck up time/power/memory. Even if you do really well and get Java to only be 2 times slower than C++, a 30FPS AAA game will run 15FPS, killing the game on the platform. If Java was forced as the language of choice for OSX, guess what? All 30FPS games mentioned above WONT run on OSX because no matter how fast you code, the kernel in command of the drivers will slow it down many times. Casual games you can get away with... That is why Java is still ok on Android for these.

 

[softwareguy256]

To state the obvious, any interpreted language has a non-zero overhead and garbage collection introduces non-deterministic running time that is simply unacceptable for many mission critical tasks. Cube jobs, IT work, there's so much slack and the penalties for mistakes are so minor that using ANY language including java and visual basic are acceptable.

It is blatantly ABSURD to say that Java is faster than C++ and its only a matter of time whether it is 1, 5, 10, 20 years before you realize that I am right. But the base pay says everything. If you are making under 6 figures you need to be quiet immediately, because it shows that the market does not really value your opinion or your expertise.

You obviously have no idea what you are talking about. Frankly I'd be worried if you were interviewing me. Get a clue before making stupid posts.

Oh and if you are going to make a claim that "Java is dog slow for many reasons" then you need to back up your claim with facts. Otherwise you just look like a fool.