they are not
just like cargo bikes are not
Ask HN: When is pure functional programming beneficial?
81–86 of 86 posts
Re: Ask HN: When is pure functional programming beneficial?
#82Pure FP is fantastic for business applications with complex rules and logic. Shines in projects that leverage Domain Driven Design:
https://pragprog.com/titles/swdddf/domain-modeling-made-func...
Re: Ask HN: When is pure functional programming beneficial?
#83Pure functions can be visualized as static mappings from inputs -> outputs. It's like a simple table mapping inputs to outputs. Given a set of inputs, you are guaranteed the same outputs on every invocation.
In a complex world with many hidden aspects, unleashing unpleasant surprises all the time, working on purely functional components makes it easier to:
1. understand 2. test 3. debug 4. extend
These are significant benefits of the functional approach (at function/component level) in my pov.
Re: Ask HN: When is pure functional programming beneficial?
#84Pure FP is fantastic when you're doing Domain-Driven Design. Optics is brilliant for working with aggregates, functional core imperative shell to structure the dependencies within the applications and put the domain in the center, monads and applicatives to achieve different component composition styles.
Re: Ask HN: When is pure functional programming beneficial?
#85I wouldn't say there is any threshold where purely functional programming shines less. Fewer regressions and the system being more likely to "just work" makes it more fun to develop. So for interactive programs, servers, CLI tools, parsers et.c. purely functional programming is amazing. An elm developer reported that the prototype they wrote in elm ended up with less bugs than the actual production system. I personal…
> In F# ... 350k lines of C# were rewritten in 30K of F# code. Not discounting the rest of your statements (I love FP for all the reasons), but I really despise - and discount - statements like the one above. I feel they are disingenuous: "This large-ish program that grew over time with evolving needs and uses was rewritten at a later date once the requirements and use-cases were fully understood and - amazingly - we…
Of course that statement on it's own can be disingenuous, but in this case it's not only related to better understanding requirements. Lower cyclomatic complexity which functional programming lends itself to contribute to the lower LOC. The new code base had even more features than the previous one had implemented. I think it's relevant.
Re: Ask HN: When is pure functional programming beneficial?
#86Systems that have clear inputs and outputs. Parsers, compilers, stuff like that. SAT Solvers. Anything you could unit test without mock objects. Mixed initiative systems (say UI code where you call into the framework and the framework calls into you) can go either way. Sometimes you can formulate the part of your code in a pure functional way which tames the chaos, if you can’t or that formulation is unnatural the ch…
>Anything you could unit test without mock objects You can unit test without mock objects because you're following functional patterns.
Could you elaborate a little bit more? These days i write a lot of go code and i end up using mock objects for different interfaces to write unit tests. Is there another way to do this?