5 ms·

I have read a lot of articles about learning functional programming to make you a better programmer with conventional OO or imperative languages - but this does

I have read a lot of articles about learning functional programming to make you a better programmer with conventional OO or imperative languages - but this does not make sense to me. The argument is "learn these concepts that are not available in other languages to make you better at those languages". Can anyone explain?

stabbles 9y ago
I think the most apparent example is that people recognize patterns like `fold` and `map` everywhere once they've seen functional programming. This can be implemented in any language I guess. Most often you'll see explicit & imperative loops being refactored to shorter, descriptive code with anonymous functions, folds, filters and maps
deleted 9y ago
[deleted]
Jtsummers 9y ago
You can take those concepts and use them in your designs in languages where they're missing, even if you don't use FP or logic languages where they're "native".
craigsmansion 9y ago
Broadly speaking, imperative programming allows one to start coding a solution before one understands the problem. Functional programming is generally more abstract in its approach to modelling the problem. If you get the model wrong, you will not end up with a working solution, forcing you to rethink your model. While imperative programming allows you to reiterate towards a solution as you start to understand the problem better as you work towards it, it's obviously better and faster if your initial model of the problem is more accurate. Functional programming forces you to create a viable model of the problem before you start. If you can extend that discipline over to an imperative language, you will need less iteration and the resulting solution will likely be more elegant. The argument is not (or shouldn't be) about concepts, but about paradigms and discipline.
ht85 9y ago
Many people doing OO have trouble structuring their classes, splitting functionalities and responsibilities properly. OO kind of lets you do anything you want, allowing you to store data anywhere and having any kind of flow you want. It's very easy to do something that "just works", and while there is a lot of value in that, you can keep bad habits for very long. FP is a lot more constraining, and will force you to adapt how you think to fit said constraints. Having to think differently offers a different perspective on code architecture, that will eventually give you ideas applicable beyond FP languages.
- Raknarg 9y ago
  Many would argue the exact opposite, that OO is contraining and FP is much more free, allowing you to change your design model without having to redesign the entire model.
disease 9y ago
Working with functional languages has made me value and seek out simplicity in my code. Before I write a loop or create another class I'll often ask myself if there is a more simple way to solve the problem - and oftentimes there is.
matwood 9y ago
> Can anyone explain? A quick example that can be faked in any language is a pure function [1]. The functions only inputs are the set of arguments, and from those arguments returns a side-effect free result. A pure function is easy to test and easy to reason about. Contrast a pure function with an impure function that uses an objects internal state plus the arguments passed in to further tweak the state an/or return a result. It is immediately obvious the second is much harder to test and reason about. It becomes even more challenging when the object is thrown into a large system with a lot of moving parts. Even before I really started learning about true functional programming, I had been writing 'pure' functions for years because they just made sense. Even internal private methods are simpler as pure functions. Shared state is evil for many reasons and should be avoided if possible. [1] https://en.wikipedia.org/wiki/Pure_function https://en.wikipedia.org/wiki/Pure_function

stabbles 9y ago

I think the most apparent example is that people recognize patterns like `fold` and `map` everywhere once they've seen functional programming. This can be implemented in any language I guess. Most often you'll see explicit & imperative loops being refactored to shorter, descriptive code with anonymous functions, folds, filters and maps

deleted 9y ago

[deleted]

Jtsummers 9y ago

You can take those concepts and use them in your designs in languages where they're missing, even if you don't use FP or logic languages where they're "native".

craigsmansion 9y ago

Broadly speaking, imperative programming allows one to start coding a solution before one understands the problem. Functional programming is generally more abstract in its approach to modelling the problem. If you get the model wrong, you will not end up with a working solution, forcing you to rethink your model. While imperative programming allows you to reiterate towards a solution as you start to understand the problem better as you work towards it, it's obviously better and faster if your initial model of the problem is more accurate. Functional programming forces you to create a viable model of the problem before you start. If you can extend that discipline over to an imperative language, you will need less iteration and the resulting solution will likely be more elegant. The argument is not (or shouldn't be) about concepts, but about paradigms and discipline.

ht85 9y ago

Many people doing OO have trouble structuring their classes, splitting functionalities and responsibilities properly. OO kind of lets you do anything you want, allowing you to store data anywhere and having any kind of flow you want. It's very easy to do something that "just works", and while there is a lot of value in that, you can keep bad habits for very long. FP is a lot more constraining, and will force you to adapt how you think to fit said constraints. Having to think differently offers a different perspective on code architecture, that will eventually give you ideas applicable beyond FP languages.

Raknarg 9y ago
Many would argue the exact opposite, that OO is contraining and FP is much more free, allowing you to change your design model without having to redesign the entire model.

disease 9y ago

Working with functional languages has made me value and seek out simplicity in my code. Before I write a loop or create another class I'll often ask myself if there is a more simple way to solve the problem - and oftentimes there is.

matwood 9y ago

> Can anyone explain? A quick example that can be faked in any language is a pure function [1]. The functions only inputs are the set of arguments, and from those arguments returns a side-effect free result. A pure function is easy to test and easy to reason about. Contrast a pure function with an impure function that uses an objects internal state plus the arguments passed in to further tweak the state an/or return a result. It is immediately obvious the second is much harder to test and reason about. It becomes even more challenging when the object is thrown into a large system with a lot of moving parts. Even before I really started learning about true functional programming, I had been writing 'pure' functions for years because they just made sense. Even internal private methods are simpler as pure functions. Shared state is evil for many reasons and should be avoided if possible. [1] https://en.wikipedia.org/wiki/Pure_function https://en.wikipedia.org/wiki/Pure_function