The programming language/paradigm debate

[Armando]

Re: XB1 3 Million Units Sold

C++ is an ugly workhorse language--the key insight is that it works.

So did C and assembly.

except maybe persistent data structure--I can't recall anything I worked on in the past year where that feature could be critical

They're referentially transparent, which means you don't have to worry about aliasing and can reason about the correctness of your code far more easily. But besides that they also come in handy any time you need parallelism (because they're immutable) or any kind of backtracking/undo (because you don't lose the previous states).

I often deal with a BASIC variant that doesn't even support function calls. Yet, as primitive as that is, it gets the job done.

But you'd never argue it's a good idea. And I think that's the part that rubs me the wrong way about OOP - it's a bad idea that we still use primarily because of inertia, and we sell it like it's a smart thing to do. I don't expect it to go away for a couple of decades, but I'd like it if we could at least be honest about the real reasons we use it.

People who can't break down a problem and properly structure a solution will produce garbage, whatever language they use.

"Bad coders can write bad code in any language" is a tautology. The interesting observation is that bad languages limit the way good coders can break down and structure a solution - because they lack certain kinds of "glue" to build up the solution with (e.g. function calls in that BASIC variant.) For instance, if I use a dynamically typed unityped language, I'll never be able to express "the argument to this function must be an integer" in the code.

[ItazuraNhomango]

Re: XB1 3 Million Units Sold

Think I'll skip most of the detailed, point by point response, and say this: C++ is an ugly workhorse language--the key insight is that it works.

I agree with every problem you pointed out (except maybe persistent data structure--I can't recall anything I worked on in the past year where that feature could be critical), but think you've made overly much of them. I often deal with a BASIC variant that doesn't even support function calls. Yet, as primitive as that is, it gets the job done.

While the language choice is non-trivial, the design skill dominates when the system gets larger. People who can't break down a problem and properly structure a solution will produce garbage, whatever language they use.

[Icemage]

Re: XB1 3 Million Units Sold

I'm an old-school programmer who can do either functional or OOP. I much prefer functional over OOP, especially for smaller projects that need to be heavily iterated on.

For really big projects with many cooks in the kitchen, though, OOP is the only sane choice.


Icemage

[Armando]

Re: XB1 3 Million Units Sold

Um... C++ isn't that bad. It's not my favorite language (anymore), but it supports near-bare-metal level of access as well as object orientated programming and generic programming. (Not to mention having decades of solid library development, and decades more if counting C libraries.)

C++ gives you so many ways to accidentally write a program that has no meaning that it's ridiculous (these days) to build an entire application on top of it. On top of that, manual memory management precludes any kind of persistent data structure and will perform worse than garbage collection in the general case. Sure, to get the very best performance you might need to do some low-level wizardry in a very small percentage of your code, but a sane language would require you to opt into something that could fail so spectacularly if you get it wrong. It's also a very complicated language in general, despite not doing all that much for you.

As for OOP, sure, it's a big step forward from procedural programming, and it emphasizes encapsulation, but that's about all it's got going for it. OOP languages emphasize objects, but they're only one of two complementary ways of abstracting data. They also encourage heavy use of inheritance, ostensibly for code reuse, but that's a bad idea more often than not - see The Fragile Base Class Problem. Then you've got null, a.k.a. Tony Hoare's billion-dollar mistake. The lack of sum types, tuples, pattern-matching, poor or non-existent support for high-order functions and type inference, and over-emphasis on mutable variables are also very problematic. OOP has good intentions but it's too flawed.

Functional programming is a far more sane paradigm. I realize no one in the industry does it; it's a chicken-and-egg problem. No one does it because no one does it.

[ItazuraNhomango]

The programming language/paradign debate

On top of that, the state of the art still involves using an antiquated and tragically flawed programming language (C++) and a very misunderstood and problematic programming style (object-oriented).

Um... C++ isn't that bad. It's not my favorite language (anymore), but it supports near-bare-metal level of access as well as object orientated programming and generic programming. (Not to mention having decades of solid library development, and decades more if counting C libraries.)

Object orientated programming paradigm, by the way, is more or less the foundation of modern software programming. (Yes, OOP is a GOOD thing.)

I don't work in a game shop, but I do work in a ~10 person software group. Let's just say that no one in the group would oppose hiring a programmer who programs in C++, but no one would support hiring anyone without object orientated programming experience. C++ is useful, OOP is essential.

[Armando]

NOTE: This thread started as a derail of XB1 3 Million Units Sold

It seems we're still struggling with the problem of how to pass on the skills it takes to create a good game.

Which is exactly why it's silly to be against the low barrier to entry for indie development. From what I've read - and hopefully someone else can chime in here - a very large portion of the professional game development is toxic - incredibly unhealthy work/life ratios, high turnover rates, and lower wages/benefits than being an average enterprisey software developer. They have a huge pool of young, unmarried people they can chew up and spit out over a short time span. With a process like that, a relatively low number of people last long enough to become experts. On top of that, the state of the art still involves using an antiquated and tragically flawed programming language (C++) and a very misunderstood and problematic programming style (object-oriented).

Letting anyone with a computer try to make a game may produce a lot of garbage but hopefully we'll see some progress in game development techniques and pass them on quicker and to a wider audience than the industry currently can.