Jump to content
  • Advertisement
Sign in to follow this  
Adyrhan

Will it be C++ the preferred game dev language in 3 years from now?

This topic is 2123 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm a fan of C++ but I think that for production Java and OpenGL will lead for compatibility/readability advantages of both.

 

... Says the absolute dearth of Java / OpenGL games rolleyes.gif besides that, I have to question the sanity of anyone who believes that Java or OpenGL is more compatible or readable than alternatives in practical terms, despite promises of the contrary. The readability of both is perhaps a matter of taste, though.

 

For the kinds of things that C++ is really good at there really is no viable replacement--maybe D someday, or Rust, but certainly not any kind of Java or C#-like productivity language. The trouble with C++, really, even moreso than C, are the number of potholes you'll encounter on a daily basis. I think this stems mostly from the fact that so many subtleties are afoot that almost no piece of code does precisely what it appears to do, and any piece of code that does perform its purported function precisely probably bears only a passing resemblance--at least, with the way most people write C++. For example, probably any 10-20 line function of C++ that does anything at all non-trivial and which compiles with exceptions enabled probably has 20 or more ways of exiting, often not safely when an exception is thrown.

 

More idiomatic, best-practices C++ code which relies on proven patterns and facilities like smart pointers, standard containers and standard algorithms is both safer and more productive, but for some reason -- sometimes technical reasons, other times cultural ones -- C++ users are in practice somewhat resistant it seems. Its an additional learning curve that many people percieve as being "outside" the necessities of the language itself -- perhaps because the learning curve of the lange is itself so large. Languages like C# or Java, I think, will always be ahead on the productivity and safety curve, owing first to a shorter legacy, a smaller and more-homogenous language, and the conveniences and safety buffers that their runtime environments supply -- which is a bit like bowling in the bumper lane.

Share this post


Link to post
Share on other sites
Advertisement

 

I'm a fan of C++ but I think that for production Java and OpenGL will lead for compatibility/readability advantages of both.

 

... Says the absolute dearth of Java / OpenGL games rolleyes.gif besides that, I have to question the sanity of anyone who believes that Java or OpenGL is more compatible or readable than alternatives in practical terms, despite promises of the contrary. The readability of both is perhaps a matter of taste, though.

 

For the kinds of things that C++ is really good at there really is no viable replacement--maybe D someday, or Rust, but certainly not any kind of Java or C#-like productivity language. The trouble with C++, really, even moreso than C, are the number of potholes you'll encounter on a daily basis. I think this stems mostly from the fact that so many subtleties are afoot that almost no piece of code does precisely what it appears to do, and any piece of code that does perform its purported function precisely probably bears only a passing resemblance--at least, with the way most people write C++. For example, probably any 10-20 line function of C++ that does anything at all non-trivial and which compiles with exceptions enabled probably has 20 or more ways of exiting, often not safely when an exception is thrown.

 

More idiomatic, best-practices C++ code which relies on proven patterns and facilities like smart pointers, standard containers and standard algorithms is both safer and more productive, but for some reason -- sometimes technical reasons, other times cultural ones -- C++ users are in practice somewhat resistant it seems. Its an additional learning curve that many people percieve as being "outside" the necessities of the language itself -- perhaps because the learning curve of the lange is itself so large. Languages like C# or Java, I think, will always be ahead on the productivity and safety curve, owing first to a shorter legacy, a smaller and more-homogenous language, and the conveniences and safety buffers that their runtime environments supply -- which is a bit like bowling in the bumper lane.

 

 

People don't use C++ because it's HARD and takes TIME to learn. By learn I mean, everything. When you are ready to C++ you read a Game Programming Gems book WITHOUT A SINGLE DUBT.

Share this post


Link to post
Share on other sites

I think equating managed languages to "bowling in the bumper lane" is misguided and demeaning. I'd say it's more like driving an automatic vs manual car. Which do you drive and why?

Share this post


Link to post
Share on other sites

That's the trouble with analogies -- they can mean exactly the same thing or slightly different things simultaneously to different people with different perspectives. I doubt if my bowling analogy means anything different than your car analogy at any less than a stretch.

 

The point is that productivity languages, and I'd say Java in particular, subscribes to a particular orthodoxy of software development that's meant to protect the programmer from themselves in many respects. Common examples would include garbage collection, Java-specific examples would include things like the lack of operator overloads. The language designers and run-time implementers have decided in various ways that they know what's best for the sanity and productivity of you and your fellow programmers, and outright prevent or make difficult particular usage that they feel is more harm than good.

 

That's a perfectly valid design constraint if the ends justify the means -- indeed C# and Java are perfectly productive and safe(r) for the paycheck-programmer who really just wants to make things work and go home at 5pm without a care for memory management, intricate exception-safety guarantees, or being fully ISO-C++ compliant. C and C++ take the stance that the programmer is infalible, and means to do precisely whatever hare-brained thing it is that they insist on doing. C++ never tries to tell you its a bad idea, that your operating system will disallow it, or that your hardware is going to balk, it allows you to cast away even the minimal safety checks it does enforce. The thing is that sometimes you really do want to do those seemingly hare-brained things -- like writing your own memory manager, spitting CPU instructions into a memory buffer and then executing it on-the-fly, or transforming an object from one type to another by overwriting its v-table pointer. C# or Java will never completely replace C++ because they necessarily disallow such deep magic, and why other systems languages like D or Rust at least have the capacity to replace C++ if neither the momentum nor the pedigree.

 

So whether all of that is more akin to bowling with bumpers or driving automatic is really neither here nor there, and I doubt if anyone would care to make a further argument in support of one or the other smile.png

Share this post


Link to post
Share on other sites

For the record: C# is not as similar to Java as a C++ programmer who didn't use both might think. When you have used both Java and C# at depth, it becomes extremely clear Java is an older language. More verbose, less expressive, and ultimately less productive. Of course, if you need to use the JVM you can solve that by using other languages than Java.

 

As for the person who said C# is nothing without .NET and that you might as well use VB.net - you are partially right, but honestly programmers with a C++ or Java background are likely to prefer C# simply due to the familiar syntax.

 

When it comes to C++ vs C# being compared to manual vs automatic gearing, I could add my own analogy: C++ is like a car you constantly need to pull over to fix something that just broke down. Or when you're building one, none of the parts delivered really fit together without having to be manually machined further. The C# car is a modern mass produced car that works for 20 years with minimal maintenance.

 

Again, I don't dislike C++ - it was the 2nd language I learnt after VB in my youth! I just feel sorry for people who choose C++ for applications for which it is not the best choice, and this includes most gameplay code.

Edited by StubbornDuck

Share this post


Link to post
Share on other sites

I'm a fan of C++ but I think that for production Java and OpenGL will lead for compatibility/readability advantages of both.

I think that for production Java is already a joke for game development as evidenced by the rather miniscule amount of game dev related libraries for the platform, not to mention ones kept up to date.

You have LWJGL, that's about it. C# is already beating Java in every way possible just with XNA/Monogame. There hasn't been any reason to use Java for a long time, originally it was used for web embedding but that turned out to be one of the biggest nightmares of all, and it has basically been completely obliterated by flash. Without that selling point it just doesn't offer anything to gamedev that another language doesn't do /better/ with the exception of naturally built in cross platform ability. But Mono gives that to C# pretty easily, that's if you're even interested in developing for something besides Windows.

I would say C# is definitely a lot more "fun" to use than C++, it's definitely a lot less hassle, but it has tradeoffs of course. It's good enough for most games but a company trying to bring out the next generation of graphics or something will probably fall back to the dinosaur C++ is and ride it through town smashing down walls C# gets stuck at potentially. Edited by Satharis

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!