My last post introduced Flow, a library for writing more understandable Haskell. The response to it on Reddit surprised me. It was more negative than I expected.

Many people who commented assumed that I didn’t understand idiomatic Haskell. This caught me off guard. I explicitly talked about and showed idiomatic Haskell in my post. Flow provides alternatives to some of the current idioms.

I would suggest that you learn the community’s syntax so you can interact with them more effectively. — mightybyte

Modify your understanding to be more compatible with idiomatic Haskell. — ReinH

I think you’ll find that after becoming a little more experienced with Haskell it’s perfectly possible to ignore most of these [operators like . and $] when reading code. — katieandjohn

Other people assumed that I had a poor understanding of math. I can understand that because math was completely absent from my post. I did that intentionally; I don’t think it’s helpful to pretend that programming and math are the same. That being said, I understand how function composition works. I’ve taken ten years of math classes.

I remember the composition operator felt like it was backwards when I learned it in a math class. But then I had another ten years of math classes. — chreekat

If and when mathematics notation is reinvented then we can start composing things the “right” way round. — tomejaguar

I’m much more prone to trust mathematical precedent than the vagaries of syntax in programming languages. — amyers127

So far the comments I’ve shown have been personal attacks. They seem to say that I would be okay with . and $ if only I understood Haskell (or math) better. I think these types of comments are shitty, but I guess they’re to be expected on the internet.

These next comments actually criticize Flow, which I welcome. Because Flow allows you to express operations as a pipeline, it can look imperative. Some people don’t like that, which confused me. Avoiding imperative-looking code in functional programming doesn’t help anyone. It’s like saying you shouldn’t use the imperative-looking for because the functional-looking traverse is better somehow. Sometimes it makes more sense to think about things imperatively, regardless of how they actually get evaluated. That’s the whole idea behind do notation!

I want to express things as to what they are in terms of value and not in terms of how to get to these values, which is what Imperative Programming does. — evohunz

I don’t see function application as English prose (read left to right), but rather a mathematical construct read from the argument. — amyers127

This argument reminds me of the useless use of cat. For the uninitiated, cat ends up in a lot of places where it is “useless” because the program you pipe it into can do the same thing. For example, these commands are all identical:

$ cat a-file | grep a-pattern
$ grep a-pattern < a-file
$ grep a-pattern a-file

Depending on the circumstances, any one of those could be the best way to express yourself. Flow tries to give you that freedom with Haskell. Consider the following equivalent expressions:

aValue |> aFunction |> anotherFunction
anotherFunction . aFunction $ aValue
anotherFunction (aFunction aValue)

I didn’t mean to imply that you should use Flow all the time. I think Flow allows you to write more understandable Haskell in certain circumstances. I don’t anticipate it completely replacing the existing idioms. Perhaps I should have expressed that in my last blog post.