Return to Answer

I basically agree with FrustratedWithFormsDesign's answer, but you also asked how learning the new paradigm helps develop one's skills. I can give a couple of examples from my own experience.

Since learning functional programming, I'm much more conscious about which concepts I work with are more naturally considered as "objects" (generally where mutation makes sense) and which are more naturally considered as immutable "values" (I think there's an important distinction, touching on where OO makes sense vs. when FP makes sense, but that's just my opinion).

I notice where my code includes side effects, and I'm more careful to isolate those places, making more of my functions "pure" functions. This greatly improves the testability of my OO code.

I'm more conscious about cycles in my data representation. (For example, I don't think you can write a function to convert a linked-list into a doubly-linked list in Haskell, so you do notice cycles quite a bit more in that language.) Avoiding cycles reduces the amount of synchronization you need to perform for your data structures to be internally consistent, easing the burden in sharing these structures between threads.

I'm more likely to rely on recursion (scheme's recursive looping constructs are things of beauty). Dijkstra touched on the importance of this in Notes on Structured Programming - recursive algorithms map very directly to mathematical induction, which he suggests is the only means to intellectually prove our loops correct. (I don't suggest that we must prove our code correct, but that the easier we make it for ourselves to do so, the more likely it is that our code is correct.)

I'm more likely to use higher-order functions. John Hughes' paper, Why Functional Programming Matters. It emphasizes the composability you get from employing functional programming techniques, higher-order functions playing a major role.

Also, as touched on in Jetti's answer, you'll find that a lot of FP ideas are being incorporated into newer OO languages. Ruby and Python both provide many higher-order functions, I've heard LINQ described as an attempt to bring support for monadic comprehensions into C#, even C++ now has lambda expressions.

I basically agree with FrustratedWithFormsDesign's answer, but you also asked how learning the new paradigm helps develop one's skills. I can give a couple of examples from my own experience.

Since learning functional programming, I'm much more conscious about which concepts I work with are more naturally considered as "objects" (generally where mutation makes sense) and which are more naturally considered as immutable "values" (I think there's an important distinction, touching on where OO makes sense vs. when FP makes sense, but that's just my opinion).

I notice where my code includes side effects, and I'm more careful to isolate those places, making more of my functions "pure" functions. This greatly improves the testability of my OO code.

I'm more conscious about cycles in my data representation. (For example, I don't think you can write a function to convert a linked-list into a doubly-linked list in Haskell, so you do notice cycles quite a bit more in that language.) Avoiding cycles reduces the amount of synchronization you need to perform for your data structures to be internally consistent, easing the burden in sharing these structures between threads.

I'm more likely to rely on recursion (scheme's recursive looping constructs are things of beauty). Dijkstra touched on the importance of this in Notes on Structured Programming - recursive algorithms map very directly to mathematical induction, which he suggests is the only means to intellectually prove our loops correct. (I don't suggest that we must prove our code correct, but that the easier we make it for ourselves to do so, the more likely it is that our code is correct.)

I'm more likely to use higher-order functions. John Hughes' paper, Why Functional Programming Matters. It emphasizes the composability you get from employing functional programming techniques, higher-order functions playing a major role.

Also, as touched on in Jetti's answer, you'll find that a lot of FP ideas are being incorporated into newer OO languages. Ruby and Python both provide many higher-order functions, I've heard LINQ described as an attempt to bring support for monadic comprehensions into C#, even C++ now has lambda expressions.

I basically agree with FrustratedWithFormsDesign's answer, but you also asked how learning the new paradigm helps develop one's skills. I can give a couple of examples from my own experience.

Since learning functional programming, I'm much more conscious about which concepts I work with are more naturally considered as "objects" (generally where mutation makes sense) and which are more naturally considered as immutable "values" (I think there's an important distinction, touching on where OO makes sense vs. when FP makes sense, but that's just my opinion).

I notice where my code includes side effects, and I'm more careful to isolate those places, making more of my functions "pure" functions. This greatly improves the testability of my OO code.

I'm more conscious about cycles in my data representation. (For example, I don't think you can write a function to convert a linked-list into a doubly-linked list in Haskell, so you do notice cycles quite a bit more in that language.) Avoiding cycles reduces the amount of synchronization you need to perform for your data structures to be internally consistent, easing the burden in sharing these structures between threads.

I'm more likely to rely on recursion (scheme's recursive looping constructs are things of beauty). Dijkstra touched on the importance of this in Notes on Structured Programming - recursive algorithms map very directly to mathematical induction, which he suggests is the only means to intellectually prove our loops correct. (I don't suggest that we must prove our code correct, but that the easier we make it for ourselves to do so, the more likely it is that our code is correct.)

I'm more likely to use higher-order functions. John Hughes' paper, Why Functional Programming Matters. It emphasizes the composability you get from employing functional programming techniques, higher-order functions playing a major role.

Also, as touched on in Jetti's answer, you'll find that a lot of FP ideas are being incorporated into newer OO languages. Ruby and Python both provide many higher-order functions, I've heard LINQ described as an attempt to bring support for monadic comprehensions into C#, even C++ now has lambda expressions.

I basically agree with FrustratedWithFormsDesign's answer, but you also asked how learning the new paradigm helps develop one's skills. I can give a couple of examples from my own experience.

Since learning functional programming, I'm much more conscious about which concepts I work with are more naturally considered as "objects" (generally where mutation makes sense) and which are more naturally considered as immutable "values" (I think there's an important distinction, touching on where OO makes sense vs. when FP makes sense, but that's just my opinion).

I notice where my code includes side effects, and I'm more careful to isolate those places, making more of my functions "pure" functions. This greatly improves the testability of my OO code.

I'm more conscious about cycles in my data representation. (For example, I don't think you can write a function to convert a linked-list into a doubly-linked list in Haskell, so you do notice cycles quite a bit more in that language.) Avoiding cycles reduces the amount of synchronization you need to perform for your data structures to be internally consistent, easing the burden in sharing these structures between threads.

I'm more likely to rely on recursion (scheme's recursive looping constructs are things of beauty). Dijkstra touched on the importance of this in Notes on Structured Programming - recursive algorithms map very directly to mathematical induction, which he suggests is the only means to intellectually prove our loops correct. (I don't suggest that we must prove our code correct, but that the easier we make it for ourselves to do so, the more likely it is that our code is correct.)

I'm more likely to use higher-order functions. John Hughes' paper, Why Functional Programming Matters. It emphasizes the composability you get from employing functional programming techniques, higher-order functions playing a major role.

Also, as touched on in Jetti's answer, you'll find that a lot of FP ideas are being incorporated into newer OO languages. Ruby and Python both provide many higher-order functions, I've heard LINQ described as an attempt to bring support for monadic comprehensions into C#, even C++ now has lambda expressions.

I basically agree with FrustratedWithFormsDesign's answer, but you also asked how learning the new paradigm helps develop one's skills. I can give a couple of examples from my own experience.

Since learning functional programming, I'm much more conscious about which concepts I work with are more naturally considered as "objects" (generally where mutation makes sense) and which are more naturally considered as immutable "values" (I think there's an important distinction, touching on where OO makes sense vs. when FP makes sense, but that's just my opinion).

I notice where my code includes side effects, and I'm more careful to isolate those places, making more of my functions "pure" functions. This greatly improves the testability of my OO code.

I'm more conscious about cycles in my data representation. (For example, I don't think you can write a function to convert a linked-list into a doubly-linked list in Haskell, so you do notice cycles quite a bit more in that language.) Avoiding cycles reduces the amount of synchronization you need to perform for your data structures to be internally consistent, easing the burden in sharing these structures between threads.

I'm more likely to rely on recursion (scheme's recursive looping constructs are things of beauty). Dijkstra touched on the importance of this in Notes on Structured Programming - recursive algorithms map very directly to mathematical induction, which he suggests is the only means to intellectually prove our loops correct. (I don't suggest that we must prove our code correct, but that the easier we make it for ourselves to do so, the more likely it is that our code is correct.)

I'm more likely to use higher-order functions. John Hughes' paper, Why Functional Programming Matters. It emphasizes the composability you get from employing functional programming techniques, higher-order functions playing a major role.

Also, as touched on in Jetti's answer, you'll find that a lot of FP ideas are being incorporated into newer OO languages. Ruby and Python both provide many higher-order functions, I've heard LINQ described as an attempt to bring support for monadic comprehensions into C#, even C++ now has lambda expressions.

I basically agree with FrustratedWithFormsDesign's answer, but you also asked how learning the new paradigm helps develop one's skills. I can give a couple of examples from my own experience.

Since learning functional programming, I'm much more conscious about which concepts I work with are more naturally considered as "objects" (generally where mutation makes sense) and which are more naturally considered as immutable "values" (I think there's an important distinction, touching on where OO makes sense vs. when FP makes sense, but that's just my opinion).

I notice where my code includes side effects, and I'm more careful to isolate those places, making more of my functions "pure" functions. This greatly improves the testability of my OO code.

I'm more conscious about cycles in my data representation. (For example, I don't think you can write a function to convert a linked-list into a doubly-linked list in Haskell, so you do notice cycles quite a bit more in that language.) Avoiding cycles reduces the amount of synchronization you need to perform for your data structures to be internally consistent, easing the burden in sharing these structures between threads.

I'm more likely to rely on recursion (scheme's recursive looping constructs are things of beauty). Dijkstra touched on the importance of this in Notes on Structured Programming - recursive algorithms map very directly to mathematical induction, which he suggests is the only means to intellectually prove our loops correct. (I don't suggest that we must prove our code correct, but that the easier we make it for ourselves to do so, the more likely it is that our code is correct.)

I'm more likely to use higher-order functions. John Hughes' paper, Why Functional Programming Matters. It emphasizes the composability you get from employing functional programming techniques, higher-order functions playing a major role.

Also, as touched on in Jetti's answer, you'll find that a lot of FP ideas are being incorporated into newer OO languages. Ruby and Python both provide many higher-order functions, I've heard LINQ described as an attempt to bring support for monadic comprehensions into C#, even C++ now has lambda expressions.