7 ms·
this post seems like a graphically appealing way of just making the usual "FP is better" argument, except without any other actual argument other than "In my ex
by zzzeek 6y ago
this post seems like a graphically appealing way of just making the usual "FP is better" argument, except without any other actual argument other than "In my experience most codebases have a pure functional subset, and I believe writing that subset in a pure-functional style is nearly always a win for the long-term health of the project."
in my experience I've seen codebases that are entirely object oriented where we are writing methods, not functions, or codebases that use methods or functions as appropriate, and they also have done just fine long term.
How is this article making any real argument for the former and not the latter?
- cerved 6y agousing LINQ in C# is vastly different from going full Haskell
- brundolf 6y ago> this post seems like a graphically appealing way of just making the usual "FP is better" argument I would rephrase it as "FP is a better default". A big part of my thesis is that dogmas tend to have shortcomings, which contrasts with the stereotypical "FP is better" literature. > in my experience I've seen codebases that are entirely object oriented where we are writing methods, not functions, or codebases that use methods or functions as appropriate Using X "as appropriate" is one of the things I was hoping to encourage :) As for "most codebases have a pure functional subset", perhaps what I should have said is "most projects' domains have a pure functional subset". The idea being that some slice of the business logic is naturally just deriving values from other values, and that if you isolate that substrate you get many of the benefits people talk about FP having (lack of sprawling side-effects, composability, easy parallelization, etc), without the more extreme costs like having to learn what an IO-Monad is
- cerved 6y agoMonads are mainly hard to grasp because Monad is a terrible name and all explanations overly convoluted
- brundolf 6y agoI think there are monads that are reasonably intuitive - Promises, Option types, etc (I know promises are ~technically~ not monads). It's mainly the practice of incorporating state into a stateless language and all the weirdness that entails that's the problem, in my view (so, specifically the IO monad)
- andreareina 6y ago> (I know promises are ~technically~ not monads) Do you mean promises in general, or the concrete implementation in js? I've got it in my head that promises the pattern are monadic, but js stuffs it (e.g. by up by making .then() automatically flatten if the callback also returns a promise)
- lmm 6y agoUsing an IO monad first is putting the cart before the horse, unless your business problem is fundamentally about IO. If you want to be able to express the business logic as functions then you need to use monads to encapsulate the complex parts of the implementation (or you'll end up with an ad-hoc, informally specified, bug ridden implementation of half of them), and once you're comfortable with them you'll probably find them useful for giving you explicit-but-not-too-verbose control over IO as well.