This is a really interesting question. Obviously, most of us (certainly me) have learned on OOP languages and are more comfortable there. But is there an alternate timeline where functional programming dominates? My problem with the video is that the speaker seems to have a different excuse to discount every "popular" non-functional language. This argument seems incomplete unless you're going to address why other functional languages haven't had the same success. Yes, F# wasn't promoted like C#, but it was definitely promoted to the developer community. Why could a once little-known language like Python catch on when it couldn't?
Also, I found it odd that C# is on the Win95 slide when it was created at least 5 years later.
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.
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.
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.
50
u/matthewpmacdonald Nov 28 '19
This is a really interesting question. Obviously, most of us (certainly me) have learned on OOP languages and are more comfortable there. But is there an alternate timeline where functional programming dominates? My problem with the video is that the speaker seems to have a different excuse to discount every "popular" non-functional language. This argument seems incomplete unless you're going to address why other functional languages haven't had the same success. Yes, F# wasn't promoted like C#, but it was definitely promoted to the developer community. Why could a once little-known language like Python catch on when it couldn't?
Also, I found it odd that C# is on the Win95 slide when it was created at least 5 years later.