• 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
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Functional Design and Architecture - When to use?

 
Greenhorn
Posts: 7
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Alexander,

Are there certain kinds of applications/systems where it is better to use a functional design/architecture rather than OO design/architecture, and vice versa?
Thanks!

Regards,
Andrea
 
Author
Posts: 27
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

andrea aplaya wrote:Hello Alexander,

Are there certain kinds of applications/systems where it is better to use a functional design/architecture rather than OO design/architecture, and vice versa?
Thanks!

Regards,
Andrea



Hi Andrea!

Yes, there are definite niches in which either OOP or FP works better.

FP:

- Compilers, research, math
- Multithreaded and concurrent applications (if we want a better story with concurrency bugs)
- Data transformations and pipelines (for example, spam filters)
- Very complicated domains. (FP simplifies domain modeling very much)
- Stateless services
- Correctness (statically typed FP works extremely well for such domains as payments, bank software, blockchains etc)

OOP:
- All the traditional uses of OOP
- GUI (for now, FP doesn't work here that well)
- Business software (at least until we find a good way for FP)
- OOP can even work for soft-realtime apps. I wouldn't try FP there.

I believe I missed a lot here. My personal choice is FP. I had too much time spent in OOP, and don't really want to come back to it
 
Greenhorn
Posts: 26
Java ME Quarkus Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm just going to add that performance is a big thing/reason to use FP (supports parallel programming). OOP does not support parallel programming.
 
Rancher
Posts: 357
21
Mac OS X Monad Clojure Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Having built large web apps in multiple languages (and multiple paradigms) over two and half decades now, I think I'd place web apps in general squarely in the FP camp.

Handling a web request is a function from request to response, possibly producing side effects alongside that response, and as you noted concurrency is so much simpler in FP languages!

I think we can make a lot of inroads in UI work with an FRP style approach (Functional Reactive): React/Redux/etc has shown us what is possible, with some great FP wrappers around those (see Reagent/Reframe in ClojureScript, for example).

As background, I did OOP from early '92 (and was on the ANSI C++ Standards Committee for eight years before transitioning to Java, then Groovy, then Scala) although I'd studied FP at university in the '80s and via Scala I came back to FP and have been doing Clojure full-time since 2011 now.
 
Alexander Granin
Author
Posts: 27
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stepankha Yuliannia wrote:I'm just going to add that performance is a big thing/reason to use FP (supports parallel programming). OOP does not support parallel programming.



Yes, agree. I'd only say that the term "performance" is quite overloaded, and we might be talking about different things here
 
Alexander Granin
Author
Posts: 27
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sean Corfield wrote:Having built large web apps in multiple languages (and multiple paradigms) over two and half decades now, I think I'd place web apps in general squarely in the FP camp.

Handling a web request is a function from request to response, possibly producing side effects alongside that response, and as you noted concurrency is so much simpler in FP languages!

I think we can make a lot of inroads in UI work with an FRP style approach (Functional Reactive): React/Redux/etc has shown us what is possible, with some great FP wrappers around those (see Reagent/Reframe in ClojureScript, for example).

As background, I did OOP from early '92 (and was on the ANSI C++ Standards Committee for eight years before transitioning to Java, then Groovy, then Scala) although I'd studied FP at university in the '80s and via Scala I came back to FP and have been doing Clojure full-time since 2011 now.



Thank you, this is very interesting! Your experience from FP and OOP matches mine.

 
Marshal
Posts: 16597
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Alexander Granin wrote:

Stepankha Yuliannia wrote:I'm just going to add that performance is a big thing/reason to use FP (supports parallel programming). OOP does not support parallel programming.

Yes, agree. I'd only say that the term "performance" is quite overloaded, and we might be talking about different things here


Just wanted to get some clarification on this "OOP does not support parallel programming" statement.

Admittedly, I haven't written any Java programs that use them but Java does have features that support parallel programming. Are you both disagreeing with that assertion or is there some nuance in what you said that I'm just missing? Isn't support for parallel programming "a function" (excuse the pun) of implementation rather than the programming paradigm (OOP vs FP) itself? A similar example would be tail recursion. Nothing in OOP or FP says that tail recursion optimization isn't supported, right? Currently, Java doesn't support TRO as far as I know but other JVM languages like Kotlin and Scala do.
 
Alexander Granin
Author
Posts: 27
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Alexander Granin wrote:

Stepankha Yuliannia wrote:I'm just going to add that performance is a big thing/reason to use FP (supports parallel programming). OOP does not support parallel programming.

Yes, agree. I'd only say that the term "performance" is quite overloaded, and we might be talking about different things here


Just wanted to get some clarification on this "OOP does not support parallel programming" statement.

Admittedly, I haven't written any Java programs that use them but Java does have features that support parallel programming. Are you both disagreeing with that assertion or is there some nuance in what you said that I'm just missing? Isn't support for parallel programming "a function" (excuse the pun) of implementation rather than the programming paradigm (OOP vs FP) itself? A similar example would be tail recursion. Nothing in OOP or FP says that tail recursion optimization isn't supported, right? Currently, Java doesn't support TRO as far as I know but other JVM languages like Kotlin and Scala do.



Hi Junilu,

This is not my statement though, so maybe Stepankha can tell.

From my perspective, OOP doesn't deny parallel and concurrent programming. After all, there are a lot of things about this. What I see is that FP is much much more suitable for parallel and concurrent programs because of its concepts of purity, immutability and careful separation of concerns. OOP is imperative, mostly. You certainly can program it with purity and immutability, it's just not enforced by OOP languages.

Also, such things as (monadic) Software Transactional Memory, eliminate so many bugs and reduce so many problems with concurrency that I'd say it's unbelievable that this is possible.
 
Stepankha Yuliannia
Greenhorn
Posts: 26
Java ME Quarkus Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Alexander Granin wrote:

Stepankha Yuliannia wrote:I'm just going to add that performance is a big thing/reason to use FP (supports parallel programming). OOP does not support parallel programming.

Yes, agree. I'd only say that the term "performance" is quite overloaded, and we might be talking about different things here


Just wanted to get some clarification on this "OOP does not support parallel programming" statement.

Admittedly, I haven't written any Java programs that use them but Java does have features that support parallel programming. Are you both disagreeing with that assertion or is there some nuance in what you said that I'm just missing? Isn't support for parallel programming "a function" (excuse the pun) of implementation rather than the programming paradigm (OOP vs FP) itself? A similar example would be tail recursion. Nothing in OOP or FP says that tail recursion optimization isn't supported, right? Currently, Java doesn't support TRO as far as I know but other JVM languages like Kotlin and Scala do.



Read/write safety is the biggest concern and bottleneck in parallel processing. So what I meant is OOP is not "real" parallel computing in my view. Functional programming basically deals with immutable objects, which means you are quite unlikely to need to worry about some thread changing the content before you get to use it - it also solves it by saying "why re-use and recycle the same memory space? There's so much memory compared to processors, let's just forget about saving space and worry about speed."
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic