Then is it me, or is this similar to procedural programming with ADT (abstract data types)?
In the real world, a lot of time people would mix paradigms, because separation in paradigms is arbitrary in the first place (this is not a science, this is closer to the art). For example, see this article about if, or for example, you can use .map in the OOP-ish language.
The big difference (at least one which first comes to my mind) with procedural programming is "functions as values". Which doesn't seem like a lot, but allows to do a lot of neat tricks. If you add lazy evaluation it will allow to do even more tricks (pure FP needs lazy evaluation, in Lisp they don't have it by default, but they have macros). This is a broad area it would take me N posts to cover. To show all the tricks and why it matters.
If the latter, then there are problems with scale of systems.
Why? Do you have any empirical evidence for this? I know people deliver 100k codebases to production (LoC is not the same as "scale", but we don't have another fair measure for this).
The bigger the system grows, the more functions are introduced in global namespace, or possibly in nested namespaces.
What the difference between namespacing with objects and namespacing with modules?
Self-contained piece of code, that can be easily unit-tested, inherited and extended. No need to pass many parameters from one function to another.
I don't know how to respond to this. What can be more unit testable than pure function? You always get the same output for the same input, which is not always true for objects. As well in FP they typically use plain data structures, so you don't need a special mocking library.
To the point where it might blend with math and formal proof of correctness.
There is a difference between proving the correctness of the program and the formalism of FP. This is an urban legend that FP programs are formally proved to be correct right away. No, they are not. You need to write additional verification for it, the same way as you would do for any other paradigm. See this post for details.
Any other real-world examples?
I don't know. Search the internet for examples. Haskell, F#, Scala, Kotlin.
From this perspective, how much time does one have to invest to understand Functional Programming approach?
There are patterns in FP as well, which you can learn and then reuse across languages. For example, map, reduce, functions as values, monads (option-monad, either-monad, futures - similar to promises, but not the same, etc.)
4) Is Functional Programming suited well enough to rewrite existing programs (websites, mobile apps, Line-Of-Business apps, etc.) using this paradigm, or are there areas where FP seems to suit best?
FP the same way as OOP as procedural style is general programming paradigms (for example, logic programming is not general), so they suitable almost for anything (95% of use-cases ?), most of the time is just a matter of taste. There are some edge cases for which you need something else, for example, I would not use FP languages (as far as I know most of them are garbage collected) to write Memcached (key-value storage). To write key-value storage you need not a garbage-collected language or non-stop garbage collection as they have in Pony.
Regarding "scale of systems" I was mostly thinking about number of names (be it functions, classes, etc.) that might collide with one another. Namespaces of course solve part of the problem, in the meaning that functions have some "prefixes" before their names (like name of namespace or module for example).
What [is] the difference between namespacing with objects and namespacing with modules?
I didn't give an example here, sorry. I had in mind Java 9 modules, and upcoming C++20 modules. They solve different problems than just namespaces in these languages.
Regarding testability. I was thinking rather about a set of functions (methods) enclosed in a class. It's rare to do everything in just one function, typically one function uses other functions to express the result. I was never trying to imply that functional programs are difficult to be unit-tested ;)
You always get the same output for the same input, which is not always true for objects. [emphasis added]
Now I don't know how to respond to this... Seems like a serious bug to me. There's not a problem to create objects with immutable state, where the results of method calls are always the same. Plus such immutable objects can easily be shared between threads. It depends on the style and/or necessity.
There are patterns in FP as well, which you can learn and then reuse across languages. For example, map, reduce, functions as values, monads (option-monad, either-monad, futures - similar to promises, but not the same, etc.)
Very true. Just a different set of concepts. By the way, combination of map and reduce is one of my favourites (!) I learned long ago.
Thank you very much for your time and interesting discussion. I will keep coming to your blog and occasionally ask some more questions :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In the real world, a lot of time people would mix paradigms, because separation in paradigms is arbitrary in the first place (this is not a science, this is closer to the art). For example, see this article about if, or for example, you can use
.mapin the OOP-ish language.The big difference (at least one which first comes to my mind) with procedural programming is "functions as values". Which doesn't seem like a lot, but allows to do a lot of neat tricks. If you add lazy evaluation it will allow to do even more tricks (pure FP needs lazy evaluation, in Lisp they don't have it by default, but they have macros). This is a broad area it would take me N posts to cover. To show all the tricks and why it matters.
Why? Do you have any empirical evidence for this? I know people deliver 100k codebases to production (LoC is not the same as "scale", but we don't have another fair measure for this).
What the difference between namespacing with objects and namespacing with modules?
I don't know how to respond to this. What can be more unit testable than pure function? You always get the same output for the same input, which is not always true for objects. As well in FP they typically use plain data structures, so you don't need a special mocking library.
There is a difference between proving the correctness of the program and the formalism of FP. This is an urban legend that FP programs are formally proved to be correct right away. No, they are not. You need to write additional verification for it, the same way as you would do for any other paradigm. See this post for details.
I don't know. Search the internet for examples. Haskell, F#, Scala, Kotlin.
There are patterns in FP as well, which you can learn and then reuse across languages. For example,
map,reduce, functions as values, monads (option-monad, either-monad, futures - similar to promises, but not the same, etc.)FP the same way as OOP as procedural style is general programming paradigms (for example, logic programming is not general), so they suitable almost for anything (95% of use-cases ?), most of the time is just a matter of taste. There are some edge cases for which you need something else, for example, I would not use FP languages (as far as I know most of them are garbage collected) to write Memcached (key-value storage). To write key-value storage you need not a garbage-collected language or non-stop garbage collection as they have in Pony.
Regarding "scale of systems" I was mostly thinking about number of names (be it functions, classes, etc.) that might collide with one another. Namespaces of course solve part of the problem, in the meaning that functions have some "prefixes" before their names (like name of namespace or module for example).
I didn't give an example here, sorry. I had in mind Java 9 modules, and upcoming C++20 modules. They solve different problems than just namespaces in these languages.
Regarding testability. I was thinking rather about a set of functions (methods) enclosed in a class. It's rare to do everything in just one function, typically one function uses other functions to express the result. I was never trying to imply that functional programs are difficult to be unit-tested ;)
Now I don't know how to respond to this... Seems like a serious bug to me. There's not a problem to create objects with immutable state, where the results of method calls are always the same. Plus such immutable objects can easily be shared between threads. It depends on the style and/or necessity.
Very true. Just a different set of concepts. By the way, combination of
mapandreduceis one of my favourites (!) I learned long ago.Thank you very much for your time and interesting discussion. I will keep coming to your blog and occasionally ask some more questions :)