8 ms·

Reasons for not learning functional programming

37 points by wiradikusuma 14y ago

deleted 14y ago
[deleted]
- ceol 14y ago
  He made that list to rebut it.
  - deleted 14y ago
    [deleted]
griffindy 14y ago
didn't understand it was joke until I read the comments. unless it was never meant to be a joke...
- _delirium 14y ago
  It says at the top that he's trying to compile a list of common "why not FP" arguments so he can rebut them, as part of publicity for an O'Reilly series on functional programming.
- jgeralnik 14y ago
  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?
ceol 14y ago
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 14y ago
  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.
  - ceol 14y ago
    Thanks for your reply! That certainly gives me a bit of motivation to learn a functional language.
  - dmlorenzetti 14y ago
    This has been my experience. I've learned a bit about FP (mainly by reading books on several FP languages, and attending the SF Bay Area Functional Programmers group back when it was still meeting). However, I have never seen a reasonable way to use a true FP language in my work. Most of what I do is inherently stateful-- at the core are iterative algorithms that update vectors of state variables with small corrections until a problem converges. This is a really hard use case for a pure FP language (i.e., one that "takes away assignment") to shine. That said, learning FP has influenced the way I write the code that pumps numbers into the core update algorithms. Think using PURE and ELEMENTAL functions in Fortran, for example. And of course scientific programming has a rich history of passing functions in to general numerical algorithms. I just don't use closures, or create functions on the fly, or any of that other FP goodness.
  - alinajaf 14y ago
    > "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.
lmkg 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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.
malkia 14y ago
Job creation is one of the strong benefits of modern-day OO.
_delirium 14y ago
If it's intended as a rebuttal of common objections, I'd probably include something about efficiency (the runtime and/or memory variety).
ExpiredLink 14y ago
> 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 http://en.wikipedia.org/wiki/Hype_cycle
- jerf 14y ago
  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 14y ago
Because you can't write pac-man using it. http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html
zackmorris 14y ago
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 14y ago
In the spirit of the original article and its comments: My wife is imperative. I wont be able to talk to her anymore.

37 points by wiradikusuma 14y ago

deleted 14y ago

[deleted]

ceol 14y ago
He made that list to rebut it.
- deleted 14y ago
  [deleted]

griffindy 14y ago

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

_delirium 14y ago
It says at the top that he's trying to compile a list of common "why not FP" arguments so he can rebut them, as part of publicity for an O'Reilly series on functional programming.
jgeralnik 14y ago
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?

ceol 14y ago

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 14y ago
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.
- ceol 14y ago
  Thanks for your reply! That certainly gives me a bit of motivation to learn a functional language.
- dmlorenzetti 14y ago
  This has been my experience. I've learned a bit about FP (mainly by reading books on several FP languages, and attending the SF Bay Area Functional Programmers group back when it was still meeting). However, I have never seen a reasonable way to use a true FP language in my work. Most of what I do is inherently stateful-- at the core are iterative algorithms that update vectors of state variables with small corrections until a problem converges. This is a really hard use case for a pure FP language (i.e., one that "takes away assignment") to shine. That said, learning FP has influenced the way I write the code that pumps numbers into the core update algorithms. Think using PURE and ELEMENTAL functions in Fortran, for example. And of course scientific programming has a rich history of passing functions in to general numerical algorithms. I just don't use closures, or create functions on the fly, or any of that other FP goodness.
- alinajaf 14y ago
  > "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.

lmkg 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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.

malkia 14y ago

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

_delirium 14y ago

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

ExpiredLink 14y ago

> 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 http://en.wikipedia.org/wiki/Hype_cycle

jerf 14y ago
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 14y ago

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

zackmorris 14y ago

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 14y ago

In the spirit of the original article and its comments: My wife is imperative. I wont be able to talk to her anymore.