Readablility

[tmichniewski]

When I read code like this:

    val forExpression: StateT[IO, IntState, Int] = for {
        _ <- add(2)        //3
        _ <- add(3)        //6
        x <- multiply(10)  //6x10
    } yield x

I start wondering if this is really that good.

Firstly, the statements starting with underscore seem to be pretending that the output is not important and the calls return no significant value, while the result is somewhere handled. Moreover, if there were two such intermediate values, then this would become even more fuzzy.

Secondly, since this is a very simple program, which just adds or multiplies a few integers, then we would expect, that the source code should also be very easy to understand.

But it isn't. On the contrary, this code with plenty of boilerplate is far from being simple and easy to understand. But this is a very simple program. Something like a few expressions.

Instead, this simple program becomes complex with plenty of additional types, methods and concepts. If so, then how the code would look like if the original code was complex?

This brings me to the conclusion that those great concepts look so discouraging and bring so much additional effort, that it may be understandable, why such monadic way of implementing is not that popular in the community of developers. I would argue, that it is less than a percent comparing to the other approaches. Generally, software engineering is complex enough, that we shouldn't make it additionally more complex. We should remember about such simple things like readability or KISS rule.

In other words, immutability, pure functions, this is OK. But doing simple arithmetic program with so advanced implementation forces to make a reflection, whether this is really better. At least the lecture of the book I am reading is trying to convey completelly opposite message.

Even the relation between for expression and the monads is not well thought off. Please notice that while debuggig some code with for expression, then out of the sudden some flatMap or map gets called. Is it really the way how elegant programs should work?

[alvinj]

I’m sorry, I still haven’t had the time to respond to your comments yet, but in regard to this one, one thing I can say is that this is the hard part of FP. To me, everything else about FP is relatively simple — at least once you understand the reason for doing things — and then the hard part is this, gluing things together.

Conversely, what tends to make OOP difficult is all the shared mutable state. When I worked a lot in the OOP world, I saw a lot of developers do a lot of defensive-coding things that were the result of trying to protect themselves from mutability.

And also, it’s perfectly fine if it’s not for everyone. When I write client-side mobile apps, I use pure functions as much as possible, but the frameworks are all OOP and mutation, so that’s what I use.

And as I mention in my Big FP Book, I encourage everyone to always ask “Why,” as in, “Is this really better? If so, why?”