3 ms·

This article is a great example of how FP is currently being ruined in the same way OOP was ruined in late 80s. The paradigm had a lot of great ideas, but it be

This article is a great example of how FP is currently being ruined in the same way OOP was ruined in late 80s. The paradigm had a lot of great ideas, but it became so popular so quickly that people began to fetishize its terminology and tools, while completely forgetting what those tools were meant to accomplish.

Ididntdothis 7y ago
Very true. And you should get really worried once we have FP consultants and executives talk about FP. This seems to happen to a lot of good ideas, be it OOP, Agile or TDD. Ideologues have very compelling messages but they usually destroy what they are promoting. They don’t allow the question “why are we doing this again? Are we on the right track?”
agumonkey 7y ago
mainstream spoils everything
whateveracct 7y ago
What are the tools "meant to accomplish" exactly? I've deployed production code built with the exactly techniques in the article. it's doable and in my experience easy (modulo the large learning curve - pay it once, pay it forever) The (very simple all things considered!) top-level type signature of `Sem (State s ': r) a -> S.StateT s (Sem r) a` is also something I've used in production (different library of the same sort)
- atq2119 7y ago
  I wonder which fraction of the code actually benefits from these techniques though. Certainly I become suspicious from the fact that examples like in this article always tend to be of a very narrow, specific kind. In my experience, every worthwhile piece of code outside of certain libraries has enough of what you might call "business logic" that these theoretically clean approaches no longer apply to. This has been true across lots of domains, from games, to CRUD, to compilers, to combinatorial optimization algorithms. I'd go on to argue that the interesting core of all those problem domains was precisely in the areas that couldn't be solved using cute techniques like OP's.
Kutta 7y ago
Awful comment. The OP, while not pedagogically ideal, demonstrates proof writing along the Curry-Howard correspondence, an extremely deep topic which predates popular functional programming and OOP by decades. To liken this to "tool fetishization" is pure nonsense.

Ididntdothis 7y ago

Very true. And you should get really worried once we have FP consultants and executives talk about FP. This seems to happen to a lot of good ideas, be it OOP, Agile or TDD. Ideologues have very compelling messages but they usually destroy what they are promoting. They don’t allow the question “why are we doing this again? Are we on the right track?”

agumonkey 7y ago

mainstream spoils everything

whateveracct 7y ago

What are the tools "meant to accomplish" exactly? I've deployed production code built with the exactly techniques in the article. it's doable and in my experience easy (modulo the large learning curve - pay it once, pay it forever) The (very simple all things considered!) top-level type signature of `Sem (State s ': r) a -> S.StateT s (Sem r) a` is also something I've used in production (different library of the same sort)

atq2119 7y ago
I wonder which fraction of the code actually benefits from these techniques though. Certainly I become suspicious from the fact that examples like in this article always tend to be of a very narrow, specific kind. In my experience, every worthwhile piece of code outside of certain libraries has enough of what you might call "business logic" that these theoretically clean approaches no longer apply to. This has been true across lots of domains, from games, to CRUD, to compilers, to combinatorial optimization algorithms. I'd go on to argue that the interesting core of all those problem domains was precisely in the areas that couldn't be solved using cute techniques like OP's.

Kutta 7y ago

Awful comment. The OP, while not pedagogically ideal, demonstrates proof writing along the Curry-Howard correspondence, an extremely deep topic which predates popular functional programming and OOP by decades. To liken this to "tool fetishization" is pure nonsense.