Hacker News Reader

Comment by yummyfajitas | Hacker News Reader

Functional programming works just fine.

If you want to take two isolated functions and make them behave in some complicated manner depending on how often one or both are called, simply refactor them into the state monad. I.e., replace f: a -> a with f: a -> State a, and do the same for g.

This is likely to break stuff. In C, good luck figuring out what might be broken as a result. In a pure functional language, you know the damage is limited to the state monad. Anything outside of state is safe.

View on HN

It took me a while to realize, but monads are a great solution to the problem of state (to mention just one thing).

Now that I've gotten used to them though, it sucks not having them in (many) other languages... Haskell has spoiled me :(.

Most other (good?!) languages should allow you to define monadic data structures fairly easily. Many languages are able to make use of monads, the difference being that Haskell leaves you (almost) no other option.

Refactoring a stateless program into one that uses state is a big pain. Making programs that use different amounts of state, or kinds of state, at different parts within the program, is also a big pain. Functional programming languages including ones where monads are regularly used are just bad at this. You get towers of state transformers, or a lot of boilerplate for converting between one kind of state to another, and boilerplate for entering and leaving different kinds of stateful situations. Or you can just have one big state monad that goes everywhere, in which case there's three kinds of things, which are functions that live purely in IO, those which are pure, and those which live in your state monad.

But then you realize that certain purely IO actions need to do some logging and then they can't live in the IO monad and you need to refactor logging out of everything else and put your logging monad inside your state monad (and put a bunch of new liftIO's all over the place), but wait, didn't you just want to add some logging statements to debug this thing, and now you're tearing apart the structure of the world.

So maybe we could come up with some abstraction for logically separate components of a program's state, and then create a type of action that uses descriptors telling what subset of a program's state components are used, or we could not do that and recognize that functional programming does not work just fine, and that pure functional languages are bad at working with state.

I agree with you that Haskell's approach is imperfect. There are too many liftIO's, and some method of taking the union of state monads (rather than nesting them) would be vastly better.

But I'm going to disagree with you regarding the claim that pure functional languages are bad at state. All of the problems you mentioned also exist in a non-functional language. In a non-functional language, you have functions which live in IO, in StateT GameState IO, and pure functions. The only difference is that you must carefully read the code to figure out which is which.

The approach of having one gigantic state monad which goes everywhere is precisely what you do in an impure language - just with some syntactic sugar to hide the liftIO.

Reply on news.ycombinator.com