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.

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

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.

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.

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.

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.

Luckily Haskell supports impure functional programming too ...

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