• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What is the benefits of functional programming?

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, my question is generic. It doesn't matter the language: scala, erlang, etc. I would like to know the benefits of using functional programming. Why should I use in my project in comparison to OO, for example. Other thing: I know that you can create a complex project in scala, really hard to maintain. So, how we can prevent the developers to create 'monsters'?

Thanks
 
Ranch Hand
Posts: 426
Eclipse IDE Fedora Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Q1. http://en.wikipedia.org/wiki/Functional_programming In computer science, functional programming is a programming paradigm, a style of building the structure and elements of computer programs, that treats computation as the evaluation of mathematical functions and avoids state and mutable data. For this reason, it is typically not adopted in commercial applications (banking, insurance, stock exchanges, process control for manufacturing) because these applications depend heavily on state and integral data. Scala is different in that a prime application goal for Scala is to produce a hybrid functional language with object orientation capabilities and emphasis on immutable data structures.

Q2. You cannot legislate or mandate good programming practices. If your developers are smart as a box of rocks, you'll get poor results. Developers need to think independently and creatively. Mandating a set of rules to follow removes the creativity necessary to come up with unique solutions. If your concern is quality, you need to back up that concern with dedicated quality assurance people and processes. Hence the need to create defects and track progress in an agile way. Don't give a developer 90 days to do something, he'll waste the first 89 days on gobble-de-gook. Hold each developer accountable to a daily regimen of tasks and progress backed by a top notch quality assurance program.
 
author
Posts: 13
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Roger Sterling
Ranch Hand
Posts: 426
Eclipse IDE Fedora Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ?

Language is a tool, a bad developer is a bad developer no matter if he or she speaks English or French or whatever.

How, in your view, does Scala have any better modularity than Java or C++ ? Recombination is messy in code, but works very well as Services; hence Service Oriented Architecture. Scala no more helps coders create better maintainable code than any other language. The power to be a successful coder lies with the coder, not the langauge.
 
Runar Bjarnason
author
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

 
Roger Sterling
Ranch Hand
Posts: 426
Eclipse IDE Fedora Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Very well put. I would amend your statement to say "adhering to the principles of good programming practices" would be more closely accurate. It does not matter which language a coder uses, if he has horrible programming practices.
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So is Scala FP atop an OO language or OO programming atop a functional language?

I am hoping to add λs to a procedural language, but that is reversible, too.
 
Runar Bjarnason
author
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Scala is basically an object language just like Java. Its functional features, like lambdas, patterns, and type class dictionaries, are implemented as first-class objects with methods.
 
Phelipe Maia
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Really cool. Thanks for the explanation. I know that it's too easy to "create monsters" with all technologies and methodologies, but my concern is about the complexity curve in scala programming with FP. For example, would you recommend to develop an entire ERP in Scala with FP? I know that we can use Scala "as Java" and just take advantages of some API's. My question is more about the effort to create a huge team.
 
Runar Bjarnason
author
Posts: 13
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Phelipe Maia
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



I agree, but a team with programmers well versed will always be extraordinarily productive. I know the power of Scala and FP, but I can't realize a huge system written entirely in Scala. I wanna bet all in Scala, but I'm concern about build an ERP, for example, in Scala. The place that I see Scala is a language for high performance to be used in specific projects, or to implement some complex algorithms in a easier way. Do you know what I mean? Just let me know if I'm wrong about the main propose of Scala.
 
Runar Bjarnason
author
Posts: 13
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Phelipe Maia
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Perfect! Thanks!
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic