Functional programming isn't the answer

I call code in Haskell's IO imperative. If you are tempted to call it pure functional, read this:

http://conal.net/blog/posts/the-c-language-is-purely-functio...

I'm pretty sick of all high-level languages actually. I even wrote my own functional programming language "Fexl", and I'm sick of it too. Here's a totally general purpose quicksort:

    # (sort keep compare xs) sorts the list xs using the three-way comparison
    # function.  It keeps duplicates if the keep flag is true, otherwise it
    # discards them and returns only the unique entries.

    \sort =
        (@\sort\keep\compare\xs
        xs [] \x\xs
        \lo = (filter (\y compare y x T F F) xs)
        \hi = (filter (\y compare y x F keep T) xs)
        \sort = (sort keep compare)
        append (sort lo) [x; sort hi]
        )

I'm tired of all of it. The language I really like is plain old C.

To handle arbitrary strings reliably, I can just use this code:

https://github.com/chkoreff/Fexl/blob/master/src/str.h

https://github.com/chkoreff/Fexl/blob/master/src/str.c

To deal with dynamic allocation, detecting any memory leaks upon program exit, I use this:

https://github.com/chkoreff/Fexl/blob/master/src/memory.h

https://github.com/chkoreff/Fexl/blob/master/src/memory.c

For high-speed buffering of data, one character at a time, I can use this:

https://github.com/chkoreff/Fexl/blob/master/src/buf.h

https://github.com/chkoreff/Fexl/blob/master/src/buf.c

Functional programming is in vogue right now, just as object-oriented was a few decades ago. The hype will fade, and just like any other programming paradigm (including object-oriented) there will be use cases where it is and is not the most appropriate.

I wish we could all ignore these hype trains.

The article appears to be flamebait.

The main point is trivial because it applies to nearly every single technique/tool/language/framework: "X is not perfect. X can/should not be applied in all situations. X must be augmented by Y. X is a means to an end, not an end unto itself." etc.

It mixes the trivial, obviously true ("Every technique has to be measured on its own, independent of weather or not it’s 'functional'") with that sure to offend ("The Religion of FP").

I don't see any real insight. What does it have to say that we didn't already know?

I don't think this trivial algorithmic example even does a good job at being the straw man in this argument.

Yeh, he's right in that its another means to an end, but where's the comparison to other means? This just seems like a bash on FP, rather than an intelligent discussion on what can give us a better answer.

The real benefit is immutability, the rest is syntax sugar.