The programming language/paradigm debate

[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.

[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]

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.

[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

[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.

[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.

[Icemage]

Re: XB1 3 Million Units Sold

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.

I think you're being unfair here. Have you ever worked on a large project with many coders? OOP is the tool you use to keep the cats herded. Otherwise you have a dozen different flavors of function happening in the codebase, with each team member only conversant in a fraction of it.

If you're just working on a project with one or two programmers, absolutely OOP is a waste of time and energy unless you're one of those people that likes to normally produce spaghetti code (because structured but inefficient code is still preferable to completely disorganized code).


Icemage

[Armando]

Re: XB1 3 Million Units Sold

I think you're being unfair here. Have you ever worked on a large project with many coders? OOP is the tool you use to keep the cats herded. Otherwise you have a dozen different flavors of function happening in the codebase, with each team member only conversant in a fraction of it.

If you're just working on a project with one or two programmers, absolutely OOP is a waste of time and energy unless you're one of those people that likes to normally produce spaghetti code (because structured but inefficient code is still preferable to completely disorganized code).

I think we might be misunderstanding each other. I'm not advocating not using abstractions. I know you need abstraction. What I'm saying is that merely shoving variables into classes isn't enough. In the codebase where I work I've seen megaclasses that do too much. I've seen super deep inheritance trees that people keep extending because they need to use the variables in the base classes - they're essentially treating it as a bag of globals. I've seen objects that'll blow up when you call method Z unless you called X and Y in the right order. I've seen subclasses that aren't substitutable for their parent class. I've seen the same 3 or 4 parameters being used in multiple methods across multiple classes, and no one thinks to bundle them up into an object. If there's a way to make the code brittle or tightly coupled, they've found it. I'm sure you've seen similar things.

The best OOP code is functional in nature. Side effects are kept to a minimum, immutability is preferred over mutability, null is forbidden, inheritance is used sparingly and carefully, classes and functions are kept small and do only one thing well. But even if you use an OOP language like Java or C# in a functional style and avoid most of the OOP problems, you've still deprived yourself of many of the useful features of functional languages like: currying; sum types (tagged unions); product types (tuples); pattern matching; type inference; tail call elimination; and persistent data structures.

[Icemage]

Re: XB1 3 Million Units Sold

I think we might be misunderstanding each other. I'm not advocating not using abstractions. I know you need abstraction. What I'm saying is that merely shoving variables into classes isn't enough. In the codebase where I work I've seen megaclasses that do too much. I've seen super deep inheritance trees that people keep extending because they need to use the variables in the base classes - they're essentially treating it as a bag of globals. I've seen objects that'll blow up when you call method Z unless you called X and Y in the right order. I've seen subclasses that aren't substitutable for their parent class. I've seen the same 3 or 4 parameters being used in multiple methods across multiple classes, and no one thinks to bundle them up into an object. If there's a way to make the code brittle or tightly coupled, they've found it. I'm sure you've seen similar things.

Yeah, one of the weaknesses of OOP is that it's totally possible to overload a class or function. But I would offer the counterpoint that any programmers dumb enough to make those sorts of mistakes would be making equally stupid mistakes using standalone functions, irrespective of what language is in use; stupid is stupid is stupid, and just because someone knows how to write a Hello World in a programming language doesn't make them not stupid.

The best OOP code is functional in nature. Side effects are kept to a minimum, immutability is preferred over mutability, null is forbidden, inheritance is used sparingly and carefully, classes and functions are kept small and do only one thing well. But even if you use an OOP language like Java or C# in a functional style and avoid most of the OOP problems, you've still deprived yourself of many of the useful features of functional languages like: currying; sum types (tagged unions); product types (tuples); pattern matching; type inference; tail call elimination; and persistent data structures.

I don't see a basis for prejudice here. Every language has its strengths and weaknesses. C-family (Ansi C, C++, C#, etc.) are valued because they can be drilled down to very low level code when things need to be micromanaged, but at the cost of verbosity and a risk of instability if the code is not written properly. Java's strength is portability, stability and brevity of code, at the cost of computational speed on non-dedicated architectures.

Not every project calls for the same features, and the challenge is always to find the environment that plays well with the rest of your production flow while giving you the best match of feature sets.

Within the context of console and PC game programming, your only real choices are C variants and (maaaaybe) some of the more recent Delphi/Pascal derivatives. The rest of the programming languages available simply do not have the extended feature sets and computational flexibility to get the performance that most games need without bolting on a ton of extra stuff.


Icemage

[Armando]

Re: XB1 3 Million Units Sold

But I would offer the counterpoint that any programmers dumb enough to make those sorts of mistakes would be making equally stupid mistakes using standalone functions, irrespective of what language is in use; stupid is stupid is stupid, and just because someone knows how to write a Hello World in a programming language doesn't make them not stupid.

This is where I disagree. Part of the problem is that OOP languages encourage some of these behaviours, either by convention or by omission of alternatives. Functional programming languages default to immutable variables and persistent data structures and forbid null, reducing one common source of mistakes (mutable state) and eliminating another (NullPointerExceptions). The ability to easily pass functions as arguments keep people from using inheritance as a crutch for passing functions around, or hacky workarounds like the "Strategy Pattern".

Within the context of console and PC game programming, your only real choices are C variants and (maaaaybe) some of the more recent Delphi/Pascal derivatives. The rest of the programming languages available simply do not have the extended feature sets and computational flexibility to get the performance that most games need without bolting on a ton of extra stuff.

Even within C variants, we can do much better than C++ - for example, D. Outside the C family, functional languages have a superset of the features you'd find in C-like languages. There's not much of value you can do in Java or C# that couldn't be easily done in Scala or F#, but the reverse doesn't hold. If you wanted a functional language that compiles down to native code, there's Standard ML, OCaml and Haskell. Any sane language has a way to interoperate with C code anyways, so if you really need to get your hands dirty, you can still optimize that 10% of code that matters in C/C++ and build the rest of your application in a better language.

[Icemage]

Re: XB1 3 Million Units Sold

This is where I disagree. Part of the problem is that OOP languages encourage some of these behaviours

Sure, but that's why you have things like Best Practices to keep you from being a chump. I'm all for more explicit code and abolition of Nulls, but the truth of the matter is that we don't always get to design systems from the ground up. I've got clients who are working with backlogs of historical data and fields that are filled with Null references for various and sundry things, and tearing those out just to satisfy my OCD is simply not a cost-effective use of my time.

There's also the obscurity factor that comes into play; it's laughably easy to find a C or Java programmer, even a good one. It's harder to find a Delphi or PHP programmer who knows what they're doing. Everything else is really niche stuff and becomes a serious hiring problem for code maintainability (but can be used as a job security thing if you're one of those clowns that likes to blackmail their employers with obscure stuff that only a small fraction of potential employees would even recognize, let alone know how to maintain or update).

Even within C variants, we can do much better than C++ - for example, D. Outside the C family, functional languages have a superset of the features you'd find in C-like languages. There's not much of value you can do in Java or C# that couldn't be easily done in Scala or F#, but the reverse doesn't hold. If you wanted a functional language that compiles down to native code, there's Standard ML, OCaml and Haskell. Any sane language has a way to interoperate with C code anyways, so if you really need to get your hands dirty, you can still optimize that 10% of code that matters in C/C++ and build the rest of your application in a better language.

See above.


Icemage

[Armando]

Re: XB1 3 Million Units Sold

See above.

I agree, and those are completely legitimate business decisions. That's what I meant when I said what keeps C++ and OOP in use is inertia.

What I was trying to get at earlier is that indies can go off the beaten path and show that these newer languages and programming paradigms are viable, which is what eventually breaks the bigger companies out of the vicious cycle of "no one is using it so we won't use it" cycle.

[Icemage]

Re: XB1 3 Million Units Sold

I agree, and those are completely legitimate business decisions. That's what I meant when I said what keeps C++ and OOP in use is inertia.

That is a gross, gross oversimplification of the situation. C++ is an acceptable lingua franca that everyone puts up with because the alternative would be fragmenting the available efforts into producing toolchains.

For a real world equivalent, a large portion of the world conducts trade in English because it has the most comprehensive and easily-referenced vocabulary of all living languages.

What I was trying to get at earlier is that indies can go off the beaten path and show that these newer languages and programming paradigms are viable, which is what eventually breaks the bigger companies out of the vicious cycle of "no one is using it so we won't use it" cycle.

Disagree.

While you can indeed have software developed in other languages, fragmenting the market so that you have many languages in common use instead of a handful makes the task of trying to find competent staff more difficult, not less, and makes no more sense than having all your management staff speak different languages internally in a multinational corporation.

Indies by their nature don't answer to anyone and don't have to use the common toolchains, but the vast majority do because using a different language rarely comes with enough efficiency benefits to offset losing the library of available code already constructed for the most dominant languages. By the same token, such applications by themselves cannot change the balance of power because such code is rarely published to the public or even commercial domain, and even if it were, splitting the effort amongst different environments would result in no centralized repository of improving tools.

Why do you think Linux and MacOS haven't gained much traction for gaming? It's because for the longest time, hardware manufacturers rarely published drivers for them, and even then you have to do a lot of wheel reinvention to do even the most basic things that are taken for granted on other platforms, and the performance gains just weren't generally worth it to address a small slice of the available market. By the same token, there haven't been any languages that have come down the pipeline that offer enough improvement in workflow to convince much of anyone to switch.


Icemage

[Caspian]

Re: XB1 3 Million Units Sold

I'm not sure there's ever been a better example of a "nerd argument". This needs to be saved for posterity.

[Malacite]

Re: XB1 3 Million Units Sold

What? No.

"Nerd arguments" are over stupid crap, i.e. Captain Kirk vs Picard. They're having a technical debate over programming science.