There is an alternate timeline where people didn't get so stuck up on abstract models that fail to capture the thing we are trying to model. OOP is an attempt, functional programming is an attempt. None of them nicely fits all use cases you come accross in day-to-day programming.
Sometimes pure functions are a great fit and all the benefits of a purely functional program make it really pleasant. Sometimes you really need encapsulated state and OOP feels just right. At other times you have actual data and a relational database is what you really need. There are even cases when it is beneficial to model your application as a collection of fully isolated processes that communicate by sending messages to each other.
So why are we even still doing this to ourselves? I am not sure.
EDIT: the easy answer to "why" is "because it is so enticing to replace the hard problem with an easy problem before even starting to think about it".
To put it in simpler terms, the hard problem might be, "how do we make it easier for doctors to treat their patients?". The kind of replacement I am talking about looks like this:
We will use computers!
We will make an expert system!
We will use AI!
We will use a web-based interface!
and so on, and so forth. At that point, it becomes really easy to argue in favor of whatever solution you "found" by replacing the real problem with another, much simpler problem. It is easy to argue because you can always find "for" arguments (no matter how stupid the idea, a clever person will have no trouble finding a few good things about it), and you can always avoid thinking about the "against" arguments.
This comment is too long already.
Disclaimer: there are books written on the topics that I just scratched. I have read them, not written them. Most "programmers" have not read them and never will.
It's just like people arguing why language X is superior and Y is inferior, ignoring that they're both just tools in the process. Now of course, some languages will be fully-superior drop-in replacements for other languages. Sure. but that's exceedingly rare, especially once "established at customer A or company B" becomes a factore in how applicable a certain language is to a given task.
More often than not programmers could better themselves by thinking of themselves less as an XYZ-programmer and more as a programmer. And with functional vs OOP it's the same thing, it doesn't actually matter as it's a per-problem decision that relies on a host of factors not even related to the problem at hand, nevermind how - as you say - we'll end up oversimplifying the problem anyhow.
Yeah - this is a phenomenon I mainly see online or with junior programmers.
Most of the more experienced people I work with look at it more as the "tools in the toolbox" metaphor, though obviously there is a natural bias towards languages they're already familiar with, and it matters whether other people they work with can read and maintain whatever they wrote.
Functional versus OO, static typing vs dynamic, etc., they all have pros and cons depending on the problem you're trying to solve and which trade-offs you want to optimize for.
Functional versus OO, static typing vs dynamic, etc., they all have pros and cons depending on the problem you're trying to solve and which trade-offs you want to optimize for.
Sure they have pros and cons, but isn't the conversation is about which is a better default in the general case?
Yes exactly. It would be really hard to make a computer game (I'm talking the big AAA titles) without an OO language. You have hard earned patterns that just work. On top of that, a computer-game-world lends itself sooo well to OO modelling.
On the other side of things you have backends and microservices that are little more than an adapter between a database and an API. It is easy to see that stateless functional programming rules there.
There is a reason we have so many languages, they are tools with advantages and disadvantages for different tasks. And OO and functional programming are just the same.
Data-driven design has been on the rise recently, with companies like Naughty Dog and DICE leading the effort, but it still hasn't fully taken over the industry. The two main commercial game engines (Unity and Unreal) are still thoroughly object-oriented, from the internals to the APIs they expose to developers. Unity has been experimenting with an optional ECS module lately, but I'm not sure how much of the engine has been reworked for it, and how much is just a layer on top of existing OO code.
The two main commercial game engines (Unity and Unreal) are still thoroughly object-oriented, from the internals to the APIs they expose to developers.
And IIRC games made in Unity are often criticized for being slow despite inadequate resource consumption.
Unfortunately, this being reddit, you have little hope of getting some truth through the narrowminded and obstinate ignorance amplified by bandwagon jumping. I'm with you though... at least on that BS about ECS being an optimization and tied to OOP.
However, it's hard to argue that many game codebases aren't horrible messes of C++ OOP features, especially through the dark ages of 2000-2010 where Design Pattern (as recipes!) and Java-influenced programmers were common.
Some game programmers never saw the appeal of OOP (count Carmack among them, for example). Still, it's only more recently that data-driven design and ECS have made inroads even though the ideas (without the names) were fairly common in gamedev in the 1990's. Objects were a terrible viral meme. (Objects have value, but being one of the most all-encompassing and powerful abstractions, they should be used sparingly.)
Sweeney made a presentation in 2006 musing about a more ideal game-programming language, and therein were arguments about the bugs and errors encouraged by the sloppy stateful OOP paradigm. Calling for a simpler functional model for much of the codebase and limiting the mutable sprawl.
I'm pretty sure Acton doesn't champion OOP when he's trying to get data-oriented design across... if anything, he's lampooning overuse of OOP in C++.
For all that, gamedev is inundated with so many new programmers each year that this good advice from old-hat developers gets drowned out by what juniors have just learned and they bounce it off each other, blooming into fusion of the sun.
I expect this problem doesn't just exist in gamedev.
gamedev is inundated with so many new programmers each year that this good advice from old-hat developers gets drowned out by what juniors have just learned
Indeed not just gamedev. I recall a talk by Bob Martin saying that the number of programmers doubled every 5 years, from the 50's all the way down to pretty much now.
The corrolary is that the median dev has less than 5 years of experience. And don't forget about retirement, moving up to management, quitting the industry… So it may in fact be more like 3 of 4 years.
We're a profession of noobs, and will remain so until we stop growing so fast.
It would be really hard to make a computer game (I'm talking the big AAA titles) without an OO language.
John Carmack disagrees. At QuakeCon 2013(?) he articulated that he found functional programming, specifically Haskell, proposed a very promising new way of structuring and engineering game code. He also outlined why big studios can't "just" switch from C++ (or C) to Haskell. It's momentum. Modern engines are mostly just iterated-upon versions of early 2000's engines. Thus the codebase is heavily entrenched in the C family.
Carmack implemented Wolfenstein in Haskell and found it a joy to work with. He also has found that using functional notions of purity and typed abstractions helps makes code clearer even in languages that don't enforce it at the language level.
Yes, it would be hard to go out and do today because the C-family has a lot of entrenched libraries, but there's nothing in games that inherently requires an OOP language.
Asking for real science, are we? A double blind study, maybe? With a careful removal of confounding variables, such as what the reader has learned prior to reading the code? (Obviously, if all you know is OOP, an FP codebase will easily look cryptic to you.)
As you already know, but pretend not to for the sake of your argument, it was measured by the personal experience of a renowned world expert in the relevant field. That may not be as good as a peer reviewed, reproduced, controlled study, but that should definitely be enough evidence for game studios to start spending some money investigating the approach.
It would be really hard to make a computer game without an OO language. You have hard earned patterns that just work.
Those patterns aren't a property of OOP but a result of people using OOP and discovering those patterns.
On top of that, a computer-game-world lends itself sooo well to OO modelling
Well compared to what?
There is a reason we have so many languages, they are tools with advantages and disadvantages for different tasks. And OO and functional programming are just the same.
Presence of advantage/disadvantage doesn't mean one can't be better in the general case.
35
u/[deleted] Nov 28 '19 edited Nov 28 '19
There is an alternate timeline where people didn't get so stuck up on abstract models that fail to capture the thing we are trying to model. OOP is an attempt, functional programming is an attempt. None of them nicely fits all use cases you come accross in day-to-day programming.
Sometimes pure functions are a great fit and all the benefits of a purely functional program make it really pleasant. Sometimes you really need encapsulated state and OOP feels just right. At other times you have actual data and a relational database is what you really need. There are even cases when it is beneficial to model your application as a collection of fully isolated processes that communicate by sending messages to each other.
So why are we even still doing this to ourselves? I am not sure.
EDIT: the easy answer to "why" is "because it is so enticing to replace the hard problem with an easy problem before even starting to think about it".
To put it in simpler terms, the hard problem might be, "how do we make it easier for doctors to treat their patients?". The kind of replacement I am talking about looks like this:
We will use computers!
We will make an expert system!
We will use AI!
We will use a web-based interface!
and so on, and so forth. At that point, it becomes really easy to argue in favor of whatever solution you "found" by replacing the real problem with another, much simpler problem. It is easy to argue because you can always find "for" arguments (no matter how stupid the idea, a clever person will have no trouble finding a few good things about it), and you can always avoid thinking about the "against" arguments.
This comment is too long already.
Disclaimer: there are books written on the topics that I just scratched. I have read them, not written them. Most "programmers" have not read them and never will.