Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Admitting That Functional Programming Can Be Awkward (2007)

prog21.dadgum.com

Post reply on HN
Print view View original

31–40 of 148 posts

Re: Admitting That Functional Programming Can Be Awkward (2007)

#31

Post by voodootrucker »

dehrmann wrote: post #26
voodootrucker wrote: post #9

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…

> sometimes OOP. I think OOP is taught somewhat wrong because people will dwell on contrived examples of inheritance when its real value as a paradigm is coupling state with functions. What we've learned from FP is immutability is easier to reason about, but when it isn't is when OOP shines because it gives you a sane way for managing state.

I _really_ struggled to not use contrived examples when teaching OOP. It was very hard because you don't really need it until your application becomes non-trivial so I see why all the college classes use cars & trucks or whatever.

I think I ended up going with a Player API with tapes, records, CDs etc. Some could skip, others only fast-forward. I was still unhappy with it, but it was better than most examples.

I like to point folks at writing an IntelliJ plugin. I find that some of the best architected OOP programs become nothing but a collection of plugin interfaces and base classes.

But you really need to understand "is a" vs "has a", not burn your base class, let architecture emerge following the rule of 3, rather than quickly jumping on the wrong abstraction to fight duplication.

Sandi Metz really says it better than I can: https://www.youtube.com/watch?v=8bZh5LMaSmE

Re: Admitting That Functional Programming Can Be Awkward (2007)

#32

Post by gnulinux »

fiddlerwoaroof wrote: post #29
gnulinux wrote: post #24

Earlier quoted context omitted.

Functional languages do have statements. a : Int -> Int a x = x + 2 both `:` and `=` are statements, not expressions.

This is sometimes true, the `=` equivalent in Clojure is an expression, though: user=> (def a (def b 2)) user=> a #'b Lisps generally only have expressions (every form returns a value.

Lisp runtime implicitly runs each top-level expression as statement. When you run (def x y) it's not only true that this expression returns 'x, it's also true that it alters the static state of the program by adding 'x to the scope.

To make a purely statementless language, I think you need to make everything happen in a single monadic computation. E.g. in pseudo-Haskell-ish:

    main : Scope -> StaticIO Scope
    main scope0 = do
      scope1, x'
But the main part is still statement.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#33

Post by ramchip »

dnautics wrote: post #14

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…

I think it’s a common trap for Erlang beginners to try to represent all entities (player, monster, room, etc.) as processes sending messages to each other, the way you’d use classes in OOP. It’s one way to learn the concepts, but in real apps it leads to messy, brittle code. Erlang processes really shine when they’re used as units of fault tolerance, not a code organization tool.

For an entity system ETS could be interesting, but it involves copying data on every read/write which could be a problem in games...

Re: Admitting That Functional Programming Can Be Awkward (2007)

#34

Post by Deadron »

mannykannot wrote: post #28
kibwen wrote: post #6

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…

Before reading this article and its follow-on, I would have completely endorsed the view that global mutable state is the worst, but for the sorts of issues the author is writing about, it seems that global mutable state is precisely the thing that makes procedural solutions more straightforward. In this case, it seems to be an intuitive and straightforward model for how both the programmer and player view the proble…

Until you attempt to multithread the logic and everything breaks.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#35

Post by mrloba »

jasperry wrote: post #12

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 t…

I completely agree. Just write pure functions as much as possible and you're good. What goes inside a function doesn't matter so long as the function itself is pure, imo

Re: Admitting That Functional Programming Can Be Awkward (2007)

#36

Post by pg_bot »

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.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#37

Post by mrkeen »

jasperry wrote: post #12

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 t…

> Why not start from the imperative model

This video gives a bit of discussion around that point: https://www.youtube.com/watch?v=iSmkqocn0oQ

My take on it is that it's too hard to put the side-effect genie back into the bottle once you take it out. It's hard to write side-effect-free code out of side-effectful pieces.

E.g. You can't make a reasonable transaction system if you allow side-effects. You just have to hope that the programmer doesn't include any code that can't be rolled back.

> 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.

Haskell do-notation and Scala for-comprehensions kick arse and I always miss them when I don't have them. I think lack of do-notation is my biggest complaint about Java syntax.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#38

Post by acdha »

Deadron wrote: post #34
mannykannot wrote: post #28

Earlier quoted context omitted.

Before reading this article and its follow-on, I would have completely endorsed the view that global mutable state is the worst, but for the sorts of issues the author is writing about, it seems that global mutable state is precisely the thing that makes procedural solutions more straightforward. In this case, it seems to be an intuitive and straightforward model for how both the programmer and player view the proble…

Until you attempt to multithread the logic and everything breaks.

This is true to the extent that it’s true to say that functional programming requires you to make copies of immutable structures every time something changes, which is to say not at all.

Multithreading is a problem when you have chaotic ownership of writes and updates. There are decades of prior art showing that this is a manageable problem using various strategies, and it’s not helpful to talk in absolutes rather than discussing the relative trade offs.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#40

Post by mrkeen »

mrloba wrote: post #35
jasperry wrote: post #12

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 t…

I completely agree. Just write pure functions as much as possible and you're good. What goes inside a function doesn't matter so long as the function itself is pure, imo

Do you have any examples of compilers or linters that assist with this? Any kind of error or warning would do.
Post reply on HN