48 replies to this topic

[zoneweb]

Slow compared to what? C++, C, Assembly? The JVM has come an awful long way in its 15+ years. And of course there are multiple vendors of JVMs now, all with different performance properties.

Minecraft is written in Java, and while it might not be that much to look at, a whole mass of computations are going on under the hood.

If it was fast, then the graphics could've been done better. Java is not good for gaming unless you're content with not going beyond subpar 3D graphics. Yes, there are commercial games made with Java, but they're only a few in number (at least on PCs). That's a telling sign that it's not meant for heavy duty games.

Not so much -- There's a native code SDK available too, which I'd make an educated guess is the preferred environment for pro game developers, for portability between PC and iOS if nothing else.

Programs written with the native code SDK still require a VM (for the Android OS at least), which defeats the purpose of writing in native code.

A simple, self-contained library that doesn't do what you want isn't very helpful, regardless of how well its documented or clear the code is.

Multiple libraries that aren't well documented aren't very useful either. Many functions and classes are often so interlinked and esoteric that examples are required to know the proper use of them.

C++ simply doesn't make any over-reaching attempts to protect you from yourself. Java and many other modern, RAD-oriented languages have extensive guardrails in place, while C++ is happy to let you walk off the end of the pier; however, that does't change the fact that good design is required regardless of language or programming paradigm.

So the best languages are the ones that act like nannies? I see that cognitive laziness and impulsiveness, but I agree with your point.

Again, there's something to be said for simplicity, and I actually have a lot more respect for JavaScript than your average Joe -- but its hardly a panacea of simplicity. Javascript performance varies greatly between browsers, as does the feature-set needed to do anything interesting with games. Performance swings from one extreme to the other between even versions of the same browser.

Though JS code is prone to hanging up because of bad loops or whatnot, it won't crash in the way that compiled programs do. With the recent addition of the canvas element, making games with decent 2D graphics is possible. It's a good alternative to flash, which has even worse performance issues.

[Telastyn]

If it was fast, then the graphics could've been done better.

The background computation isn't exactly a hinderance for minecraft. The thing runs on iPads with little difficulty. The graphics could've been done better if the interesting/hard/useful things weren't the priority. Or if there were more people working on it, or y'know... if it actually mattered.

So the best languages are the ones that act like nannies? I see that cognitive laziness and impulsiveness

Laziness has little to do with it. People have a fairly universal limit on the number of things they can juggle at any given time. The less cycles you're wasting tracking bullshit the computer could do for you the more you can spend on the problem at hand.

[SimonForsman]

If it was fast, then the graphics could've been done better. Java is not good for gaming unless you're content with not going beyond subpar 3D graphics. Yes, there are commercial games made with Java, but they're only a few in number (at least on PCs). That's a telling sign that it's not meant for heavy duty games.

Actually graphics is not an issue with Java, you can make games that are graphically far more impressive than todays AAA console games without any problems, the language has almost nothing to do with graphics performance today as its all done by the GPU. (drawcalls are more expensive with Java due to the JNI overhead but a OpenGL drawcall in Java isn't more expensive than a DX9 drawcall in C++ (It is more expensive than a OpenGL drawcall in C++ though)) and standard practice is to reduce the number of drawcalls to a minimum regardless of language and API), The reason for the generally poor graphics has more to do with the people using it (mostly indies with low budgets) and the target platforms (Mobiles and low range PCs with integrated GPUs)

Performance wise Java is on par with most C++ implementations with a few notable exceptions:
1) Native calls are slower due to the JNI overhead
2) Trig functions are noticably slower outside of the accurate range on x86 and a few other platforms (This is pretty much a non issue if you are aware of it as there are easy workarounds (unless you need the high precision but then it would be slow even if you rewrote it in C++)

problem 1 is solved by batching the drawcalls and avoiding immediate mode OpenGL (same as the solution to expensive drawcalls in C++ basically, only its more important in Java).
problem 2 is solved by doing a low accuracy argument reduction yourself before you call the function or by using lookup tables.

[patrrr]

Oh, cool! Opinions! Here are some of mine;

Why Java is (and Java projects tend to be) wrong:

• Tools are slow, and setting everything up for a project can take time
• Incredibly verbose language, makes it harder to get a good idea of what the code actually does
• Type erasure in generics is bad for you
• It doesn't have character; it's a gray, dull, unimaginative and shallow language
• All the crazy abstractions and inheritance chains people make
• No functions

What's good with Java:

• Some of the JVMs are really performant and well-engineered projects
• It's reasonable to say that Java handles larger projects with many developers better than C++
• It has implementations on many systems, no need for recompiling
• No need to think about garbage collection. Not that much, anyway.
• Execution can be fast

[StoneMask]

So say someone wanted to make the best possible running games, performance and flexibility-wise. What would be the best option while disregarding the support and popularity of a certain language? Elegance, power, efficiency, etc.?

[swiftcoder]

What would be the best option while disregarding the support and popularity of a certain language? Elegance, power, efficiency, etc.?

Haskell, or maybe Prolog?

None of the faux-object-oriented languages, so popular among the masses, comes anywhere close to their elegance, power or expressiveness.

(I'm only half joking)

[Bacterius]

So say someone wanted to make the best possible running games, performance and flexibility-wise. What would be the best option while disregarding the support and popularity of a certain language? Elegance, power, efficiency, etc.?

I always found Brainfuck strangely... soothing to read. It's a bit tedious to the untrained eye though.

I personally love Pascal Object ,for several reasons:
- it's not quite mainstream, yet isn't dead by any means
- I find the language elegant
- It has performance characteristics close to raw C
- you can instantly and seamlessly switch from object-oriented programming to imperative programming, go from class methods to syscalls, without needing to P/Invoke or whatever the current fancy term is.
- compilation is actually fast (although that's probably not a characteristic of the language itself)
- it's cross-platform (FPC/Lazarus)
- it just works (and errors are actually descriptive and helpful) and fast to fire up a project
- library header ports: OpenGL - check. OpenAL - check. OpenCL?? check. DirectX 9/10/11 - check, although those may be a bit unstable, and lots of other cool libraries.
- etc..

That said when you're talking about GPU performance, languages will perform almost identically, since all they do is send instructions to the driver, which will work at the same speed regardless of what language sent the instruction. The real difference comes into play when performing heavy-duty algorithms on the CPU, and even then the gap is closing. I believe the best-suited language for a given task is the one that makes it as easy and elegant as possible to write a given algorithm.

Any language can be used to make an AAA game. Hell, you could just take an AAA game's source, run it through a language converter (which can be done provided both languages are "complete"), and you're all done (theoretically). But I would probably cut my wrists if someone told me to write even a simple tetris in Brainfuck - because it's not suited to the task. It *can* be done theoretically, but you're infinitely better off using a more flexible language.

So basically, use the language you're most comfortable with, unless it is definitely unsuited to what you're looking to do - in that case, do yourself a favor and switch languages. For instance I used to toy around with C# while doing graphics stuff, since it already had some good bindings and lots of online examples. Then I got hooked up into GPGPU technology, remembered my favorite language had an OpenCL port, and I left C# for dead. Not because Pascal Object was better at calling OpenCL functions nor because it was easier to write algorithms there (furthermore, in OpenCL kernels are written in a C dialect, so..), but because I simply preferred one over the other, equivalent (for this task) language.

Programming should be fun, and you shouldn't be forced into a language you don't enjoy just because it's mainstream or some other stupid reason. Unless you're obviously shooting yourself in the foot using such and such language over another, go ahead. But don't hesitate to learn new languages either, even if you don't need to (like, you might be stuck in a cave with nothing but a Python interpreter one day or something).

TL;DR: if you don't like Java, don't use it when it's not needed. But definitely learn it because one way or the other, you *will* need to use it at some point. But nobody's putting a gun to your head and forcing you to use it 24/7.

[Telastyn]

This comes up in some of the programming language forums I frequent. Academics espouse the virtues of Haskell and it's kin while poo-pooing popularity/adoption of mainstream languages. Nothing much against haskell (which is one of the best out of mainstream languages) but popularity matters. If a whole lot of programmers could make better games faster in Haskell than its alternatives don't you think someone would leap on that? There is always a gotcha.

[swiftcoder]

Nothing much against haskell (which is one of the best out of mainstream languages) but popularity matters.

StoneMask specifically asked us to neglect support and popularity - that's the reason I suggested Haskell and Prolog. Yes, in practical terms they aren't terribly good choices for game development

[MarlboroKing]

Laziness has little to do with it. People have a fairly universal limit on the number of things they can juggle at any given time. The less cycles you're wasting tracking bullshit the computer could do for you the more you can spend on the problem at hand.

Why should a language "protect you from yourself"? That's the advantage of C++ that Java and C# will never see. Also, no matter what language, clock cycles are still being used to free the memory allocated which takes away from your game. But if you want to talk about bullshit tracking, Java's easiest solution for memory leak detection is a seperate program, 7 steps, 2 runs, dumping the stack each run, loading dumps and comparing. C++ is 1 header, 1 define, 1 function and usually 1 run and it'll tell you what function and even what line. That's not including the time spent debugging and testing the fix because that'll usually be same same on either language.

No matter what language you choose, there are positives and there are negatives. Don't assume C++ is better than Java and don't assume Java is better than C++, they both have their pro's and con's that smash eachother into a practically equal state. Choose what you are comfortable with and/or would be the best solution for you.

[Telastyn]

Why should a language "protect you from yourself"?

Because humans are inaccurate. Multiple humans are inaccurate and have trouble communicating.

That's the advantage of C++ that Java and C# will never see.

What advantage is that? That C++ code lets you make more bugs for no benefit?

That is what is called a disadvantage.

Also, no matter what language, clock cycles are still being used to free the memory allocated which takes away from your game.

Not clock cycles, mental cycles. If you can only track 7 independent variables and some of those are spent managing variable lifetimes in your code, you've got less brainpower to use for real coding.

But if you want to talk about bullshit tracking, Java's easiest solution for memory leak detection is a seperate program, 7 steps, 2 runs, dumping the stack each run, loading dumps and comparing.

Umm, no. Load up netbeans, run profiler (optionally installing JProfiler), include memory tracking, done. I'm fairly certain other IDE's provide similar mechanics.

You won't get a line number, but you're also only doing memory leak debugging once in a blue moon since you have a garbage collector...

[Cornstalks]

Slow compared to what? C++, C, Assembly? The JVM has come an awful long way in its 15+ years. And of course there are multiple vendors of JVMs now, all with different performance properties.

Minecraft is written in Java, and while it might not be that much to look at, a whole mass of computations are going on under the hood.

If it was fast, then the graphics could've been done better. Java is not good for gaming unless you're content with not going beyond subpar 3D graphics. Yes, there are commercial games made with Java, but they're only a few in number (at least on PCs). That's a telling sign that it's not meant for heavy duty games.

Ummm... Welcome to the 21st century, where the bottleneck in graphics is: the graphics card, your shaders (if you write the like crap, they'll run like crap), and memory I/O (between RAM and the video card). These days, the amount of graphical work done on the CPU is tiny.

[jbadams]

So say someone wanted to make the best possible running games, performance and flexibility-wise. What would be the best option while disregarding the support and popularity of a certain language? Elegance, power, efficiency, etc.?

Disregarding the support -- and tools, which you didn't explicitly mention -- really makes your question one that doesn't apply very well to any real-world development. In many cases, good tools and language support are far more important than small differences in elegance or efficiency of the language itself.


When looking at efficiency, don't forget to take into account that the compiler or interpreter, running environment, and specifics of the task being carried out will greatly outweigh the choice of language; you might get great efficiency from a particular language on some platforms, but if you're required to target one where that isn't true it may suddenly become a great choice even if it is otherwise perfect for your needs. If a language is for some reason inefficient when tackling a certain specific task that might be critical for your project which does that task all the time, but if your game only does that task occasionally or not at all it doesn't really matter how inefficient it is.

If it [java] was fast, then the graphics could've been done better.

[CRYP7IK]

If it was fast, then the graphics could've been done better. Java is not good for gaming unless you're content with not going beyond subpar 3D graphics. Yes, there are commercial games made with Java, but they're only a few in number (at least on PCs). That's a telling sign that it's not meant for heavy duty games.

Spoken like a person who has no sense of style. Seriously though, while you are correct (Crysis in Java?) Minecraft has it's style for a reason but Java is able to do a lot nowadays. For example look at jMonkeyEngine and see what can be done with Java. This is without saying a single person will not be able to model, texture and animate things at Crysis level so that is most probably not going to happen and renders that point moot.

Programs written with the native code SDK still require a VM (for the Android OS at least), which defeats the purpose of writing in native code.

No it doesn't.

So the best languages are the ones that act like nannies? I see that cognitive laziness and impulsiveness, but I agree with your point.

Most usages of C++ turn it into that anyway with smart pointers and things like that. Then you go even further with memory buckets etc. Until you basically end up writing verbose C#. If you don't do that with C++ your game or program is going to have so many possible ridiculous bugs and lots of undefined behaviour. Don't believe me? Look at this blog post by John Carmack.

In reply to the OP. Just think about your actual requirements and what each language brings to the table that you want.

[Wiitoy200]

Maybe it is because everytime a program requires me to install Java, I look for another program that doesn't, and usually succeed.

I'm sorry, but that reason is sh*t. thats like saying "well the reason valve games blow is because it requires me to download steam and i look for another gamethat doesn't and usually succeed". pure bullsh*t.

[Wiitoy200]

so i've been reading most of the posts put up here (because some started saying stuff i didn't understand so i was all like "next") and what i've seen so far is

C++ is just as bad as java
java still blows (just not as hard as i thought)
C# is my best bet

true or am i completly off?

[Nypyren]

so i've been reading most of the posts put up here (because some started saying stuff i didn't understand so i was all like "next") and what i've seen so far is

C++ is just as bad as java
java still blows (just not as hard as i thought)
C# is my best bet

true or am i completly off?

C++: For programmers who want to write all of the code themselves.
Java: For programmers who want to have other people write all of the code for them.
C#: For programmers who want the code to write itself.

This post is hyperbole. Or is it?

[Hodgman]

C++ is for systems programming or embedded programming.
Java and C# are for application programming.

On Windows:
C++ programs often need a 2MB "C++ runtime" to be installed.
C# programs need the 50MB ".NET framework" to be installed (which may have been pre-installed by windows).
Java programs need the 20MB "JRE" to be installed.

Java and C# are arguably both derived from C++, but modified to be (arguably) more productive for general programming. They're both "managed" languages, which provide a much more robust and well-defined abstract machine than C++ provides.

[Washu]

On Windows:
C++ programs often need a 2MB "C++ runtime" to be installed.
C# programs need the 50MB ".NET framework" to be installed (which may have been pre-installed by windows).
Java programs need the 20MB "JRE" to be installed.

That's a bit misleading, so lets clarify:
When packaging your application for distribution you need to include the CRT MSI packages, which are approximately 2MB. They are not installed by default with windows, and thus are always a required component. When distributing a .net application you need only package the 800K web installer for the .net framework (appropriate version), as it will then download the correct version and install it IF IT IS NOT ALREADY INSTALLED. Now, regardless of how you package your application, and regardless of the runtime requirement (we're ignoring java here btw), the end result is that you will always be using more disk space than what is listed above... because of SxS versioning. Just to give a quick example, I currently have about 800MB of Microsoft CRT versions sitting in my WinSxS folder... I should also note that the full VC redist for x86 is 8MB, the same redistributable for x64 is 10MB. So if you include x64 versions of your application, along side an x86 version that's 18MB of CRT packages.

[swiftcoder]

C++ is for systems programming or embedded programming.
Java and C# are for application programming.

This section is a bit misleading too.

C++ is widely used in developing end-user applications, though not to the extent it was before the rise of Java, .NET, and software-in-the-cloud.

On the other side of the fence, there have been OS written from the ground up in Java (and I vaguely recall a pure-hardware JVM at one point), and a lot of so-called 'embedded devices' run Java.

And in the mainstream of OS development or embedded programming, you'll rarely find C++ *either*. It's considered too bloated and error-prone for use in the Linux kernel, and embedded platforms tend to lack a decent C++ compiler.