/* attempt to deal with prototype, bootstrap, jquery conflicts */ /* for dropdown menus */

Jump to content

Image of the Day

Today's #ScreenshotSaturday features Face Your Fears from Turtle Roc ... #virtualrealityshop #mobilevr #vrshop https://t.co/3qhSNAVNOZ
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net's newsletters to receive the latest updates and exclusive content.

Sign up now

Recommendations of A Langauge

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
24 replies to this topic

#21 BGB   Members   


Posted 23 February 2013 - 03:43 PM

The various JVMs have some advantages over .Net/Mono
1) better runtime performance on *nix servers and in some cases non x86 clients.
2) Java is the "standard" language on Android. (The only good CLR implementation costs $299-$1899 per developer)
3) Some ARM CPUs can execute Java bytecode nativly.

When it comes to the actual languages i can't think of any reason to use Java over C# though and i wouldn't recommend Java over C# to anyone, (If you know C# you can easily switch to Java in the few situations where it works better anyway)

Jazelle is not really part of newer ARM ISA's, and has since been replaced by ThumbEE (now also deprecated).
ThumbEE, however, is not specific to JVM Bytecode, and can be used by CLR implementations as well.

You say this like it's a negative. Multiple inheritance is one of the worst features of C++, there is a reason later languages got rid of it.

No. Multiple inheritance has comparatively few applications, but it is not never the Right Thing. As the FAQ says: "People who spout off one-size-fits-all rules . . . make your design decisions without knowing your requirements. . . . there are some situations where a solution with multiple inheritance is cheaper to build, debug, test, optimize, and maintain than a solution without multiple inheritance."

FWIW, from a language/VM design and implementation perspective, MI is kind of a beast though, and its costs of supporting it tend to outweigh the cases where it is "actually useful", making a case for leaving it out of a language.
so, the classes+interfaces model can do "mostly similar stuff", and is much simpler/cheaper to implement (since the contents for every child class simply append onto the end of the parent class, ...).
another "cheap hack extension" to this model is making interfaces able to provide "default methods", which closes the gap a little more, but doesn't significantly increase implementation complexity (if a class implements an interface, and fails to provide an implementation of a default method, the one from the interface is simply grabbed and added into the class).

Operator overloading is another one of those language features that was so badly abused that it's value certainly becomes questionable.

No. If a language feature is abused, that doesn't mean the language feature is bad. It means that the programmers who abuse it are stupid.

In this case, not having it forces a hypothetical Java BigNum class to have an API like: "new BigNum(4).exponentiate(51).mod(6).subtract(1)". You laugh, but I have often seen method chaining of such cruftitude in production code.

traditionally, some amount of C++ code has abused operator overloading in stupid ways (some of which is present in the C++ standard library).
I suspect some of this may have been because it was still in the "new feature" stage, and many people will overuse and abuse new features until a sense of when/how they are best used develops.
but, they are still "pretty damn useful" sometimes, especially in cases where it actually makes sense, like extending the numeric tower with more types:
bignums or 128/256 bit numeric types;
vectors and matrices;
this is generally a big painful area in Java.

Lack of implicit control over memory manage[ment] is the only real missing feature that actually hurts the language, and even in that case, 99% of the time this is an advantage as well.

I agree somewhat, but not being aware of how memory is structured is a common pitfall of novice programmers. Exclusive use of Java encourages that. Finally, teaching ignorance of resource management is not merely suboptimal, but irresponsible.

better is to have things like structs and value-classes, and also an explicit 'delete' for cases where this is useful, ...

I'm not going to deny that C++ isn't somewhat messy and that, at least with respect to Java and C#, its syntax is somewhat less intuitive. I don't fancy perpetuating a holy war about which is better though, mostly because I don't really care. I will stick with my recommendation not because I necessarily like C++ better, but since C/C++ is the de facto standard for games, game engines, and high performance computing in general.


#22 Bearhugger   Members   


Posted 23 February 2013 - 04:36 PM

The short version is that Java is more foolproof than C++, but it comes at the cost of power. C++ has a few gotchas (like implicit constructors, pointers, operator overloading and multiple inheritance) that can cause you some obscure bugs if you don't know what you're doing.


Quite honestly, I don't think you'll hit a performance wall anytime soon if you're just starting with game programming and are aiming to make small games. Minecraft was written in Java so there's no doubt that Java can work to write games.


If your goal is to get started with game programming and eventually join the industry, a certain expertise of C++ is a must, but if you just want to make a small game on your own, Java sounds like the logical choice for you.


I have to agree that you should at least give a shot to C# though. The language is strongly inspired from Java so it's easy to switch, but it has built a lot on top of it over the years (and it's not just syntaxical sugar), and it is the default language for XNA, which allows you to make games for your PC and 360, which can be interesting. (XNA doesn't work on Metro or WP8 and there are rumors that it's being phased out, but it is still supported.)

#23 Trienco   Members   


Posted 24 February 2013 - 12:27 AM

The short version is that Java is more foolproof than C++, but it comes at the cost of power. C++ has a few gotchas (like implicit constructors, pointers, operator overloading and multiple inheritance) that can cause you some obscure bugs if you don't know what you're doing.


I think the major gotcha of C++ is a standard that basically states that half the things you technically can do in C++ result in undefined behavior. Especially beginners will do a lot of trial and error coding, which is absolutely fatal in a language that allows you to the most horribly wrong thing without so much as a warning.


In my experience one of the main reason for obscure bugs aren't "complicated" features, but relying on doing things in a way that "seems to work just fine" until it doesn't.


Quick example?


struct Header {
    uint16_t version : 3;
    uint16_t msgId : 3;
    uint16_t msgSize : 4;
    uint16_t msgType : 5;
    uint16_t needAck : 1;
uint16_t receivedHeaderData;
Header header = (Header)receivedHeaderData;


What's wrong with this? Hint: byte order is the same on every involved machine.

Edited by Trienco, 24 February 2013 - 12:32 AM.


#24 DevLiquidKnight   Members   


Posted 24 February 2013 - 06:47 AM

This thread has somewhat gone off topic, to get things a little bit more straight:

There is no real conscience over what language to use, they are individual tools in their own right, simply comparing one tool vs another, won't get you anywhere. They all do basically the same thing, each has its own unique set of features it brings to the table, and their own nuisances.


Your project goals should be the main factor in determining which you use, or even use multiple languages to accomplish one goal as is being done much now of days.


Just use what is best for you. As for the OP I would suggest they go into C# or C++, either are good choices for making games. The majority of the game industry uses C++ from what I understand. If you have a strong grasp of Java there is no real reason to hinder you from learning either language.


Yes, there are gotchas in C++, there are gotchas in C# as well, and even Java. This is not that big of a problem, just learn to identify and re-mediate them, it will make you a better programmer in the long run.

Edited by DevLiquidKnight, 24 February 2013 - 06:57 AM.

#25 Anri   Members   


Posted 24 February 2013 - 02:08 PM

I use Java because it was the most used language on the Degree I recently finished.  I would have preferred it focused on my first language, C++, but despite some eye-rolling at the way Java does certain things, I've stuck with it.


Using it for games programming...I've found I've not had to turn to any dedicated game or graphics api outside the standard Java library. For any 2D graphics and as far as "3D" ray-casting, I just do my own software rendering with setRGB on a backbuffer(women scream, men faint!). Years ago I would have used DirectX for everything, but I feel now that I'm at the level where I can code it myself...and doing it that way has been not only rewarding, but rather enjoyable. Bit slow, but for what I am doing its fast enough. I feel my education with Java has turned me into a better programmer where I no longer rely on API calls to deal with every problem I come across.  I also keep the code to a minimum. 


If you know Java well, and have good physical and online references to hand, then its a great language for at least 2D games. Another consideration is the Android platform which also uses Java...and as much as I can't stand those "hip'n'radical" tablets...there does seem to be a good games market for them.  The days of "C++ is the only choice for games development" are now gone...although C++ seems to remain the main player.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.