from Hacker News

Admitting That Functional Programming Can Be Awkward (2007)

by kkdaemas on 10/24/20, 3:27 PM with 144 comments

by atty on 10/24/20, 4:09 PM
I think anyone who has coded long enough would recognize that OOP, functional, imperative, etc all have their strengths and weaknesses, and all have problem domains they are better suited for. Unfortunately, this sometimes gets lost in the language fan wars - it’s easy to lose nuance when discussing something you are passionate about, I have made this mistake myself.
by kibwen on 10/24/20, 4:20 PM
I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages.
IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state is often quite useful. But minimizing state, especially global state, particularly mutable state, and especially particularly global mutable state, is something even imperative language fans can get behind.
by eyelidlessness on 10/24/20, 4:59 PM
Honestly I think this conclusion comes more from lack of familiarity with how people solve similar problems with FP than anything. For example, in the author’s followup post:
```
        All you have to do is pass the world state to each function and return a new state.

    True, yes, but...yuck. It can be clunky in a language with single-assignment. And what is this really gaining you over C?
```
I mean, if you stop there, sure that’s ugly. But if you model your program with that as the foundation, then break it down (and generalize where breaking it down is general), it’s pretty easy to reason about. And what it “gains you” is never having to think about something changing in a way that produces invalid or unexpected state. (This is more true in statically typed languages of course.)
In any program of any real complexity, you will eventually be inclined to break the problem down into smaller pieces. If your smaller pieces are functions, you can be certain about the state that’s returned by them. If they’re stateful subroutines, then you have to think about multiple pieces at the same time.
by voodootrucker on 10/24/20, 4:21 PM
I wrote an exercise once while I was teaching: "pure functional pacman". Really I did it to teach myself Redux, and it was a pretty fun way to learn.
Totally agree with the article: sometimes functional is the right tool for the job, sometimes OOP.
A more recent example: parsing USB descriptors in Rust. The parser would have been trivial and easy to understand if I could have multiple mutable references to nodes, but alas I kept fighting the borrow checker.
I talked with a friend about why it was so hard, and he said "do it in a functional style". That made my borrow checker worries go away, but instead I have multiple "tree pivoters" that recursively descend through input trees while building output trees. It practically broke my brain and although it is pure, it's not nearly as readable or maintainable as one with mutation would have been.
by jasperry on 10/24/20, 4:26 PM
Could it be the case that functional structure makes programs more reliable and easier to reason about in the large, but functional style/syntax may not be the best way to write code locally?
Trying to wrap an entire function's computation into one expression is a fun mental exercise, but the resulting code may be harder to read than a sequence of statements. Haskell's "do" notation seems to be an acknowledgment of this, but to me it's adding another layer of abstraction just to recover what imperative syntax gives in the first place. Why not start from the imperative model, and then find other ways to try to limit side effects and mutation? Languages like Rust may be heading in that direction; "Return of the statement" as it were.
by karmakaze on 10/24/20, 6:25 PM
The direct update imperative way works until you have enough multithreaded actions that interact in undesirable ways. In addition, locks don't compose. I worked on a relatively straightforward trading app with charting and realtime rates. There were so many bugs from direct updates that interfered with rendering that it was best to restructure it as world-in, apply function(s), world-out. Then the renderer only had to deal with one frame of the world. Some items had a smaller 'world', like a single price tile. Whether done in a functional language or a procedural one this functional pattern is a common one.
by chowells on 10/24/20, 6:55 PM
I would much rather write the logic the author describes in Haskell than C. The C code will have to be carefully managed during development and maintenance to make sure the side effects are happening in the expected order and that no changes ever introduce unexpected interleaving of mutation. The Haskell version will prevent that trivially. You can't even express doing it the wrong way, because you can't mutate anything.
Accidentally interleaved mutation is not a theoretical or academic problem. It's probably the number three source of production bugs in my dayjob's various products, behind misunderstood requirements and web browsers constantly changing the rules. It turns out that everyone, even people like me who know better and have been burned several times, will sometimes take the convenient shortcut. It's so tempting to get something done immediately by quietly mixing some mutation in an unexpected place, and it usually doesn't bite you. Then it gets ossified that way, and a year later starts biting you. This really does happen in code maintained by multiple developers over multiple years.
To be fair to the original post, though, Haskell has come a long way in making that kind of coding easy since 2007. The lens library didn't exist back then, and it's a big part of why data transformation programs are so much more pleasant in Haskell than most languages. It lets you express data access at the right level of abstraction. You get laws to enable algebraic reasoning and a broad range of utilities for composing small pieces together to solve complex problems.
by dexwiz on 10/24/20, 4:36 PM
The middle part about insects, their spawn rates, types, and mutating values is all about state. No matter how much you try to go "stateless", there will be some state implied by your data. Functional programming as the author describes it is good at calculating state, but bad at accessing it. The only for functions to access state is through parameters, which have a final single value in your closure (no out parameters please). They don't have registers/variables/properties to modify.
Functional programming says values like spawn rate or type should be the output of an expression. Monads try to solve this, but storage must be the output of an expression, and is always more complex than simple assignment.
There is one more secret about programming that functional tries to ignore, that it runs on physical machines. Even though some would like to describe programs pure mathematically, they still are bound by physical mechanisms. Most of those mechanisms are for storing state in memory or transferring state to another location. Abstracting over this fact makes programming painful once performance is taken into account.
by mrkeen on 10/24/20, 4:34 PM
This article implies that functional languages cannot run imperative statements, even though it takes for granted that imperative languages can call functions. Google "world's finest imperative language" for a different take on this.
> And each of these is messier than it sounds, because there are so many counters and thresholds and limiters being managed and sounds being played in all kinds of situations, that the data flow isn't clean by any means. > What's interesting is that it would be trivial to write this in C.
You could make the same argument about dealing with git and all its crazy branching, rebasing, and reflogs, compared to just editing your source code in place. Or double-entry bookkeeping versus just keeping track of how much money you have. It gets awkward.
I loved the elegance of game programming in Elm a few years back, but the performance was dogshit - in my case at least - so I probably wouldn't do it again.
The real reason to stick to C/C++ in game programming is speed.
by flowerlad on 10/24/20, 7:25 PM
What is worse is when some developers maintain and mutate global state, write functions with side effects, and still think their code is "functional" because they aren't using any classes. A lot of JavaScript developers are moving to that camp because of React and Hooks.
More on that here: https://medium.com/weekly-webtips/dysfunctional-programming-...
by nicolashahn on 10/24/20, 4:04 PM
> admit that functional programming is the wrong paradigm for some types of problems.
Absolutely. Some problems are just so much simpler in an imperative style that it's worth the lack of confidence you get with the functional solution in its correctness and robustness.
That's why I love languages that have fairly powerful functional features but have an imperative escape hatch. I think more and more languages are becoming that. Rust does it very well, but the lisps, probably Scala, and a few others I'm not thinking of may be better, don't have much experience with those though.
by dnautics on 10/24/20, 4:27 PM
I'm confused by this article. The author says he's in erlang (which, btw, is not pure functional). And then goes on to describe a system which sounds like an object oriented system. But a game programmer would probably actually implement it not as object per se, but maybe backed by an entity component system. But it seems like BEAM languages would be actually quite good at expressing entity systems, which, correct me if I'm wrong, are similar to say checking out and manipulating data in a database.
by savanaly on 10/24/20, 4:20 PM
>Sure, there have been games written in Lisp and some games written by language dilettantes fond of Objective Caml, but they never turn out to be programmed in a functional style. You can write imperative code in those languages easily enough.
I would like to know more about this. I've written several games in Elm, a js counterpart to Haskell, and I guess foolishly assumed that meant I was writing them in the functional style. Now I'm curious if I'm actually writing in an iterative style and if so what would the functional style look like? I would welcome general responses to this as well as any comments on the code style specifically in examples like [0].
[0] https://github.com/tristanpendergrass/legendary-barnacle/blo...
by r-w on 10/24/20, 4:20 PM
Ever heard of the Elm Architecture? It helps address some of these pain points, e.g., by forcing you to decide from the get-go what your global modifiable state comprises, and then having each action consist of an update to that state model.
by tome on 10/24/20, 5:05 PM
Can someone with experience of entity component systems (ECS) please chime in? My understanding is that games are not written in the manner that the author says is so easy, rather they are written as pure functions operating on a big table of world state. The world state happens to be mutable for efficiency, but that's an implementation detail. Then again I've never worked with ECS so perhaps this my misconception.
by FpUser on 10/24/20, 5:41 PM
Of course it can be awkward as it is very specific and opinionated paradigm. It may help to solve some problems while being totally unsuitable to solve others in a sane manner. There are no silver bullets in life.
I personally always shied away from adopting/committing myself to any strict concept. My long experience taught me that as soon as you do there it will likely blow up in your face one or the other way some time down the road.
by ookdatnog on 10/24/20, 10:14 PM
John Carmack commented quite extensively on functional programming in video games:
https://youtu.be/1PhArSujR_A?t=125
https://www.gamasutra.com/view/news/169296/Indepth_Functiona...
by kaashmonee on 10/24/20, 6:32 PM
I'm not sure I'm understanding the point of this article. Every language and language paradigm is awkward if it's used for purposes it's not meant for. Writing a game is something that is really heavily dependent on mainting some sort of state and functional programming in principle is supposed to be stateless. So, unsurprisingly, it's awkward to use FP for game development.
by mikewarot on 10/24/20, 5:50 PM
Programming without destructive updates works because it makes explicit the data flow in a program, not because destructive updates are bad.
by ngcc_hk on 10/25/20, 12:08 AM
In spite of its name this video use JavaScript to implement a game using the three styles of programming. Great video learnt from hacker news: https://youtu.be/vK1DazRK_a0
by pmarreck on 10/24/20, 7:45 PM
He thinks passing around the world state as a functional immutable data structure is “gross”, but modifying the same state as a global from anywhere in the program... isn’t?
by pg_bot on 10/24/20, 4:51 PM
Once you grok the language you can easily model the type of situations that they find awkward.
For example in erlang/elixir you can keep game state in a series of processes. You model the state changes based on messages that a process receives, and you can spawn/terminate processes as needed. Everything he described as challenging is trivial if you understand the language paradigm.
by jqpabc123 on 10/24/20, 4:54 PM
There is no one "best" way to program.
by nerdtime on 10/24/20, 6:53 PM
Functional programs tend to be more modular than imperative or OOP counter parts but nobody really knows why nor do they understand the cases where FP becomes less modular.
FP is only modular when you use combinators. If you use closures then it's no longer modular.
```
   f x y = x + y
   g y = y * 2
   w x = (f x) . g
```
g and f are combinators and modular and w is the composition of both of those combinators.
```
   w = \x -> (\y -> (x + y) * 2)
```
In this case the above is not modular because it doesn't use combinators. The above style is actually kind of promoted by haskell when you need to do things with side effects. It actually makes FP more complex than it needs to be without improving modularity.