4 ms·

Very neat article. Since I got into and out of Haskell a while back, one of the complaints I always had about breaking into the space was that it was too abstr

Very neat article. Since I got into and out of Haskell a while back, one of the complaints I always had about breaking into the space was that it was too abstract. Some of the core concepts of FP seemed really arbitrary when described without useful examples. So it's nice that the author has found a great analogy in Factorio. However, I have to say that I don't think the author succeeded in showing me "that real engineering is functional." During my tour of FP, I would always eventually run into a wall of abstraction as soon as things got more than a little bit complicated. In that sense, Factorio comes across as a bit of a contrived example. As soon as you have an algorithm that lends itself to a few pieces of mutable state in a loop with complex terminating conditions, good luck. Yes, it's theoretically possible to shoehorn things like that into the formalities of FP. However, doing so usually ends up feeling like an academic exercise more than anything else. It doesn't feel like it moves you any closer to your ultimate goals; to implement functionality more quickly, cleanly, and intelligibly. That being said, I don't regret getting into FP for a while. It's always a useful challenge to re-frame what you think you know with a different set of concepts. FP also works really well for certain kinds of problems. But I think the number of those are relatively few. This may be reaching, but I like to believe there's some historical precedent for this. After all, none other than Kurt Gödel himself eventually abandoned the λ-calculus in favor of Turing's mechanical (imperative) framing of computation. I want to believe there was some similar sentiment behind this decision. But who knows? It was probably more of a technical thing than I realize. But I've always felt on some level that an overabundance of abstraction necessarily means a lack of power.

thinkharderdev 5y ago
If you are writing a complex algorithms then an imperative style is usually going to be clearer (and more performant), but when dealing with higher-level code that is just moving data around and doing some relatively straightforward mutations, then functional code can be much more straightforward and intelligible. When you introduce concurrency then that is where I think pure FP really shines. Writing concurrent code with a pure FP effect system like ZIO is so much nicer (and safer!) than writing concurrent code in Java (or any other language I've ever used).
- gavinray 5y ago
  ZIO (particularly with the V2 release just done) explicitly aims to be beginner friendly and accessible compared to other "pure" FP and effects libraries though This isn't my experience trying to read documentation and tutorials with similar libraries in both Scala and Haskell I would go so far as to say that ZIO is like the Python of the realm. It's practically oriented and beginner friendly first and foremost. Also Scala is easier to understand than Haskell, but that's an opinion.
  - thinkharderdev 5y ago
    Agreed, I think it's not so much that pure FP is too abstract and complicated. It can actually allow really clean, usable abstractions. It's just that many pure FP libraries for some reason try to explicitly model category theoretic abstractions so you end up needing a lot of theory to be able to get your bearings. ZIO is built on the same theoretical foundations but is designed so that you don't need the theory to be productive. That's all just to say that the issue isn't FP in general, but the way FP has been implemented in beginner-unfriendly ways.

thinkharderdev 5y ago

If you are writing a complex algorithms then an imperative style is usually going to be clearer (and more performant), but when dealing with higher-level code that is just moving data around and doing some relatively straightforward mutations, then functional code can be much more straightforward and intelligible. When you introduce concurrency then that is where I think pure FP really shines. Writing concurrent code with a pure FP effect system like ZIO is so much nicer (and safer!) than writing concurrent code in Java (or any other language I've ever used).

gavinray 5y ago
ZIO (particularly with the V2 release just done) explicitly aims to be beginner friendly and accessible compared to other "pure" FP and effects libraries though This isn't my experience trying to read documentation and tutorials with similar libraries in both Scala and Haskell I would go so far as to say that ZIO is like the Python of the realm. It's practically oriented and beginner friendly first and foremost. Also Scala is easier to understand than Haskell, but that's an opinion.
- thinkharderdev 5y ago
  Agreed, I think it's not so much that pure FP is too abstract and complicated. It can actually allow really clean, usable abstractions. It's just that many pure FP libraries for some reason try to explicitly model category theoretic abstractions so you end up needing a lot of theory to be able to get your bearings. ZIO is built on the same theoretical foundations but is designed so that you don't need the theory to be productive. That's all just to say that the issue isn't FP in general, but the way FP has been implemented in beginner-unfriendly ways.