• 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

Difference from Pierre-Yves Saumont's book

 
Author
Posts: 28
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for having me!

In my introductory post, I was asked how my book compares to Pierre-Ives Saumont's "Functional Programming with Java", so I am trying to answer that now.

I think the main difference is already shown in its title/subtitle, highlighting the book's different approach to its topics.

The book approaches its topics primarily from the Java side and moves towards FP, not vice versa.
That means it builds upon the available tools in the JDK and shows how to use them to augment your code gradually, not replace it with functional techniques and concepts, so you can enjoy the best of both OO and FP.

Looking at functional programming concepts and techniques from an isolated point of view, everything is quite awesome.
Topics like persistent data structures, reactive programming, or state management with actors, are all great solutions.
So many things are way easier to do than before in imperative or OO code.

However, many Java devs, myself included, work with existing projects, code bases, and dependencies living in an imperative or OO world.
We usually can't switch to another paradigm for core features or change the whole architecture because it is supposed to be a "better" solution.
Even if we could, most of the time, you still shouldn't without a clear need to do so.

That's why I try to approach the functional topics from the point of view of a more "typical" Java developer wanting to improve their code with functional concepts and techniques.

My reasoning for doing so is simple.
Once, I read a book about FP in Java that intentionally ignored Streams and built its own equivalent.
That's actually a great way to learn the why and how of declarative data processing, and there is much to learn from such content.
But on the other hand, how often do you really implement such a feature in a "real" project yourself? It feels a little bit like a case of "not invented here" syndrome.

I'm guilty of that myself, don't get me wrong, but I believe that using the tools already available often triumphs over using a dependency or, even worse, implementing it yourself.
My point is that using non-JDK tools always adds responsibilities, long-term commitments, and requires a mental overhead that you might even unwillingly force onto others.

That's why the book introduces functional concepts, techniques, and the available tools in the JDK in detail, including ~50 figures.
This allows the reader to develop a "functional mindest" that's useful regardless of the chosen paradigm, even in a more OO/imperative-akin language like Java, opening up a new world without completely transforming your code base.
 
Marshal
Posts: 79475
379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I shall split this thread so my replies will give me a change of winning

Ben Weidig wrote:Thanks for having me!

That's a pleasure and thank you for coming here to promote your book.

In my introductory post, I was asked how my book compares to Pierre-Ives Saumont's "Functional Programming with Java" . . .

Yes, I asked that question.

. . . approaches its topics primarily from the Java side and moves towards FP . . .

Yes, P‑YS starts from FP principles.

. . . So many things are way easier to do than before in imperative or OO code.

Agree that the declarative style which Streams and λs permit, once you have learnt it, makes programming easier.

. . . change the whole architecture because it is supposed to be a "better" solution. . . .

I am sure there is a name for that. Yes, “If it ain't broke, don't fix it.”

. . . built its own equivalent.
That's actually a great way to learn . . . how often do you really implement such a feature in a "real" project yourself? . . . .

Yes, it is good to learn the internals of library classes, even if you then tell your readers, “Nobody does this in real‑life programming.” Once a student/learner has built a hashtable. they will understand how they work for ever. . . . And never write such a class again!
 
Being a smart alec beats the alternative. This tiny ad knows what I'm talking about:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic