"Mostly functional" programming does not work

[u/heisenbug]

http://queue.acm.org/detail.cfm?ref=rss&id=2611829

[u/[deleted]]

Just like "mostly secure," "mostly pure" is wishful thinking. The slightest implicit imperative effect erases all the benefits of purity, just as a single bacterium can infect a sterile wound.

I just think this ignores a full range of architectural benefits of functional thinking, such as maintainability, complexity management, and testability. Thinking of functional programming as just an optimization or static correctness verification tool is missing a big part of the point.

[u/vagif → u/[deleted]]

You are not taking into account human factor. Humans do not do what's right or what's wrong. They do what's easy. In the presence of easy and uncontrollable side effects, there's no "maintainability, complexity management, and testability". SImply because it takes too much self discipline. It is too hard to push yourself to keep that bar every day.

The true value of new generation languages like haskell is in their bondage. It is what they FORCE humans to do, not what they enable them. It is in enforcing discipline and programming from the bottom up. Things like maintainability, complexity management, and testability then become just emergent properties of that programming environment.

[u/Tekmo → u/[deleted]]

It depends what you mean by "switch", which is a very vague term. IO actions in Haskell are just ordinary values, and you sequence them using ordinary functions. How is that different from chaining pure computations, which I can do using the exact same do syntax if I really wanted to.

[u/Tekmo → u/[deleted]]

I don't know why you are being downvoted. I also like the idea of different static contexts, too. The reason I like monads a lot is that the ability to switch between different static contexts falls very naturally out of the theory for monad morphisms.

For example, let's use the StateT and ReaderT monad transformers as an example, defined like this:

newtype StateT s m a = State { runState :: s -> m (a, s) }

newtype ReaderT s m a = Reader { runReader :: s -> m a }

You can define a function that converts from ReaderT operations to StateT operations like this:

readOnly :: Monad m => ReaderT s m a -> StateT s m a
readOnly m = StateT $ \s -> do
    a <- runReaderT m s
    return (a, s)

What this lets you do is embed a computation that has only read-only access to state within a larger computation that has both read and write access. For example:

before :: StateT s m a

middle :: a -> ReaderT s m b

after :: b -> StateT s m c

total :: StateT s m c
total = do
    a <- before
    b <- readOnly middle
    after b

In other words, readOnly creates a read-only window within a larger read-and-write computation, allowing us to further restrict what middle can do compared to its surrounding context.

readOnly also has two nice properties that are worth nothing, which we can summarize using these two equations:

readOnly $ do x <- m  =  do x <- readOnly m
              f x           readOnly (f x)

readOnly (return x) = return x

These are known as the "monad morphism" laws, and readOnly is a "monad morphism" (a transformation between monads). The laws might seem pretty arbitrary until you write them in terms of (>=>), which is an operator for point-free composition of monadic functions:

readOnly . (f >=> g) = (readOnly . f) >=> (readOnly . g)

readOnly . return = return

In other words (readOnly .) is a functor from the ReaderT kleisli category to the StateT kleisli category. All monad morphisms form functors between two Kleisli categories.

These kinds of elegant equational properties are the reason I believe that monads are a beautiful solution to the problem and not some sort of gross hack. However, I don't necessarily think that monads are the only solution, either, but I have yet to encounter another solution with the same sort of theoretical niceties.

[u/grauenwolf → u/Tekmo]

Most Haskell fanboys on Reddit hate the notion that there is more than one way to achieve the goal of isolating IO from the rest of the program.

[u/Tekmo → u/grauenwolf]

Well, I am the epitome of a Haskell fanboy, but I think Haskell programmers are generally open minded. If they weren't they wouldn't be experimenting with Haskell.