The people in the horrible, horrible world of enterprisey OO programming call this Aspect-Oriented Programming. It's often accomplished with postcompilers or source transformations and whatnot, because the languages used aren't Haskell, but it boils down to roughly the same thing.<p>AOP never really caught on because the advantages (keep logging and error handling separate from the business logic) were too small for the extra mess it added. Notably: difficult debugging, plus really weird COMEFROM-style behavior[0] if some well-meaning colleague added a little too much magic to the "aspects" (e.g. the automatically mixed-in logging code). The function suddenly does stuff that you never programmed. Good luck hunting that one down!<p>I strongly suspect this style of programming has similar downsides. Anyone tried it in large projects?<p>[0] <a href="https://en.wikipedia.org/wiki/COMEFROM" rel="nofollow">https://en.wikipedia.org/wiki/COMEFROM</a>
Free monads are very much `initial'. Compare the final approach: <a href="http://okmij.org/ftp/tagless-final/course/" rel="nofollow">http://okmij.org/ftp/tagless-final/course/</a>
I like the ideas of the article. An abstraction over IO and being able to distinguish between inherently serial operations and parallel ones on a different level are good ideas.
I do not think this article exemplifies these benefits. Instead, it focuses much time on implementing a toy DSL. I want to see what Free can do but IO cannot (functionally or stylistically).
What is really cool about this approach is that, unlike the counterpart design patterns you might find in an imperative OO language such as the Interpreter and Command patterns, within the strong-statically-typed functional languages we can rely on the guarantees the type system gives us for abstractions such as the Free Applicative to allow for optimizations that would be merely convention in a less type-enforcing type system.
<i>While ideal from a theoretical perspective, as a practical matter, can you imagine renaming a 10 GB file by first creating a copy of it, and then deleting the old version?!?</i><p><i>That kind of inefficiency is not practical for most real world programs!</i><p><i>To solve this problem, we can write an optimizing interpreter, which is a special kind of interpreter that can detect patterns and substitute them with semantically equivalent but faster alternatives.</i><p>But why?
"There are problems here I haven’t talked about, and most languages don’t make this particular style of programming very easy or performant."<p>...hmm, that's a rather big caveat arriving at the end of the article
HtDP changed the way I look at programming. But today I'm a diehard OOP fanatic. I want code that reflects the way I think, not code I have to work to understand.<p>I did not know but am not surprised to find that people write procedural Haskell. Procedural is how we all start out thinking about things. You do A, then B, to reach goal C. It takes time and experience and deliberate practice to improve upon that way of solving problems.<p>Functional moves the code in the direction of math. OOP moves in the direction of the domain. Math is harder to understand than domain logic, you will inevitably hack together an object system on top of your FP in order to implement domain logic.<p>Both styles have properties that are work better for certain domain concepts. What's nice about modern programming languages is that they build in primitives so you can use whichever style fits the concept you're fleshing out.<p>But trying to do everything functionally is ultimately counter-productive, in my opinion. It's the wrong format to declare high-level domain logic in, because high-level domain logic is that which is closest to human thought, not the underlying math.<p>Any FP 'architecture' will pretty much be object oriented. Math may treat state as ugly cruft, but humans need to group information close to where it's needed and in ways that make sense, that means state. Don't let the quest for mathematical beauty get in the way of solving your problem.
This is what i'm doing in javascript over in redux-effects: <a href="https://www.github.com/redux-effects/redux-effects" rel="nofollow">https://www.github.com/redux-effects/redux-effects</a>
I'm still new to FP, but I like how PureScript solved this problem by having an Effect Monad: <a href="http://www.purescript.org/learn/eff/" rel="nofollow">http://www.purescript.org/learn/eff/</a>
I program like this all the time in Haskell. Much of the latter bits can be replaced by so-called "mtl-style" typeclasses (used similarly to Oleg's Finally Tagless idea). I have a brief talk on this at last year's LambdaConf but didn't really give it sufficient space I suppose. I think the whole Prism/Inject machinery can be completely eliminated in this way.
I am not sure you can get rid of IO monad. It's how the Haskell programs interact with the outside world, and I think IO is a primitive that you can't build from other things.<p>But in metaphorical (architectural) sense, yeah, you can probably get rid of it and use different monadic datatypes for different parts of the program that access different pieces in the world.<p>However, I am not clear how you then combine/serialize those different monads. It seems eventually you will get something like IO monad again. I am not sure but I think there needs to be some master monad going on in all Haskell programs that (potentially) serializes all the actions to the outside world.
A modern architecture for functional programmers<p>I don't understand. This was posted yesterday (<a href="https://news.ycombinator.com/item?id=10806075" rel="nofollow">https://news.ycombinator.com/item?id=10806075</a>) and you didn't even change the shortcut nobody outside domain could possibly know.