3 ms·

I've been hacking away in as my job Unity for years.. Can someone tell me do they think the practice described in the article is a good idea? (The writer says

I've been hacking away in as my job Unity for years.. Can someone tell me do they think the practice described in the article is a good idea? (The writer says they are just learning so their opinion is not very valuable to me (When theyve cranked out a bunch of games on various platforms and encountered all kinds of horrible shit and overcome it, it would be more valuable to me)) I'm all too familiar with OO's many foibles and I'm interested in functional bur have never done any. One thing I've heard though, is that OO is bad for most stuff except games. Where you actually have this world with all these entities composed of various objects going around in it about their business. Its does make sense to have a 'Cow' object that has state + methods to get it to do various things like 'moo' Additional: Looked around a bit and the Arcadia repo says.. " Arcadia is alpha-quality software, and shouldn't be used for anything important yet. " I'm also try as hard a possible and use as much standard, vanilla Unity stuff as possible, as the more weird custom plugins and whatnot you use the more heartache you get when it comes to building and releasing + updates on a million damn phones or PC setups. Anything not standard has to justify its existence against very jarsh criteria. I will download and mess with this though. I'm actually really excited to do some functional programming!!

mquander 10y ago
I've programmed mostly-functional stuff for a while in a bunch of languages and I have been working on a large performance-intensive (massively multiplayer, VR, and mobile!) Unity codebase for the past year. My conclusion is that functional programming is still a good idea to the extent that you can do it. Specifically, you should still minimize and encapsulate mutable state, and you should write pure functions when possible. However, the infrastructure doesn't exist to do functional programming efficiently in a lot of ways. Examples: - Most of the .NET standard library functions over sequences (i.e. LINQ) incur substantial time overhead and do a lot of heap allocation. Writing and using generators, same story. - Anonymous functions incur heap allocations and overhead which does not seem to ever be optimized out in Unity's Mono runtime. - .NET's standard library data structures are mutable. - Most of Unity's API and the libraries people write for it are not functional. I don't think you would be wise to try to fight these facts and paper over everything with functional abstractions, or you will die of a thousand small performance cuts.
- hacker_9 10y ago
  Just a note, this is mainly an Unity problem as they use an old Mono compiler and runtime. Additionally lambdas only create garbage when you capture local variables, and the normal GC is optimised to run without you noticing collections. The latest C# also has a whole library dedicated to functional data structures [1]. Additionally the C# compiler was rewritten in a functional style (proving it's capability IMO) and is completely immutable. It made sense for their use case as they can pass the syntax tree around to other threads now without fear of it changing. [1] https://www.nuget.org/packages/System.Collections.Immutable https://www.nuget.org/packages/System.Collections.Immutable
dangoor 10y ago
John Carmack has discussed functional programming[1] and has spoken about using Scheme at various points. So, the basic idea of using functional programming for games appeals to at least one well known developer :) [1]: http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php http://www.gamasutra.com/view/news/169296/Indepth_Functional...
Jeaye 10y ago
Arcadia is not representative of all functional programming practices ever. Its alpha state isn't reflective of the alpha state of functional programming either, which has been around for longer than most of us (50s-60s). FP boils down to one thing: referential transparency, or purity. A pure function f is such that any call to f(x) always yields the same result, to the point where any call to f(x) can be replaced with that result with no change in behavior. With it, we also typically use first class functions, higher order functions, closures, and lots of recursion; those aren't the key purpose of it though, I'd argue. Even in OOP, we're taught not to have globals. Why? They're not thread-safe; it's not clear who owns them; anyone can change them at any time; in languages like C++, there are also lifetime concerns regarding ordering of initialization between translation units. Referential transparency, I'd argue, is pushing the same exact agenda: stop modifying global state. It's not safe and it's not pure. As John Carmack mentioned in the article above, as game developers, we keep so much state in our mind at any given time; this grows exponentially with the number of threads we're also thinking about. Even in the most OO languages, we can strive to write code based on pure functions to make those functions easier to reason about, test, and compose. When something goes wrong in your function, and it's pure, you need only worry about your inputs, what you're doing in your function, and your outputs. When it's called doesn't matter (such as before or after some global state has changed). Rich Hickey, the creator of Clojure, said, in his Spec-ulation rant, that it's tough to explain to Java developers why they should consider Clojure. The reason it's tough is that you first need to explain to them that there's a problem they have which they don't realize: an anxious burning sensation regarding all of the mutation going on in their complex systems. When people use Clojure, and similar functional languages, they often feel liberated that an entire class of problems and bugs can be ruled out. With pure functions, systems can be much easier to understand through a narrow lense. With immutable data structures, tasks can trivially be run in parallel without the worry of thread safety; values don't change. As someone who came into Clojure from a background in C++, I've found that it is, indeed, liberating.
lucozade 10y ago
> One thing I've heard though, is that OO is bad for most stuff except games OO is useful when your primary abstraction is modelling the outside world. This is often true for games but is also true in a lot of other contexts. The explosion of interest in OO languages coincided with the explosion of interest in GUIs as OO was found to be helpful in modelling documents, windows etc. One of the reasons why C is still heavily used, despite its well publicised faults, is that it's proved useful where your primary abstraction is the machine you're running on. Functional programming, in my view, is useful where you want to abstract over operation. Where you want to specify what you want to do rather than how i.e. declarative programming. That's why concepts like map, filter etc have had a fair amount of "crossover" success. At different times, all these abstractions can be useful. With experience we have learnt that some features associated with each type of programming are more valuable than others e.g. multiple inheritance and raw pointers are used with caution. For something like a game, assuming it's non-trivial, I would expect that you'd find yourself needing to draw from all these. So I would be cautious about picking a language that cut you off from one or the other.
dkersten 10y ago
is that OO is bad for most stuff except games Mike Acton would disagree with you, I think. At least, if you want the kind of performance that graphics-heavy AAA titles demand.

mquander 10y ago

I've programmed mostly-functional stuff for a while in a bunch of languages and I have been working on a large performance-intensive (massively multiplayer, VR, and mobile!) Unity codebase for the past year. My conclusion is that functional programming is still a good idea to the extent that you can do it. Specifically, you should still minimize and encapsulate mutable state, and you should write pure functions when possible. However, the infrastructure doesn't exist to do functional programming efficiently in a lot of ways. Examples: - Most of the .NET standard library functions over sequences (i.e. LINQ) incur substantial time overhead and do a lot of heap allocation. Writing and using generators, same story. - Anonymous functions incur heap allocations and overhead which does not seem to ever be optimized out in Unity's Mono runtime. - .NET's standard library data structures are mutable. - Most of Unity's API and the libraries people write for it are not functional. I don't think you would be wise to try to fight these facts and paper over everything with functional abstractions, or you will die of a thousand small performance cuts.

hacker_9 10y ago
Just a note, this is mainly an Unity problem as they use an old Mono compiler and runtime. Additionally lambdas only create garbage when you capture local variables, and the normal GC is optimised to run without you noticing collections. The latest C# also has a whole library dedicated to functional data structures [1]. Additionally the C# compiler was rewritten in a functional style (proving it's capability IMO) and is completely immutable. It made sense for their use case as they can pass the syntax tree around to other threads now without fear of it changing. [1] https://www.nuget.org/packages/System.Collections.Immutable https://www.nuget.org/packages/System.Collections.Immutable

dangoor 10y ago

John Carmack has discussed functional programming[1] and has spoken about using Scheme at various points. So, the basic idea of using functional programming for games appeals to at least one well known developer :) [1]: http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php http://www.gamasutra.com/view/news/169296/Indepth_Functional...

Jeaye 10y ago

Arcadia is not representative of all functional programming practices ever. Its alpha state isn't reflective of the alpha state of functional programming either, which has been around for longer than most of us (50s-60s). FP boils down to one thing: referential transparency, or purity. A pure function f is such that any call to f(x) always yields the same result, to the point where any call to f(x) can be replaced with that result with no change in behavior. With it, we also typically use first class functions, higher order functions, closures, and lots of recursion; those aren't the key purpose of it though, I'd argue. Even in OOP, we're taught not to have globals. Why? They're not thread-safe; it's not clear who owns them; anyone can change them at any time; in languages like C++, there are also lifetime concerns regarding ordering of initialization between translation units. Referential transparency, I'd argue, is pushing the same exact agenda: stop modifying global state. It's not safe and it's not pure. As John Carmack mentioned in the article above, as game developers, we keep so much state in our mind at any given time; this grows exponentially with the number of threads we're also thinking about. Even in the most OO languages, we can strive to write code based on pure functions to make those functions easier to reason about, test, and compose. When something goes wrong in your function, and it's pure, you need only worry about your inputs, what you're doing in your function, and your outputs. When it's called doesn't matter (such as before or after some global state has changed). Rich Hickey, the creator of Clojure, said, in his Spec-ulation rant, that it's tough to explain to Java developers why they should consider Clojure. The reason it's tough is that you first need to explain to them that there's a problem they have which they don't realize: an anxious burning sensation regarding all of the mutation going on in their complex systems. When people use Clojure, and similar functional languages, they often feel liberated that an entire class of problems and bugs can be ruled out. With pure functions, systems can be much easier to understand through a narrow lense. With immutable data structures, tasks can trivially be run in parallel without the worry of thread safety; values don't change. As someone who came into Clojure from a background in C++, I've found that it is, indeed, liberating.

lucozade 10y ago

> One thing I've heard though, is that OO is bad for most stuff except games OO is useful when your primary abstraction is modelling the outside world. This is often true for games but is also true in a lot of other contexts. The explosion of interest in OO languages coincided with the explosion of interest in GUIs as OO was found to be helpful in modelling documents, windows etc. One of the reasons why C is still heavily used, despite its well publicised faults, is that it's proved useful where your primary abstraction is the machine you're running on. Functional programming, in my view, is useful where you want to abstract over operation. Where you want to specify what you want to do rather than how i.e. declarative programming. That's why concepts like map, filter etc have had a fair amount of "crossover" success. At different times, all these abstractions can be useful. With experience we have learnt that some features associated with each type of programming are more valuable than others e.g. multiple inheritance and raw pointers are used with caution. For something like a game, assuming it's non-trivial, I would expect that you'd find yourself needing to draw from all these. So I would be cautious about picking a language that cut you off from one or the other.

dkersten 10y ago

is that OO is bad for most stuff except games Mike Acton would disagree with you, I think. At least, if you want the kind of performance that graphics-heavy AAA titles demand.