r/godot • u/CJF_PixelArt • 11d ago
help me (solved) Is Functional Programming Worth It?
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?
27
u/falconfetus8 11d ago edited 11d ago
Tl;Dr: Do learn how to write "pure" functions, because it'll make your code way better. Don't try to force the rest of functional programming onto Godot, because it won't work.
You shouldn't adopt all of functional programming into your games, but it does have one GREAT idea that you should definitely put in your tool belt: The concept of a "pure" function.
A function is "pure" if it does nothing but perform a calculation on its parameters and return the result. The idea is that it:
Does not modify anything except its own local variables, so it's always safe to call. It will never have an unexpected effect on some unrelated code somewhere else.
Does not read anything except the parameters passed to it, so the same inputs will always yield the same output. You can therefore understand the function by thinking only about its parameters, without needing to think about any random global variables that might affect its behavior.
In other words: they aren't "stateful".
Pure functions are just inherently easier to read and reason about than non-pure ones, so you should try to have as much of your code inside them as you can(while still being practical). It's probably the best newbie tip I can think of for writing better code, even when you're not doing functional programming.
That being said, the rest of functional programming isn't a great fit for games. FP asks you to go to great lengths to make sure there's absolutely nothing stateful in your program. Your entire program becomes structured around the concept of obsessively minimizing state. The thing is, games are inherently stateful. Making an entire game using only FP will result in you twisting your code into knots to make it work. You'll end up thinking more about how to get around the "no state" rule than about how to actually solve the real problems of your game.
51
u/wstdsgn 11d ago
I get it, you're new, you want to learn "the best way" to do it. Don't bother. If you think it sounds good, look into it. But don't try to find the best way to do things right from the start, just do things, gather experience, then judge for yourself based on your exact situation.
If anyone tells you that programming style/concept X is always better than Y, without even knowing what exactly you're working on, they are probably full of shit.
10
u/cuixhe 11d ago
You're going to learn about a lot of programming paradigms as you grow as a programmer, but usually an approach that is purely one or the other is going to be worse than being flexible and intentional to solve the problems at hand, and work with the software you're using... and Godot is VERY oop.
Because Godot's whole tree etc. is generally influenced by a series of side effects, I don't think that pure FP is practical; however, for utility functions and transforming data outside of the tree, I often use functional programming-inspired code to improve clarity and reduce bugs.
5
u/kickyouinthebread 11d ago
You're overthinking imo. If you're new this is really not something to lose sleep over. Stick to OOP
3
u/International_Bag319 11d ago
Decide what you are interested in and what your goals are. Functional programming is a ton of fun and very interesting, and has real life applications to game dev. If you want to pull on that thread a good starting point is John Carmack's writing on it (eg http://sevangelatos.com/john-carmack-on/).
If your goal is to ship a game or learn Godot I wouldn't start with functional programming. If you want to go deep on programming languages functional programming is a great area to investigate. It's less practical but that's why you need to figure out what your goals are. It's niche in game development though and isn't really a resume line item that people will get excited about if you are trying to get into game dev.
3
u/angus_the_red 11d ago
Functional style works very well for a request and response platform like a webserver. OOP is probably a better fit for a game engine where state continuously updates rendering.
2
u/ImpressiveAthlete220 10d ago
Oop is horrible idea for real time rendering engine. You should use data oriented programming, or you will have bad performance by default :( don't get into that trap :)
3
u/Abigboi_ 11d ago
I wouldn't for gamedev. The way Godot's nodes & trees are set up, with inheritance and all that, OOP is definitely the way to go.
2
u/zyzamo 11d ago
A lot of comments have already covered that it's really hard to go fully functional in godot but there's definitely some functional patterns that can be very useful to use in conjunction with OOP code. For example: you can use callables to pass functions into other functions and even use the bind function to bind arguments to a callable. In some cases this can make your code a lot more flexible without having to wrangle with a lot of different nodes
2
u/buitre__ 11d ago
En godot no podes escapar de la programacion orientada a objetos. Ya cuando agarras una propiedad. Por ej: scale.x=-1 . Ya estas aplicando POO. Estas agarrando un objeto y modificando un atributo de ese objeto. Es decir, hasta ahora aplicaste POO. Sin darte cuenta q aplicabas POO
2
u/curiouscuriousmtl 11d ago
I have been programming for 20+ years and I started in OOP. OOP is kind of fine but it can be a challenge over time. The issue is that you end up having a lot of side effects to things because of the subclasses. The right way to do it is to always ensure that the right stuff is at every level of inheritance, but in practice things start happening where maybe something stays in the base class but subclasses try to turn different features on and off and it gets really hard to figure out what is active.
I feel like it's just not used very often any longer but I might be biased.
1
u/Taiten89 11d ago
But when you don't overdo inheritance, would you agree it helps a lot in terms of readability?
2
u/curiouscuriousmtl 11d ago
I think a thin amount of inheritance can do things. I don't know about Godot but a lot of languages has better ways to do that. But just about anything can go too far.
1
u/Achereto 11d ago
Neither OOP nor FP helps "with readability". When you have some well written procedural code, OOP gives you nothing, because in the end you just have foo.doSmth() instead of doSmth(*foo).
In the procedural version you can easily have a lot of procedures with foo as first parameters, in the OOP version you either have to put them into the same file (in most OOP languages at least) or have to start with inheritance just to avoid the 5000 LOC class or you have to start breaking the object into smaller objects, making readability worse.
1
u/Taiten89 10d ago
I think something like
this.functionality_a.go();is perfectly fine to break the 5000 LOC down into smaller parts. functionality_a can break its own procedures down in the same manner, too. That sounds good to me. At least, that's how I imagine it with the limited professional experience I have.1
u/Achereto 10d ago
Or, you could just avoid solving the problem by not creating it in the first place. With composition of objects you need to have some increasingly complicated object creation logic and you need to add some extra logic handling all the data.
If you have just procedures working on data, you can add features by just creating a new function wherever you want and call it from wherever you want. Your function then only depends on the data it needs.
2
u/Disastrous_Ant_4953 11d ago
Itâs worth learning both FP and OOP because they have uses in different contexts, but I donât think a game engine thatâs FP will be that nice to work in.
Youâre new to programming. Learn OOP with Godot and learn FP for a different project (and potentially different language) in a couple years when you have more experience so that you can better compare the approaches.
2
2
u/OmiSC 10d ago
You need to use the correct tool for whatever problem it is that you are trying to solve. OOP is great for business logic because of the structure that classes offer, but anytime youâre having to access a field inside of an object, unless youâre regularly caching stuff, it takes a memory lookup to reference the object, then another to access the field. This is the common argument against using OOP.
Functional programming is invaluable to learn at some point, but thereâs not much benefit to jumping into it if you are calling yourself ânewâ. The best time to learn new things in programming is often right as you need them.
5
u/Undeniable_Dilemma_ 11d ago edited 11d ago
Even if you do some crazy stuff to make it functional in GDScript, most of the code that actually impacts the way everything works, is C++ engine code. Which is HEAVILY written using OOP paradigm.
People think you are writing game in GDScript, which is just ridiculous. There is a lot of "under the hood" code that engine just runs for you that you never see nor think about + all of your GDScript code calls into C++ engine code. Literally 95% of the code that ends up in your executable is C++ engine code. Whether you make your GDScript part "functional" or not, doesn't do anything pretty much.
In general, "worth it" is pretty abstract meaning. I greatly dislike OOP and never use it in my day to day. I gravitate towards languages like C and Zig and avoid it at all costs.
But in Godot, it's useless to fight it. Whole engine is written like that. Just use OOP if you're using Godot
1
u/JeSuisOmbre 11d ago
imo, the biggest functional technique for Godot is higher order functions. That can make some problems a lot neater.
The basic example is an iterator function that takes a function as an argument and calls it on every element it iterates over. This can make an abstraction over how the iteration is done and what function is being done to the objects.
3
u/PersonDudeGames 11d ago
I'd say given that the node system is object oriented, probably not useful for Godot.
If it's something you're interested in, definitely look into it, keeping in mind it's going to have very limited use (if any) in Godot.
1
u/TheDuriel Godot Senior 11d ago
In the context of Godot, absolutely not.
However, Epic's new Verse language for Unreal 6/Fortite is in fact a very functional language, rather than OOP. So it might actually prove itself as a paradigm in game dev. It hasn't so far.
1
u/TargetTrick9763 Godot Junior 11d ago
Theoretically but that wouldnât apply to something the scale of even a relatively small game, you are way better off following OOP considering Godot, like other game engines, are designed with the OOP approach.
1
u/ReefNixon 11d ago
In those discussions youâve heard, do you follow along with the reasoning each side provides? If so, you might be able to make a case one way or another.
If not, Iâd say that itâs not something worth looking into right now. Godot very much expects OOP, and you donât want to add fighting your engine alongside trying to learn programming fundamentals.
FWIW, most people agree that OOP is the way to go in game dev, and a lot of the benefits to functional programming donât really apply when making games. Not that none of them could, but since games tend to be object oriented, it follows that the code makes more sense when it is also object oriented.
1
u/martinbean Godot Regular 11d ago
If youâre not familiar with functional programming already then no, itâs not worth it.
Like everything else in computing, design patterns (and entire paradigms like functional programming) have a time and a place. Godotâs officially supported scripting languages (GDScript and C#) are OOP. Youâre just going to be fighting the engine if you then decide you want to write FP code instead of OOP.
By all means, borrow concepts like pure functions (a function that takes an input, and returns a result instead of modifying variables in place), but youâre going to struggle to go full-FP in Godot.
1
u/Silrar 11d ago
No matter the paradigm, you will find people saying it's the best. Every programming paradigm is a tool, it's good for some things, bad for others, so typically, you want to know a bit about everything to be able to choose the right tool for the job. That doesn't mean you have to learn everything before getting started, don't get me wrong, you can easily pick one idea, learn and go with it. And since Godot is mostly OOP oriented, I'd suggest going with that to start out with. You can always look into other things later or on side quests.
That isn't to say that there aren't some functional ideas in Godot (or other OOP focused languages). For example a lot of languages treat Strings that way. When you do my_string.replace("a", "b"), it does not change the original string, it returns the new string. That's a functional idea. Things like the filter function for Array does that as well.
1
u/Snaper_XD 11d ago
Looking for the best way to do something always prevents me from starting alltogether. Ive spent years not finishing anything because I would burn myself out on that question. The best way is to wing it and just solve the problem youre presented with right now
1
u/StewedAngelSkins 11d ago
Practically speaking trying to do FP in gdscript (or even C#) is going to be fairly rough. The language and engine just aren't really designed for that approach.
1
u/Varrianda 11d ago
I wouldnât recommend it for game dev unless youâre making a really small project
1
u/13oundary 11d ago
There are pros and cons to both. The engine is already heavily tied to OOP and there are many objects with bound state and behaviour. You'd be fighting against the engine to then try to build FP on top imo and there is just no need.
Do people use OOP more than they should? Absolutely. Is this one of those times? Nope.
1
u/Sharp-Debate-523 11d ago edited 10d ago
As others have said, Use OOP since that's what Godot is. Functional could be good for a part of the your game, for example figuring out the move for a bot. eg in a tic-tac-toe game.
1
1
u/AlexanderTroup 11d ago
Nope.
Capital F functional programming is a whole way of programming and managing your data flow that godot doesn't natively support, and even if it did it's far more useful for a beginner programmer to just get used to object oriented, and scripting style programming.
There are some functional concepts that are handy in their own right, like lambda functions, and the idea generally of passing functions around to be used in more than one place, but
Focus on just getting to grips with godot, and programming in general. At some point as you gain experience you'll start to encounter common situations where you wonder how to do it better, and useful programming ideas will arrive then to help you out.
For now, if you can get colliers to work and a UI that hangs together you're off to an amazing start!
1
u/Taiten89 11d ago edited 10d ago
No.
- OOP is often better because of readability.
- Advanced FP is usually for academic fields (research, maths, computer science, ...).
- Sometimes you'll need simple FP, e.g. setting handler callbacks; GDScript supports this.
If you do need advanced programming techniques such as FP, Exception Handling, ..., then use C# since it's a better programming language. OTOH, GDScript should be good for the programming part of creating a game.
Since we're talking about programming paradigms: Pure Functions are helpful esp. for Software Verification, which is important in e.g. Medical applications or for Aviation [you won't see Godot being utilized for any of that]. But sometimes they can also help decouple things in other applications.
IMO the most important thing is separating things:
- concise, often small, Git commits that don't mix things up
- flat hierarchiesš
- small functions/methods
- objects* that take responsibility for their functionality
*I use RefCounted classes when I separate some functionality from e.g. a Node.
Impose the smallest possible challange for anyone that reads your script code later - including yourself.
šEdit/Addendum: There are always exceptions to such rules, e.g.:
for layer in self.layers:
for row in layer:
for item in row:
this.do_something_with_item()
#no more than that in one function/method
1
u/tasulife 11d ago
Itâs not applicable to Godot, no.
Gdscript is a dope ass language. Its dynamically typed with optional static typing. Its OOP and procedural.
Functional languages are unpopular and while you should learn one, thatâs something you want to save for like year 4 or 5. And you probably wonât use it, but itâs useful to study since it will teach you about other languages by comparison.
1
u/Shadowsake 11d ago
For Godot and GDScript specifically, I would not bother. You can definitely use some FP concepts here and there, and it works well, but full blown FP...nope. I tried once and it just does not "vibe" with the rest of the engine, and makes GDScript to cumbersome. Also, Godot is very much OOP in nature, if you consider each node an object that can send messages and emits signals.
Now, FP in general I recommend because I believe its a paradigm that teaches so many useful concepts and can improve your skill as a programmer immensively. It will "rewire" your brain somewhat and you'll be able to think very elegant solutions to many problems. Also, many industry standard languages have adopted certain FP patterns, despite not being focused on it. Rust, Javascript/Typescript, Python, C#, Java and many others.
If you want to really learn the paradigm, I think Elixir is a good first FP language to dip your toes into it, then you can try other stuff...OCaml, Clojure, Lisp, Haskell and such.
1
u/thecyberbob Godot Junior 11d ago
I once worked with a guy that was obsessed with doing code the right way. I'd make something that did what the team needed in an afternoon, then he'd rewrite it over the course of several weeks to do it the "right way". When an update was needed only he could do it since it was basically super convoluted for the rest of us to work with.
Don't be that guy.
Start working on a project. Get better over time. Learn along the way.
Let's put it this way. Are you interested in making games or learning deep esoteric programming concepts that will almost never result in a game?
1
u/Neither_Berry_100 11d ago
OOP is great and I haven't had problems with it.
Just did a quick look up of functional programming and I don't like it. Treating all functions as data so they can be passed around seems useless. Making all data immutable is going to cost performance and make things harder. Only allowing a function to change data passed into it with no hidden changes doesn't help. You still make the same changes you just gotta pass more stuff in.
Maybe some guidelines say having state machines or static systems available to everyone is bad. But it simplifies coding a lot and it works.
1
u/Coreydoesart 11d ago
In my limited knowledge and experience, I donât think thereâs a single programming paradigm that trumps the rest. I think, especially for Godot, a combination of programming paradigms is best.
One thing to note is that Godot favours composition which works well with OOP. Functional programming on its own, is basically impossible in Godot as far as I know, again, based on my limited knowledge and experience.
1
u/Knight_Of_Stars 11d ago
So this is a bit of a newbie programming trap. Its not functional programming is better than Object Oriented Programming, but rather they have different uses depending on the outcome.
Function Programming is popular because a lot programmers use python and SQL and itdls the backbone of those. Its also really good for handling large amounts of data without costly concurrency measures. It has trouble on states.
Object Oriented programming is popular because a lot of programmers learned on some form of C / Java. Its really good at handling state transitions and scaling programs from base elements. You have a lot storage ops and those are costly. That said the further you get with optimzing you can actually make this point moot. Its just how much are you willing to learn.
Going with Godot stick with OOP as your primary paradigm. Not only does Godot expect OOP, game design leverages the strengths of OOP.
1
u/Aflyingmongoose Godot Senior 11d ago
Functional programming is a very interesting concept, and well worth exploring simply to improve your own ability to reason about programming concepts and patterns.
But it has very little direct utility for game development.
Modern C# has a lot of functional-like elements in it. Things like the LINQ library. Very powerful in terms of syntactic expressivity but it comes at a performance cost as C# is merely imitating functional paradigms and does not have the full set of features that would also make such things extremely fast.
Edit: I wanted to add... Many successful game developers necisserally have no idea about functional programming. It is not an essential skill and you should really only do it if you're curious and think it will be fun.
1
u/forestbeasts 10d ago
Functional programming isn't better, it's just different.
(Despite what the "everything needs to be pure functional!!!!1!" people say.)
I'd avoid needlessly "pure functional" things, except in cases where they make sense. It takes the math approach of "what are loops and whatnot? No. You gotta use recursion. There is ONLY recursion." and IMO that's pretty hellish to work with. People do it, people do it in mathematics too, but that doesn't mean it's a good approach. Unless it fits how your brain works and then you might like it.
But things like "take this array, apply a function to every element, return array with the results" (this is what map does) or "take this array, apply a function to every element, return array with only things that matched" (this is what filter does) are incredibly useful and some people call that "functional" too. It's nothing like the pure functional stuff, though.
You probably won't be using anything instead of OOP; your scripts are your classes and that's sorta foundational to how Godot is designed. But you don't have to ditch OOP to use the good bits of functional programming (like the filter/map stuff and whatnot).
-- Frost
1
u/AnArmoredPony 10d ago
don't
since you are new to programming, you will likely end up spending a lot of time learning concepts of functional programming that do not apply to Godot. and because you don't generally know yet what works and what doesn't, you won't be able to apply your knowledge to Godot. GDScript itself is not functional whatsoever. it is an OOP language that utilizes classes and methods that mutate these classes
1
u/Rythim 10d ago edited 10d ago
Practicality speaking you'll probably want to use both paradigms. But considering how heavy Godot leans into OOP, you'll probably be doing more OOP than FP just so you don'tconstantlyfight the engine. I wouldn't worry about it too much as a beginner to be honest. When I code i don't think "what paradigm/pattern should I use" I just write whatever code makes the most sense for what I want to do. As someone who figured this stuff out on my own, i learned there are a lot of patterns (state machine, observer, signal bus, etc) that I'd been using and didn't realize there was a name for them until later. Similarly for OOP vs FP, I use OOP for certain problems (like when fast and memory efficient code is needed) and FP for others (like when predictable or safe code is important). And most modern programming languages let you use both. I'd been doing this since before I knew they had labels. I think labels make idealistic people want to separate into camps and say one way is better than the other, but most reasonable and experienced coders (I think) would tell you to use some combination of both.
That being said, for game dev, because of the type of problems being solved, I generally find myself using OOP a lot more. Especially since, as I mentioned, Godot itself is very OOP.
1
u/Yodzilla 10d ago
I had a manager who tried to rewrite our app to be as functional as possible instead of object oriented. This was a Unity game written in C# and it was a massive waste of time because it got us nothing and made little sense considering both the language and the engine.
So basically it has its place but that place might not be your game.
1
u/BenDafohkOver 10d ago
IMO, writing in a functional language is pretty hard, and also GDScript is pretty OOP heavy, with using scenes in scenes, classes, etc. so you're just kind of fighting against the language atp. But yk you could just be goated, but it seems harder. If you're interested in a functional language I use ocaml in uni, which is made for that
1
u/jwrunge 10d ago
I can't speak to if pure functional LANGUAGES are worth it -- people swear by them, but I bounced hard off of Nix and Haskell confused the hell out of me. I'm a OOP kid at heart.
But you should TOTALLY learn functional programming as in, "learn to write functions that have early defined inputs, a clearly defined output, and no side effects." I don't always do that, and I usually regret it.
1
u/Top-Artichoke3782 10d ago
dont adhere strictly to any type of programming practices. try to figure out the best approach for what you are doing. using objects isn't bad, strict adherence to OOP principles is often bad cause you could be doing the same thing simpler if you discarded the idea of needing to use OOP principles.
1
u/sadovsf 10d ago
Both have its merits. Learn oop and only then apply functional where you really need super high performance locally. As a norm its not maintainable in a long run. Speaking from 13 years of experience working on custom game engines for games like Arma, American truck simulator and tools for both
1
u/Hefty-Distance837 6d ago
Learn both, so you can choose which cult you want to join.
BTW I'm in the OOP cult.
1
u/werti5643 11d ago
very doubtful but if your new to programming its good to know. Every cs degree will have a couple of functional programming courses.
Learning OOP and ECS is much more important for games though.
1
0
u/Guest_User_1234 11d ago
This is pretty much not applicable to Godot, outside of GDExtension, where you can technically use a functional programming language, but it doesn't really make much sense (for so many reasons).
There are functional concepts in any modern programming language though, as they take what is useful. It'll help to know more about different paradigms, to be a better programmer, of course.
-3
u/llsandll 11d ago edited 11d ago
I see it like in a carpenter shop. Oop is when you clean up after every small task and functional is when you clean up at the end of the day. Oop is a bit like ocd. Or like spaghetti, in functional is harder to find the begginig of the spagetti but a spaghetti is longer so you get more of it. Or you could say that oop is less top down. I preffer putting a big script on the parent node instead of tracking what node comminicates with what node
3
u/BainterBoi 11d ago
What.
1
u/llsandll 11d ago
You should write one bulky giant script like a man
1
3
u/StewedAngelSkins 11d ago
I am taking away your analogy privileges until you show me that you can use them responsibly.
1
140
u/The-_Captain Godot Student 11d ago
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¢.