
Disadvantages of purely functional programming - YAFZ
http://flyingfrogblog.blogspot.com/2016/05/disadvantages-of-purely-functional.html
======
Roboprog
It seems to me that yes, you need an "escape hatch" in an FP language to make
your updates.

It would be nice if the language required such functions, and the modules in
which they reside, to be flagged. (I don't know if Haskell does something like
this with mutation, or not)

It also seems that an "actor model" would be a good way to encapsulate the
updates in an otherwise FP program by having a loop/reduce/fold wrapped around
the mutable data responding to request-events and generating responses. This
allows the other pure/immutable/idempotent type of code to remain isolated
from it.

~~~
dottedmag
Flagged like "State T" in function type, which Haskell has had since ~1995?

~~~
tome
Or IO, or ST, or STM, or any other number of Haskell features that Roboprog
has correctly predicted to exist.

------
efnx
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/1230000000929/index.ht...](http://chimera.labs.oreilly.com/books/1230000000929/index.html)

~~~
yummyfajitas
This is an ad hominem attack, and a fallacy. He may hate Haskell - so what?
Are any of his critiques incorrect?

~~~
lispm
Harrop is a known troll. This is not an attack.

It's a fact.

> Are any of his critiques incorrect?

Probably. That's what makes a real troll effective.

Harrop had a business around OCaml and later F#. He often posted to other FP
communities controversial statements, with added links to his offerings. He
started not knowing much about those other languages or FP in general, but in
later years he learned from people and his attacks got more sophisticated. His
controversial marketing did not make him many friends, though.

Going after the real or perceived drawbacks of purely functional programming
in Haskell and also its data structures was one of his favorite targets.

Before that he used similar tactics in the Lisp community. For example I
remember that he once said that Lisp is not used and this can be seen that
there are no Lisp mailing list archived at GMANE. Well, that one was easy. I
explained to him that GMANE has a top hierarchy for Lisp, where all the
mailing lists are. But that did not stop him, he discovered or made up many
more problems with Lisp. ;-)

------
LionessLover
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...](http://flyingfrogblog.blogspot.de/2010/05/why-is-haskell-used-so-
little-in.html)

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.

~~~
danharaj
the company i work at, [https://obsidian.systems](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...](https://www.reddit.com/r/haskell/comments/49jjff/haskell_opportunities_at_obsidian_systems/)

The answer to that 2010 blog post is that the ecosystem has dramatically
improved in the last 6 years.

~~~
alecco
Sorry, but that's no proof.

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

~~~
TheCoelacanth
It's also setting a very high bar for functional languages to clear. Off the
top of my head I can't even name a garbage collected language that has reified
generics and value types.

~~~
krallja
> Off the top of my head I can't even name a garbage collected language that
> has reified generics and value types.

C#

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

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

~~~
Mathnerd314
Any imperative algorithm / data-structure, e.g. union-find, can be implemented
purely by using an IntMap for memory and a State monad, with roughly
equivalent performance: [https://hackage.haskell.org/package/union-
find](https://hackage.haskell.org/package/union-find)

As to whether that actually counts as "purely functional programming", I can't
say. Honestly the whole term seems quite misleading.
[https://chadaustin.me/2015/09/haskell-is-not-a-purely-
functi...](https://chadaustin.me/2015/09/haskell-is-not-a-purely-functional-
language/)

~~~
sclv
The reason he cites union-find is that it is one of the only significant data
structures where sustained research hasn't either produced an immutable
version with the same performance as the mutable one or demonstrated that one
can't exist.

It's a great puzzle, but it's not a huge drawback because subbing in IntMap or
something really _does_ give adequate performance for typical union-find cases
(unification or the like). Which is to say, the performance gap left to be
closed is almost certainly _not_ where the important improvements to
unification algorithms are made (which have to do with being able to impose a
lot more particular structure on the types of things being unified, etc).

------
chubot
Good points, although I agree that a lot of them boil down to similar
statements.

I have settled on a style of doing "functional-like" programming in Python and
C++. It's more about the high level architecture than low level coding
details.

It means being very paranoid and rigorous about state -- but still having
great tools to express it! For example: Using ZERO mutable globals, and
passing state in as a parameter to functions. Using immutable/persistent data
structures. These techniques are done very naturally and effectively in Python
and C++. You just have to be disciplined.

To me there's no real advantage to expressing something like "split a string
by a delimiter" in a purely functional style. Either way, you have a trivial
referentially transparent function you can reuse without causing complexity in
your program. You might as well do the obvious imperative thing.

However there IS a benefit to threading state explicitly throughout the
application, and encapsulating it in OBJECTS (yes objects).

For me, the thing that sealed the deal against functional languages for "real
work" was trying to write a production quality sh parser.

I went down a long path of trying to do this first in OCaml and then in Lisp.
The VERY first thing that hits you over the head -- lexing -- is heavily and
inherently stateful. ocamllex and ocamlyacc to me are evidence of this paucity
and poverty of purely functional solutions. They're just transliterating
solutions from C. Well I might as well use C then.

Actually, I decided to use C++, which was like my 5th choice as language.
Aside from headers and compile times, it's a good choice. I use "functions and
data" (a la Rich Hickey).

Except my functions and data are both CLASSES. Data objects are basically
structs, except they can do things like print themselves and answer simple
queries based on their values, which helps readability (e.g. 1 liners, like
word.AsFuncName() ).

Function objects are simply classes with configuration passed to constructors.
That usually have a single method, but multiple methods are also often useful.
Calling this method is basically equivalent to calling a curried function. But
this is supremely useful for both compilers and servers, because often you
have config/params that is constant once you reach main(), and then you have
params that vary per request or per file processed. Many functions depend on
both, and it's cleaner to separate the two kinds of params.

So both "functions and data" are effectively and usefully implemented as
classes. The key is to make some classes like functions, and some classes like
data. And have more of a bipartite dependency graph, where functions depend on
data, and data depends on functions.

When all your classes are an equal mix of data and behavior, that's when they
start getting "hard-coded" weird-shaped dependencies, and your program turns
into fragile spaghetti. Functions and data are a useful architectural
technique, and to me it doesn't have that much to do with Clojure or Lisp,
although Hickey is certainly a great advocate.

~~~
pjmlp
I dabble occasionally in FP languages and I am a bit fan of the ML family.

However I came to the conclusion that the latest improvemetns in C#, Java and
C++ are already quite good for doing FP style programming.

Yes, I feel a bit dirty not being able to use more pure FP languages, but I
have to work within the context that customers allow us to do.

Although it feels like blasphemy, C++14/7 can be seen almost as an impure
Haskell with curly brackets.

~~~
chubot
Yes I agree. It's MUCH easier to do FP in modern OO languages than OOP in
functional languages. So with the OO languages, you're simply in a better
position to solve real problems.

Learning OCaml really improved my appreciation of C++. C++ code is just all
over the place, but you can write it in a pretty clean style (admittedly with
considerable effort.)

Related: [https://akabe.github.io/evilml/](https://akabe.github.io/evilml/)

~~~
pjmlp
Have you ever learned Smalltalk?

Thanks to support for blocks (lambda), Smalltalk collections already had LINQ
style programming, aka algorithm.h support, for example.

Nice link.

~~~
chubot
I actually haven't ever used SmallTalk, although I understand Ruby is
considerably influenced by it (blocks, as far as I understand). Any pointers
are appreciated though.

I'm more of a Python person, and Python doesn't really use blocks. I like the
duality mentioned this post:
[http://journal.stuffwithstuff.com/2013/01/13/iteration-
insid...](http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-
out/) (In summary it's for item in L: f(item) vs L.each(|item| ...)

I don't really think of C++ algorithm.h as LINQ ? I guess I don't use it that
much. To me that is more "functional in the small", e.g. map or filter with
lambdas, vs. "functional in the large". But I'd be interested to hear more
details on this analogy.

~~~
pjmlp
There are lots of Smalltalk books here, including the original ones from Xerox
PARC.

[http://stephane.ducasse.free.fr/FreeBooks.html](http://stephane.ducasse.free.fr/FreeBooks.html)

The best free implementations to play around are Squeak and Pharo.

[http://squeak.org/](http://squeak.org/)

[http://squeak.org/](http://squeak.org/)

Or if you want to avoid installing anything, Amber gives some taste of it.

[http://amber-lang.net/](http://amber-lang.net/)

Now, regarding the LINQ like stuff, in Smalltalk doing this type of stuff was
already possible back in those days.

    
    
        |a|
        vec := #(1 2 3 4 5 6). 
        sumPairs := (vec select: [:x | (x \\ 2) = 0]) inject: 0 into: [:l :r | l + r].
    

Yes, that is what I was thinking of. The other part, immutable data and such,
isn't that possible to practice in large teams. But I do make use of it in
personal projects.

------
tome
Luckily Haskell supports impure functional programming too ...

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

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

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

~~~
braythwayt
If your data is immutable, in what sense is your code not 'Functional
Programming?'

"It's OO, and it can't be both OO and FP."

Hmmm.

