

Functional programming isn't the answer - buffyoda
http://degoes.net/articles/fp-is-not-the-answer/

======
Chattered
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...](http://conal.net/blog/posts/the-c-language-is-purely-functional)

------
fexl
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.h)

[https://github.com/chkoreff/Fexl/blob/master/src/str.c](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.h)

[https://github.com/chkoreff/Fexl/blob/master/src/memory.c](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.h)

[https://github.com/chkoreff/Fexl/blob/master/src/buf.c](https://github.com/chkoreff/Fexl/blob/master/src/buf.c)

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

~~~
mercer
At least in my experience it's a hype that provides an 'alternative' to the OO
approach. Which I hope means that people will have more options when choosing
an approach, rather than shoehorning everything into the OO paradigm.

~~~
na85
Well yeah, that's my point. Object oriented is not always the right way to do
it. A crude example might be just how hideous and over designed an OO
HelloWorld can be.

------
mattfenwick
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?

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

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

