4 ms·
Functional programming absolutely has its use cases, and I love a bit of functional style thrown into imperative language one hundred percent. That being said,
by cheeze 5y ago
Functional programming absolutely has its use cases, and I love a bit of functional style thrown into imperative language one hundred percent.
That being said, I often end up arguing with 'pure functional programmers' at work - they can be incredibly hard to work with and married to the idea that _everything needs to be functional_ because its their preference, even though your average college student is going to be able to pick up and iterate on code that just uses a damn for loop or whatnot.
I _like_ functional, I find it incredibly useful, but like everything else, its just a tool to solve a problem and there are tradeoffs.
But some of the most annoying and must-do-things-academically-because-look-how-cool-monads-are this-is-the-only-proper-way people are very vocal about functional, which is a pretty big turnoff IMO.
Haskell is a good example. There are totally cases where Haskell will make your life easier. But if you're trying to reinvent the wheel and redefine our architecture by injecting haskell everywhere you can because _you like it_, that drives me absolutely bonkers.
- jimmaswell 5y agoWhat are the use cases you've seen functional programming in real business?
- pharmakom 5y agoPrecisely modelling the business domain using immutable objects and pure functions is a killer feature of FP for the real world.
- tephra 5y agoI'd imagine one of the more common use cases is data processing. At my last job I was part of a team that built a data processing platform and we did it in a mostly functional style.
- dnautics 5y agohttps://www.youtube.com/watch?v=yTkzNHF6rMs https://www.youtube.com/watch?v=yTkzNHF6rMs Of course this approach requires an impure functional language (so you can have side-effect calls).
- theCodeStig 5y agoHave you tried to see the pure FP viewpoint, rather than argue?
- sweezyjeezy 5y agoI have personally been from an FP acolyte and back, there's some great stuff there, it will improve your non-FP code to learn an FP language. That said, bending over backwards to fit the FP mindset is suboptimal, the same way as writing fully OO code is. e.g. IMO some stuff from FP should _generally_ be avoided in favour of making code easier to read and debug - e.g. recursion, maps, monads, generators etc. etc.