Disadvantages of purely functional programming • Hacker News Board

Re: Disadvantages of purely functional programming

#11

Post by striking » Sun, Jun 05, 2016, 4:31 PM UTC

efnx wrote: post #7

Harrop 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…

I like Haskell, and I use it once in a while. The thing is, I like knowing what my tools are capable of. That includes wanting to know their limits.

This piece, to me, seems well-researched and factual. It's not perfect, but it's good. It has plenty of good citations for areas that aren't simply opinionated. A piece that is honest about the shortcomings of a piece of software can only help that software's community.

You claim this piece will push away newcomers. As a newcomer to Haskell, I disagree. There are good things and bad things to every language. What does actually push away newcomers are the pitfalls that they're not aware of.

Also, consider the fact that even though you don't need something out of a language, someone may. And those people will now know to avoid Haskell for those things they can't get.

Re: Disadvantages of purely functional programming

#12

Post by danharaj » Sun, Jun 05, 2016, 4:36 PM UTC

This post lists 9 points, but the first 7 are all variations of "mutable data structures suck in a pure language!" and the other 2 are "look at all these fucking idiots who talk about purely functional programming!"

So the first 7 points are true because pure functional programming, by definition does not support mutable data structures very well. It is what it says on the tin.

If you go on stack overflow you'll find no shortage of ill-informed, unhelpful input about imperative programming languages. I think it's very strange to call a social phenomenon that is universal in software that affects every language community is a disadvantage of something as broad as "purely functional programming". If you want good discussion, go on the mailing lists or the IRC channels. #haskell is a very good channel with a lot of active professionals who love answering questions.

I am a professional Haskell programmer, AMA.

Re: Disadvantages of purely functional programming

#13

Post by skybrian » Sun, Jun 05, 2016, 4:43 PM UTC

danharaj wrote: post #12

This post lists 9 points, but the first 7 are all variations of "mutable data structures suck in a pure language!" and the other 2 are "look at all these fucking idiots who talk about purely functional programming!" So the first 7 points are true because pure functional programming, by definition does not support mutable data structures very well. It is what it says on the tin. If you go on stack overflow you'll find…

At least point 4 seems to be about algorithms, not data structures? That is, there's nothing up front that says graph algorithms must be faster using mutable data structures, but that is apparently the case, so far.

Re: Disadvantages of purely functional programming

#14

Post by theseoafs » Sun, Jun 05, 2016, 4:44 PM UTC

GreaterFool wrote: post #8

xyzzy4 wrote: post #2

I 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…

> 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.

Stack overflows.

Re: Disadvantages of purely functional programming

#15

Post by sklogic » Sun, Jun 05, 2016, 4:44 PM UTC

xyzzy4 wrote: post #2

I don't get why people would use functional programming for anything. It's both more difficult and slower.

There are cases where referential transparency is essential, so it worth tolerating all the FP issues to get there.

Also, there is a lot of cases where you need a total language with all its guarantees.

Re: Disadvantages of purely functional programming

#16

Post by DrJokepu » Sun, Jun 05, 2016, 4:48 PM UTC

norswap wrote: post #6

xyzzy4 wrote: post #2

I 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 mu…

I agree that immutability is very useful, but you don't really need any kind of FP to use immutability, do you?

Re: Disadvantages of purely functional programming

#17

Post by lmm » Sun, Jun 05, 2016, 4:55 PM UTC

skybrian wrote: post #13

danharaj wrote: post #12

This post lists 9 points, but the first 7 are all variations of "mutable data structures suck in a pure language!" and the other 2 are "look at all these fucking idiots who talk about purely functional programming!" So the first 7 points are true because pure functional programming, by definition does not support mutable data structures very well. It is what it says on the tin. If you go on stack overflow you'll find…

At least point 4 seems to be about algorithms, not data structures? That is, there's nothing up front that says graph algorithms must be faster using mutable data structures, but that is apparently the case, so far.

There are some graph algorithms that are probably most easily expressed with a mutable, garbage-collected graph, sure. This shouldn't be something that you have to implement yourself though; if you really need a garbage-collected graph datastructure, surely you just use a library that provides one.

Re: Disadvantages of purely functional programming

#18

Post by alecco » Sun, Jun 05, 2016, 4:55 PM UTC

danharaj wrote: post #10

LionessLover wrote: post #5

I 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.

Sorry, but that's no proof.

Re: Disadvantages of purely functional programming

#19

Post by Mathnerd314 » Sun, Jun 05, 2016, 4:56 PM UTC

theseoafs wrote: post #14

GreaterFool wrote: post #8

Earlier quoted context omitted.

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…

> 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. Stack overflows.

"Functional" languages typically have tail-call optimization and heap-allocated frames. Maybe OOP is a workaround for these missing features...

Re: Disadvantages of purely functional programming

#20

Post by GreaterFool » Sun, Jun 05, 2016, 4:59 PM UTC

Sadly, the author's chosen style is a rant and it is counterproductive.

There's plenty of words and claims are made but benchmarks or code are nowhere to be seen. Why should anyone take these claims at face value?

> Furthermore, most functional programming languages (OCaml, Haskell, Scala) are incapable of expressing a fast generic mutable hash table because they lack the killer combo of: reified generics, value types and a fast GC write barrier.

Sounds plausible? Maybe. Incapable is a strong word. I'm not an expert on mutable hash-tables so I don't know for sure. If I was making a claim that you can't implement mutable hash table without 2 square feet of badger fur and a pound of whale fat would you believe me? I would like to see a citation.

I have written a lot of Haskell and there was never a situation when I said to myself "if only Data.HashMap (unordered-containers) was faster". Just make sure you're using the right tool for the job (which might not be Haskell).

The author doesn't seem to write any code himself but instead links to code that other people have written and then makes claims about F# being better (I can't find the F# solution to parallel quicksort from one of the linked posts). I see very little value in that.