Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: If C++ is so bad, what should game developers use?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 127 posts

Re: Ask HN: If C++ is so bad, what should game developers use?

#21

Post by thras »

derefr wrote: post #12
thras wrote: post #9

I'm with you. Whatever you use, don't choose C++. Sure, everyone on your programming team knows C++ already. Yeah, your libraries are all written in it. And successful games have used it again and again. But if it's not one of the "cool" languages, you shouldn't be using it. Modern game developers should code in Ruby/Lisp. By the time you've finished coding all of your graphics libraries from scratch, Moore's law wil…

Wait, so why can't you use the C++ libraries from Ruby/Lisp?

I think that best thing to do is look at 1) the libraries you'll be using, 2) what your team is proficient at, 3) what's worked for other groups, 4) optimization potential.

If you think that Ruby/Lisp is your answer to the above points, go for it. But I have the feeling that it won't be for many people.

Re: Ask HN: If C++ is so bad, what should game developers use?

#22

Post by olliesaunders »

Fargren wrote: post #14
olliesaunders wrote: post #8

Earlier quoted context omitted.

Why is Haskell a bad idea?

Well, for once, it's not particulary fast, but that's not a concern for all games(it's not slow either, but it's quite hard to optimize). The real deal is that it's a completely functional language with not much support, as far as games go. You won't find any graphics libraries, so you'll have to make them from scratch. Unless you have been programing in funcitonal languages for a long time, this will take an absurd…

Functional languages are good at math. Graphics involves a lot of math.

Re: Ask HN: If C++ is so bad, what should game developers use?

#24

Post by thras »

derefr wrote: post #10
ComputerGuru wrote: post #6

Don't let them scare you away... C++ is fine if you use what you need and take the time to actually understand the tools you're using.

Why is C++ suddenly "fine" when you have no other options? There could easily be a language with all the close-to-the-metal advantages and none of the baroque, redundant complexity of C++; why must we be content to use the same language as everyone else in the industry, rather that scratching this itch and building a newer, more productive one?

A lot of that "baroque, redundant complexity" comes from standards committee's refusal to make things easier on programmers at the cost of any smidgen of performance.

And for certain tasks, like the highly competitive video game industry, uncompromising performance is exactly what the doctor ordered. You can always hire smarter programmers if you have to. On the other hand, it's hard to sell a game that runs or looks like crap at 60 fps.

Re: Ask HN: If C++ is so bad, what should game developers use?

#25

Post by derefr »

thras wrote: post #21
derefr wrote: post #12

Earlier quoted context omitted.

Wait, so why can't you use the C++ libraries from Ruby/Lisp?

I think that best thing to do is look at 1) the libraries you'll be using, 2) what your team is proficient at, 3) what's worked for other groups, 4) optimization potential. If you think that Ruby/Lisp is your answer to the above points, go for it. But I have the feeling that it won't be for many people.

I didn't say I wanted to use Ruby or Lisp--I was simply denying the parent's point that one would have to "write the graphics libraries from scratch."

Besides, isn't the advice for optimizing every other kind of project:

1. Start in a high-level language

2. Port any bits that profile as slow to a low-level language, and then interface them into your HLL code

Why, all of the sudden, when you're coding a game, is it a better idea to start in the low-level language? Because your team "knows it?" by that argument, all games would still be being developed in assembler, because the most senior members of the team would have more experience with that than any new-fangled language like C++.

Re: Ask HN: If C++ is so bad, what should game developers use?

#26

Post by miloshh »

You're right, C++ pretty much has no serious alternatives for games. And not just games, anything that involves computer graphics, physical simulation, computer vision or image processing.

Python is excellent if some good soul has already written a library that does exactly what you need (in C or C++, obviously). The combination of numpy+PyOpenGL+PyCUDA is great for certain kinds of research projects (I have written a volume renderer in it) but probably far from commercial usability.

Haskell has great potential, but the community is too small and too academic to produce the necessary libraries and tools (which is a lot of work with minimal scientific content). The key problem is the absence of an industrial-strength array facility - there are many kinds of arrays in Haskell, all somewhat clunky and incomplete.

D might be a contender, but last time I looked the tools seemed very basic and it did not even support 64-bit systems.

Re: Ask HN: If C++ is so bad, what should game developers use?

#27

Post by derefr »

eli wrote: post #15
derefr wrote: post #10

Earlier quoted context omitted.

Why is C++ suddenly "fine" when you have no other options? There could easily be a language with all the close-to-the-metal advantages and none of the baroque, redundant complexity of C++; why must we be content to use the same language as everyone else in the industry, rather that scratching this itch and building a newer, more productive one?

"Newer" isn't necessarily better or more productive. Especially given the monumental task of having to write a game without the benefit of any of the libraries developed over the past few decades. Perhaps the reason there are no other viable options is because C++ is pretty well suited to the task?

Why would you have to lose the libraries? .so files are .so files; it doesn't matter what language they were written in, as long as they expose an API that can be cleanly wrapped by your own language.

Re: Ask HN: If C++ is so bad, what should game developers use?

#28

Post by jacquesm »

thras wrote: post #21
derefr wrote: post #12

Earlier quoted context omitted.

Wait, so why can't you use the C++ libraries from Ruby/Lisp?

I think that best thing to do is look at 1) the libraries you'll be using, 2) what your team is proficient at, 3) what's worked for other groups, 4) optimization potential. If you think that Ruby/Lisp is your answer to the above points, go for it. But I have the feeling that it won't be for many people.

There's a role for lisp (and prolog) in gaming, but not on the outside.

As an embedded core to sort out a bunch of logic they definitely have their place.

Re: Ask HN: If C++ is so bad, what should game developers use?

#29

Post by gaius »

Fargren wrote: post #14
olliesaunders wrote: post #8

Earlier quoted context omitted.

Why is Haskell a bad idea?

Well, for once, it's not particulary fast, but that's not a concern for all games(it's not slow either, but it's quite hard to optimize). The real deal is that it's a completely functional language with not much support, as far as games go. You won't find any graphics libraries, so you'll have to make them from scratch. Unless you have been programing in funcitonal languages for a long time, this will take an absurd…

You won't find any graphics libraries, so you'll have to make them from scratch

Haskell has OpenGL bindings: http://www.haskell.org/haskellwiki/Opengl

So does OCaml: http://glcaml.sourceforge.net/

Re: Ask HN: If C++ is so bad, what should game developers use?

#30

Post by timr »

If you let the language trolls on proggit and HN convince you that you must avoid C++ -- particularly whatever 'subset' of C++ scratches your itch with minimal complexity -- you've made a classic pointy haired boss mistake: letting the whims of the crowd make a technical decision for your project.

Don't buy into the nonsense. C++ is a fine language. People have been using it for decades to do real work, and they probably still will be in another two decades, long after Ruby and Haskell and Blub have been discarded as 'archaic' by the next generation of 20-year-old language snobs.

Post reply on HN