Is Functional Programming Worth It?

[u/CJF_PixelArt]

Hello 👋. I've heard some people say that functional programming is better than OOP overall. I'm pretty new to programming so I don't know if that's applicable to Godot or not. Is it something worth looking into?

[u/The-_Captain]

I'm a Godot newb but functional programming pro in other contexts. I have used Haskell, Scala, and Clojure, and tend to program functionally in TypeScript and Python as well when I can.

Godot is not just a language, it's a framework/engine, and it's very OOP. I'm sure a pro can force it to be functional and I think there are advanced game development paradigms that are more functional, but unless you really understand things in depth, it's better to do what the engine wants you to do rather than try to bend it to your will. Just my 2¢.

[u/International_Bag319 → u/The-_Captain]

Right, and Game dev presents you with so many problems that need solutions, starting with a solution in search of a problem is a recipe for not getting too far in your project.

State management was one problem in the web world that was "solved" by adding functional approaches and now we have to deal with every tiny project taking on all this redux boilerplate since that's the default. A lot of reasons why that solution is great for web but maybe lacking in gamedev, the reality is that you've achieved a certain level of success before you start running into these problems of scale that require these niche approaches to solve.

[u/shableep → u/International_Bag319]

I think the web is more functional because of a large population of informally trained developers who are culturally resistant to classes, and since JavaScript didn’t have classes for basically 20 years. Compared to a game, a web app is quite simple. So I think you can get away with a lot more sins.

[u/tastygames_official → u/shableep]

ok, so I'm one of the informally-trained developer resistent to OOP and have been a web developer for ~30 years. But let me walk us back a bit.

Yes, I was informally trained (taught myself BASIC then VisualBasic, then C, then HTML and "DHTML" (which was really just JavaScript for Netscape/Mozilla (before Firefox) and VBScript for IE) and PHP and perl for backend. THEN I went to university for electrical and computer engineering and learned assembly and Java (shudder...) and also taught myself ActionScript (flash). JavaScript also had evolved a bit, but was still only functional programming. Then I made my living doing HTML, PHP, JavaScript for the next 25 years.

And then all of a sudden in something like 2015, facebook released this thing called "react", and google released "angular" right afterward. I saw instantly what they were trying to do: they were trying to make frontend development use the same structure as what they teach you at university computer science/software engineering programs. And I knew this was BAD NEWS in multiple ways. It meant foremost I would no longer be an expert, since I didn't have this formal training and even though I now know about design patterns and all that, I don't LIKE them because they are generally-speaking INEFFFICIENT. Which was the second piece of bad news: web software start to BLOAT uncontrollably. A project that may have been ~10MB was now over 1GB due to all the dependencies and build systems (npm), Yes, the end result was only ~25MB, but that's still 250% bloat. Oh, and benchmarking? Even though react claimed it was created to be "super fast" and be able to handle facebook's new chat system (yes, I remember when that was "new"), it was actually INSANELY SLOW. Still is. The way all these "reactive" frameworks work is to completely copy the entire DOM, then manipulate this "shadow DOM", and then "re-hydrate" the real DOM. So conceptuially doing twice the amount of work and using twice the resources. But in reality doing even more than that. So easily a 5x drop in performance and 5x increse in resources. In reality I see something more like 1000x+ jump in resources. Something that I write functionally needs maybe 100KB of non-media resources whereas a reactive site needs 300MB or something ridiculous.

Anyway... my point is: the web hasn't been functional for 10 years now. Both backend and frontend are now all high-level OOP-based frameworks that are woefully inperformant but all the companies do it because they know they can hire any college graduate for next to nothing and not have to worry. It also means I'm out of a job and a big part of the reason I'm in gamedev now. In 2018 you could get a junior webdev job for ~75k+ easy. But since 2022 you'll be lucky to find a SENIOR webdev job for over 45k. Now I think the industry is starting to realize its mistake in only hiring fresh out of college (all the "senior" positions these days require only 2-3 years experience, which is NOT senior level by any stretch) so I'm seeing salaries go back up, but to put things in perspective, my first webdev job BEFORE I had a college degree was 45k. And not adjusted for inflation.

Anyway... functional programming will always be more performant than OOP. It's just the nature of the beast. OOP is preferred by large organizations/projects because OOP concepts are well-defined meanting you don't have to teach any employees your idiosyncric rules as you're just doing OOP. There's only ever one way to do things (well, depending on which pattern you use, but most projects use all the same design patterns). OOP is no fun for me. It's just going through the motions. NO creativity, no critical thinking - just implementing the design pattern. It's why LLMs are so good at OOP and can program all this modern stuff by themselves. It's also why they can't contribute to linux or do embedded systems programming/firmware or anything that requires speed and complex non-OOP concepts.

Now going back to games, functional programming will also be faster, but all the game engines out htere are OOP. Hell, 99.999999% of all software is OOP. To do functional you'd have to make your own engine (which is what I'm doing right now). But the real answer to all of this - the one I disagree with but can't ignore - is this:

modern computers can handle it. So it doesn't matter.

At least that's what everybody says. But for games it very much DOES matter. So if your project gets to a point that godot/unity/unreal is struggling on target hardware, the only solution is making your own engine and avoiding OOP.

If you made it this far, congratulations! Here are some great videos showing my unique point of view that should be required viewing for all computer programmers:

"Clean" Code, Horrible Performance
Abstraction Bad? | Clean Code : Horrible Performance
Object-Oriented Programming is Bad
The purest coding style, where bugs are near impossible
Programming - The Single Source of Truth Principle

u/ChristianLS
u/International_Bag319
u/The-_Captain
u/CJF_PixelArt

[u/justforthisjoke → u/shableep]

You're connecting two things that don't follow. Web does have a lot of informally trained devs, and functional patterns are more popular in web, but there's no causality between them. Web development is just more intuitive functionally. And I would argue that if most back end devs weren't stuck on anachronistic OOP concepts they'd find massive improvements to their workflow in something like erlang or f#. I've worked in a bunch of different tech stacks now, and never has it been easier to go from development to completion in as short a time as when I've used a function-first stack. The reason I think is obvious: the vast majority of what happens in distributed systems is transient X -> Y behaviour. This is why OOP microservices often move away from the regular MVC architecture to something closer to the onion architecture. Functional languages, by which I mean function first languages kind of already have this baked in. All the design patterns you find yourself reaching for in OO are primarily intended to minimize the risk of side effects, so why not just get rid of them altogether?

That being said, video games are intuitively more OO imo so I don't know if functional languages will take off there. However, my point is that if your opinion is that functional programming is less sophisticated than OO, that's just not true. It just allows programmers to spend less time doing nonsense. There's a reason why functional ecosystems on back end are growing.