The programming language/paradigm debate

[Armando]

Re: The programming language/paradigm debate

Unity uses JavaScript, C#, or Boo. Hardly mold-breaking.

My point isn't that they're mold-breaking. It's natural that they're not, since most people come from an OOP background. The point is that clearly there's a demand for a language that's not C++ among indie developers, and clearly some people are trying to meet that need, so I think it's unfair to deny that indies try out alternative languages or frameworks. Especially when the move from manual memory management to garbage collection is probably the biggest step forward the software industry has made in the last two decades.

All of the C derivatives are bad for productivity, up to and including C#. Java is horribad slow under most architectures, but develops and iterates quickly, so can be useful for productivity.

This is kind of tangential but I'm curious why you consider Java good for productivity and not C#. C# is essentially a Java clone that picked up new features faster than Java. Java doesn't even have higher-order functions. I'm also fairly sure Java (and C#) haven't been slow for quite a while, provided the application's had some time to "warm up" and let the JIT compiler kick in, but then "slow" is relative.

I haven't looked at F# since its early inception but a quick glance at the more modern implementation still shows things about it that I don't like; it uses inferred typing at compiler time, which in my opinion causes far more bad habits than any amount of OOP overloading.

What bad habits?

Type inference is borderline necessary if you want higher-order functions to be easy to use. Besides, the bureaucracy of type annotations is probably the main reason people like dynamically unityped languages like Python or Ruby. If so many people are willing to cripple themselves with dynamic typing, clearly they think mandatory type annotations everywhere is overkill. You can include the types of variables if you want to, and everything is perfectly type safe even if you don't.

If you're willing to gloss over OOP's multiple shortcomings because you have Best Practices and Coding Standards, I don't see why you'd hold type inference against F# - especially since documenting your code is mandatory everywhere regardless of language. In the very worst case, the IDE still knows the types.

Interoperability is not the same thing as homogeneous code. The more frames of mind you have to be in to follow a process, the more likely a mistake will be made. I am not a particular fan of building pieces of an application under different paradigms; it increases code complexity and maintenance overhead. While there are specific use cases where this can be beneficial because some languages are just bloody awful at some operations (virtually all C variants when working with string data, for instance), it's not something I would ever advocate for an application designed to be a lasting tool.

That's all true, but the transition to a new technology or paradigm will pretty much always be uncomfortable. You can't ask for much more than good backwards compatibility. Somebody's gotta take the plunge somewhere, or we'd all still be coding in C.

[Icemage]

Re: XB1 3 Million Units Sold

I don't know. Unity 3D is fairly popular among indies, and that's not C++.

Unity uses JavaScript, C#, or Boo. Hardly mold-breaking.

I don't think it's a coincidence that the last super big shift in the software industry was to jump from C++ to Java and C#, both of which were backed by large corporations with a lot of marketing money to throw around. Languages and technologies get chosen more because of marketing and not being too different from what people are already using than because of their technical merits. Java is a really mediocre language, unless your only point of comparison is C++. If it was a matter of productivity, then more people would be using F# over C#. Or perhaps OCaml, which is what F# is a dialect of.

All of the C derivatives are bad for productivity, up to and including C#. Java is horribad slow under most architectures, but develops and iterates quickly, so can be useful for productivity.

I haven't looked at F# since its early inception but a quick glance at the more modern implementation still shows things about it that I don't like; it uses inferred typing at compiler time, which in my opinion causes far more bad habits than any amount of OOP overloading.

It's not like you have to give up all the libraries and frameworks and even legacy code to switch to another language. F# interoperates with other .NET languages and Scala interoperates with Java.

Interoperability is not the same thing as homogeneous code. The more frames of mind you have to be in to follow a process, the more likely a mistake will be made. I am not a particular fan of building pieces of an application under different paradigms; it increases code complexity and maintenance overhead. While there are specific use cases where this can be beneficial because some languages are just bloody awful at some operations (virtually all C variants when working with string data, for instance), it's not something I would ever advocate for an application designed to be a lasting tool.


Icemage

[Armando]

Re: XB1 3 Million Units Sold

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.

I don't know. Unity 3D is fairly popular among indies, and that's not C++.

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.

I don't think it's a coincidence that the last super big shift in the software industry was to jump from C++ to Java and C#, both of which were backed by large corporations with a lot of marketing money to throw around. Languages and technologies get chosen more because of marketing and not being too different from what people are already using than because of their technical merits. Java is a really mediocre language, unless your only point of comparison is C++. If it was a matter of productivity, then more people would be using F# over C#. Or perhaps OCaml, which is what F# is a dialect of.

It's not like you have to give up all the libraries and frameworks and even legacy code to switch to another language. F# interoperates with other .NET languages and Scala interoperates with Java.

[cidbahamut]

Re: XB1 3 Million Units Sold

I'm kind of upset with myself for not being able to keep up with it. That's what I get for getting a non-programming job and letting my knowledge atrophy I suppose.

[Caspian]

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.

See I always thought that was "geek argument".

[Firewind]

Re: XB1 3 Million Units Sold

Picard over Kirk

Original Series over TNG

/thread

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

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

[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

[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

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

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

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

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

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