Functional Design and Architecture - When to use?

[andrea aplaya]

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

[Alexander Granin]

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

[Stepankha Yuliannia]

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.

[Sean Corfield]

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]

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]

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.

[Junilu Lacar]

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]

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]

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."