• 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

Functional Programming in Java

 
Ranch Hand
Posts: 572
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Does your book cover use cases where functional programming is a better approach ?

thanks,
Paul
 
Author
Posts: 161
31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Paul,

Does your book cover use cases where functional programming is a better approach ?



Sure, since functional programming is always a better approach

More seriously, this is highly subjective. It depends upon your own criteria. If you think about performance, the goal of functional programmers is often to do as well (or nearly as well) as the imperative version. However, some functional programs are faster than their imperative counterpart. But in general, functional programs are a bit slower.

If you think about the time needed to write a program, this is of course also subjective. An imperative programmer will have to struggle to think functionally. So, he will be less productive at first. For an experienced programmer, I would say that writing a somewhat complex functional program that compiles takes a bit longer that its imperative counterpart. The difference is that a program that compiles will have much less bugs. It will have "functional" bugs (nothing related with functional programming, but to programs with incorrect algorithms, for example) but it will rarely have implementation bugs. No unexpected null pointer (BTW, I don't really no what an expected null pointer is!), no concurrent access error, no index out of bound, no class cast exception and so on.

In the end, functional programmers are more productive.

There is another reason for this: functional programming is not only about programming using (pure) functions. It is also about pushing abstraction to the limit. In functional programming, there are no loops, no if then statements, no try catch and the like. All these structures are abstracted once for all, so the programmer can't mess with them. People often think that recursion is heavily used in functional programming. Although this is true, it is abstracted as well, so the programmer never have to use it explicitly.

So, after all, saying that functional programming is always a better approach may be a joke, but it is not far from being true!

Pierre-Yves
 
paul nisset
Ranch Hand
Posts: 572
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Hi Pierre,
Less bugs is always a compelling argument.

I found the 'no concurrent access error' comment interesting .

I guess this would mean ,in a web server environment, each thread from a user session would always access a particular function sequentially ?
If this is correct ,that would essentially mean that a functional web application would be single threaded. even if running on a multi-threaded web server.

Is that a correct view of it or would this only apply to iterating through and modifying a collection/list ?

Thanks,
Paul
 
Pierre-Yves Saumont
Author
Posts: 161
31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your analysis is mostly correct in its principle. However, it does not have to work exactly that way. You can create a multithreaded web application by using actors. Only actors handling mutable state would have to act sequentially. Actors are like small independent applications exchanging messages in an asynchronous way. And exchanging messages is treated as input/output.
 
paul nisset
Ranch Hand
Posts: 572
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sounds interesting.
Thanks.
 
I want my playground back. Here, I'll give you this tiny ad for it:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic