
Reasons for not learning functional programming - wiradikusuma
https://plus.google.com/118237818911466999581/posts/41cTMuZNHKK
======
lmkg
Well, if your goal is to play Devil's Advocate, then here's one: FP makes
simple things hard. Instead of simple for-loops you have to use recursion, if
you want to do something as primitive as assigning to a variable you have to
learn about monads, instead of control flow operators you have to use
functions-as-values, and the type system is based on a foundational
mathematical topic called lambda calculus.

Just to be clear: I'm a fan of FP, and I don't think it makes simple things
hard. I just think that debunking the above would be illuminating.

~~~
michaelfeathers
That's a good devil's advocate position, but it's easy to counter. For-loops
are replaced with maps, folds, and filters more often than recursion, and
assigning to a variable is only a primitive because we were brought up that
way.

Rather than saying "simple to hard", I'd say "familiar to unfamiliar."

~~~
pvidler
Do maps, folds and filters become as natural as for-loops in time? (If you
have already been exposed to more traditional techniques). They strike me as
similar to regular expressions, in the sense that however long I spend using
them I will always have to think it through carefully when I encounter a new
use.

By contrast, a for-loop is spelled out for me. They are certainly longer, but
I guess they match my thought process more closely. I suppose the question is,
do I think this way because of my prior exposure to for-loops, or would it be
the same if I was exposed to functional programming first? I'm really not
sure.

~~~
Zak
Yes, map, reduce and filter feel much more natural to me than explicit loops
for their respective use cases. Let's try writing an example in English:

    
    
        Give me the items from the collection foo for which the function bar returns true.
    
        Create an empty collection baz and a counter i with a value of 0. Until i reaches the length of the collection foo, do the following, then increment i and repeat: call the function bar with the element of foo at position i. If bar returns true, append the element to baz. After the loop is complete, return baz.
    

The for loop is pretty awkward just to express in English, while the filter is
straightforward enough that most non-programmers would have a pretty solid
understanding of what they'll get.

~~~
pvidler
Fascinating, thanks. I would have said that the for-loop is at least somewhat
intuitive -- the step-by-step (lather, rinse, repeat) nature resembles the way
most instruction sets are written. Not to mention flow charts, which most
people have been exposed to at some stage.

Do you have any advice for languages and techniques for getting the necessary
exposure to these concepts? I'm not in a position to use FP through work, so
I'd need some easy intro and way to practice.

~~~
Chris_Newton
_Do you have any advice for languages and techniques for getting the necessary
exposure to these concepts?_

Functional programming tends to emphasize data flow and leave control flow as
an (often hidden) implementation detail. So, I find it’s helpful to think of
algorithms in terms of transformations of data rather than series of
instructions.

For example, what values do I start with, and are they in (unordered) sets,
(ordered) sequences, or something more intricate? Then, what do I want to end
up with?

Now, how can I get from one to the other via a series of transformations or
combinations of the data? Am I turning one set/sequence/whatever into another,
operating on the individual elements? If so, that’s probably some sort of map
operation. Am I combining element of a sequence somehow? If I’ve already got a
sequence, that’s probably a reduce or something like it. But what if I’ve only
got an unordered set? Then maybe I need to impose some ordering first. Can
that order be arbitrary, or is there really some implicit order that gets me
to working with a well-defined sequence? Maybe I need to combine multiple
sequences somehow. If each element in one sequence corresponds to a single
element in the other, that’s probably some sort of zip operation. If it’s a
many-to-many matching, that might be some sort of nested recursive algorithm
that walks each sequence one inside the other, or maybe I can generate an
outer product so I’ve got a one-dimensional list of all possible pairs and
then do something simpler with that.

After a while, you get to recognise basic underlying data structures like
sets, sequences, and trees, and you get to recognise which common operations
make sense for each type. You can map just about anything, but to reduce you
need a sequence. You can make a sequence from a set by imposing an arbitrary
order if necessary. You can make a sequence from a tree in several ways, for
example by traversing it in depth-first or breadth-first. And so on.

Sometimes you’ll need to do something that isn’t a convenient, ready-made
transformation like a filter or zip, and at that point you start thinking
about using recursion to traverse the relevant data structure(s) “manually”.
Once you’ve done that a few times, you might start to see new kinds of
recurring logic within your code, which you can abstract away into their own
higher order functions to join the standard toolbox next to fold and friends.

You _can_ get into all kinds of fun and games with representing effects and
controlling the interactions between them as well. However, I’d suggest that
if you can start to think of simple problems in terms of things like
transforming and combining structured data and then move on to implementing
more advanced algorithms by combining the simpler building blocks, that’s
probably the best way to get your feet wet without getting out your depth in
the early days.

------
ceol
My biggest reason is that I have to weigh learning an entirely new paradigm
versus bettering myself in a paradigm I already know that's currently making
me money. In short, I need it to be _worth it_.

~~~
bunderbunder
Getting a good handle on FP has been one of the best things I've done to
better myself in the paradigm I get paid to write code in by day.

I haven't personally found a whole lot to warrant the "functional programming
as universal panacea" meme that's been so popular lately. But most decent
imperative languages have pretty good support for many features of functional
programming nowadays, and spending some time working in a functional language
will teach you to make better use of those features of your native one. To
that extent, polishing my FP skills has led me to like my by-day language (C#)
even better.

Even failing that, learning new ways to think about and code solutions for
problems can only improve your ability to think about and code solutions for
problems.

~~~
alinajaf
> "functional programming as universal panacea"

To me at least, the endgame for any complex system that you end up with a
large number of modular decoupled components. This endgame looks more or less
the same today in both functional and object oriented paradigms.

The difference is how you get there. In functional programming, you start with
modular, decoupled components. With OOP, you make a mess and you 'refactor'
into somewhat modular, somewhat decoupled components later.

~~~
bunderbunder
In OOP I start with modular, decoupled components. And to answer the other
popular complaint about OOP, the vast majority of my classes are not stateful.
Just like for the preferred practice in functional programming, I try to only
introduce state when practicality demands it.

Making a mess and then (maybe) refactoring later is a regrettably common
practice among may object-oriented programmers. But it's not a fundamental or
necessary approach. It's just a bad habit that refuses to die. Might die
faster if people who've been taught better practice within the functional
programming sphere would quit trying to suggest that everything outside the
(supposed) ivory tower is irretrievably corrupt and barren.

And while we're at it, 'functional' and 'object-oriented' are orthogonal
characteristics. There are a whole lot of object-oriented functional languages
out there.

~~~
spacemanaki
> And to answer the other popular complaint about OOP, the vast majority of my
> classes are not stateful.

Do you mean that they don't have any mutable state? What's a stateless class
in an OOP language except a bunch of namespaced functions?

~~~
bunderbunder
Sorry, I should have said 'immutable' instead.

------
_delirium
If it's intended as a rebuttal of common objections, I'd probably include
something about efficiency (the runtime and/or memory variety).

------
zackmorris
I think the divide between imperative and functional programming is largely an
arbitrary one. If you write a for-loop where each iteration doesn't refer to
another iteration, then the compiler should be able to swap between either
notation on the fly.

So I'm frustrated that we haven't adopted a kind of "bridge" programming with
immutable data, and dealing with the transformations that are being done.
Basically everything would be a black box, like a series of small simple
programs running in the same heap. Like a unix VM running inside the program,
and just pipe data around.

Yes, functional programming makes easy things hard, and imperative programming
makes strong things weak, but anymore I think of it as limitations in compiler
and mindset more than anything else.

------
russell
In the spirit of the original article and its comments:

My wife is imperative. I wont be able to talk to her anymore.

------
ExpiredLink
> Reasons for not learning functional programming

It's a fad, a hype* - already beyond the "Peak of Inflated Expectations",
quickly moving towards the "Trough of Disillusionment".

*) <http://en.wikipedia.org/wiki/Hype_cycle>

~~~
jerf
A case can be made that that happened in the 80s (Lisp & AI Winter being the
headline acts), and what we're actually seeing today is the climb up the (
_ahem_ , Gartner's term, not mine) "Slope of Enlightenment".

------
joeld42
Because you can't write pac-man using it. <http://prog21.dadgum.com/23.html>

------
malkia
Job creation is one of the strong benefits of modern-day OO.

------
griffindy
didn't understand it was joke until I read the comments. unless it was never
meant to be a joke...

~~~
jgeralnik
You missed the intro

    
    
      I'm trying to write a blog post for O'Reilly publicising
      the tutorials at CUFP, and was going to structure it
      around "10 reasons for not learning functional
      programming" rebutting each of them. Here's my list of 11
      (so far) … any more ideas?

