Rãºnar Bjarnason wrote:Phelipe Maia:
In the book we try to give concrete examples of the benefits of functional programming. In short, those benefits are modularity and compositionality.
Modularity is the extent to which the parts of your programs can be separated and recombined in new ways. One practical benefit of this is code reuse. If it's easy to separate a part of your program out and reuse it in a different context, that enhances your productivity. Paul likes to say that "if you just eliminate all the duplicate code in your programs, you end up with functional programming". Another benefit of this is parallelization. If parts of your program can be cleanly separated, then those separate parts can be safely run in parallel. Testability is another. Again if you can isolate parts of your program, then they can be individually tested, which gives you confidence in the quality of your overall program.
Compositionality is the extent to which your program is composed of parts, each individually understandable, with clear rules of combining them. A compositional program can be understood just by looking at its parts and the rules of combination. Pure functions have this property because they are black boxes, and you can build larger black boxes just by plugging the output of one function into the input of another. The practical benefit here is that large systems can be assembled out of simple components.
A third and often overlooked benefit of FP is that it promotes programmer happiness. It is too easy to "create monsters", like you say, with other methodologies. Code that is hard to maintain makes your life as a programmer miserable. The accumulating technical debt creates friction, and makes it feel like you are trudging through a swamp whenever you need to change anything in the code. FP counteracts this. Code that is modular and compositional feels clean and is pleasant to work with, because it promotes clear separation of concerns (modularity), and safe recombination (compositionality). I have been programming for 28 years now, and I know how easy it is to create an unmaintainable mess with methodologies like OO. I think that if I hadn't come across FP, I would have stopped programming 10 years ago.
So you are saying that code written in Scala will be easier to maintain and make the developers happier?
Rãºnar Bjarnason wrote:
So you are saying that code written in Scala will be easier to maintain and make the developers happier?
Not exactly. I'm saying that adhering to the principles of functional programming will give you those benefits. The choice of language is not the most important in this regard. You can reap the benefits in Scala, Java, or C++, although it will be considerably easier in Scala than in the latter two, and easier still in languages like ML or Haskell.
Runar Bjarnason wrote:Phelipe Maia:
In the book we try to give concrete examples of the benefits of functional programming. In short, those benefits are modularity and compositionality.
Modularity is the extent to which the parts of your programs can be separated and recombined in new ways. One practical benefit of this is code reuse. If it's easy to separate a part of your program out and reuse it in a different context, that enhances your productivity. Paul likes to say that "if you just eliminate all the duplicate code in your programs, you end up with functional programming". Another benefit of this is parallelization. If parts of your program can be cleanly separated, then those separate parts can be safely run in parallel. Testability is another. Again if you can isolate parts of your program, then they can be individually tested, which gives you confidence in the quality of your overall program.
Compositionality is the extent to which your program is composed of parts, each individually understandable, with clear rules of combining them. A compositional program can be understood just by looking at its parts and the rules of combination. Pure functions have this property because they are black boxes, and you can build larger black boxes just by plugging the output of one function into the input of another. The practical benefit here is that large systems can be assembled out of simple components.
A third and often overlooked benefit of FP is that it promotes programmer happiness. It is too easy to "create monsters", like you say, with other methodologies. Code that is hard to maintain makes your life as a programmer miserable. The accumulating technical debt creates friction, and makes it feel like you are trudging through a swamp whenever you need to change anything in the code. FP counteracts this. Code that is modular and compositional feels clean and is pleasant to work with, because it promotes clear separation of concerns (modularity), and safe recombination (compositionality). I have been programming for 28 years now, and I know how easy it is to create an unmaintainable mess with methodologies like OO. I think that if I hadn't come across FP, I would have stopped programming 10 years ago.
Runar Bjarnason wrote:It's my experience that FP actually reduces the "complexity curve". The space of potential solutions to a given problem is enormous, and FP really puts constraints on the solutions that are allowed. This simplifies your search through the solution space.
I also find that when developing functionally you do not need huge teams. A small team of programmers well versed in FP can be extraordinarily productive. You will do more with less code. That code is harder to write, to be sure, but it is easier to maintain, extend, and test.
Runar Bjarnason wrote:Yes, I think you are wrong about that. Scala is a general-purpose programming language. And if you stick with FP, then building a "huge" system is exactly the same as building a small system. The approach scales very well.