Disadvantages of purely functional programming
flyingfrogblog.blogspot.com
Disadvantages of purely functional programming
1–10 of 70 posts
Re: Disadvantages of purely functional programming
#2I don't get why people would use functional programming for anything. It's both more difficult and slower.
Re: Disadvantages of purely functional programming
#3I don't get why people would use functional programming for anything. It's both more difficult and slower.
When it comes to expressing logic in small composable, understandable pieces, nothing else can compete.
Unfortunately, it does have the challenges listed in the OP, so it seems to make most sense where either (a) it is ok to leave performance on the table in the interest of clarity or (b) you create a little sandbox in which you use functional programming for clarity, and something outside your sandbox compensates for the performance cost.
React and Om are examples of (b). They let you write pure functions that return the entire DOM. Then, outside that sandbox, a DOM differ makes it so you don't force the browser to re-render the entire DOM every time.
Re: Disadvantages of purely functional programming
#4I don't get why people would use functional programming for anything. It's both more difficult and slower.
Programming is both an art and a science. Art here means we don't have a hard scientific recommendations for all important cases; we have to learn tricks of the trade and use subjective judgement; naturally our programs differ widely.
Art - as something subjective - also means opinions differ on difficulty and slowness. That's perhaps why downvotes - the statement like this presented as an objective fact draws enough scepticism from those who have different experience in the subject.
Re: Disadvantages of purely functional programming
#5I found another article linked from the one linked here more interesting, but it's not about "FP" but only about Haskell:
"Why is Haskell used so little in the industry?" - http://flyingfrogblog.blogspot.de/2010/05/why-is-haskell-use...
Go and grab some popcorn before you move on to the comment section...
It's from 2010, I'd be interested in an update, just out of mild curiosity.
Re: Disadvantages of purely functional programming
#6I don't get why people would use functional programming for anything. It's both more difficult and slower.
First, functional programming is an umbrella term. This paper talks about strict FP, which is basically "no mutation", so I'll talk about that.
It's clear that some other aspects of FP, such as first-order functions, closures, etc are very useful in practice.
Immutability does have its advantages in that it supplies strong guarantees about what your code does. It avoids spaghetti code where everything can and does mutate everything else.
Myself, I tend to use whenever its advantages outweigh its inconveniences. Immutability is especially handy at interface boundaries.
Re: Disadvantages of purely functional programming
#7Harrop is known in the Haskell community for being a hater. Most of his remarks here are opinion, which is fine. Lots of people don't like Haskell - that's also fine, but pieces like these hurt the community because it will both push away newcomers and make industrial use more difficult.
Also, I've never needed an unsorted dictionary, and parallelism is actually great in Haskell. http://chimera.labs.oreilly.com/books/1230000000929/index.ht...
Re: Disadvantages of purely functional programming
#8I don't get why people would use functional programming for anything. It's both more difficult and slower.
I use functional style in C++ with lambdas and iterators. It is nothing but slow. I use functional style in Rust. It's blazing fast. Huge body of problems can be handled by simple recursion but I've yet to see non-functional programmers use it. I don't know why.
Functional style is simply better and is applicable in many languages. Modern C++ is a great example. Throw away much of OOP clunkiness, use simple functions, win! (OOP has it's place but in small quantities and with moderation).
With respect to purity I'm on the sidelines. I think what's far more important is algebraic data-types, pattern matching and value-returning conditionals (values, not statements!). Rust has them and it is great and not pure.
Re: Disadvantages of purely functional programming
#9I don't get why people would use functional programming for anything. It's both more difficult and slower.
Difficulty - Only at first. Once you get over the hump and learn to think functionally, procedural/OO starts to look like a convoluted mess.
Slower - Optimize for developer time. Same reason most people write their backends in Python/Ruby instead of C++.
Re: Disadvantages of purely functional programming
#10I found another article linked from the one linked here more interesting, but it's not about "FP" but only about Haskell: "Why is Haskell used so little in the industry?" - http://flyingfrogblog.blogspot.de/2010/05/why-is-haskell-use... Go and grab some popcorn before you move on to the comment section... It's from 2010, I'd be interested in an update, just out of mild curiosity.
the company i work at, https://obsidian.systems currently employs 10+ full-time Haskell developers. I'm not sure what the exact number is because we've been expanding lately. https://www.reddit.com/r/haskell/comments/49jjff/haskell_opp...
The answer to that 2010 blog post is that the ecosystem has dramatically improved in the last 6 years.