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
Stepankha Yuliannia, PhD.
I spent the morning putting in a comma and the afternoon removing it.
-- Gustave Flaubert, French realist novelist (1821-1880)
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.
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.
Alexander Granin wrote:
Yes, agree. I'd only say that the term "performance" is quite overloaded, and we might be talking about different things hereStepankha 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.
Junilu Lacar wrote:
Alexander Granin wrote:
Yes, agree. I'd only say that the term "performance" is quite overloaded, and we might be talking about different things hereStepankha 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.
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.
Junilu Lacar wrote:
Alexander Granin wrote:
Yes, agree. I'd only say that the term "performance" is quite overloaded, and we might be talking about different things hereStepankha 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.
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.
Stepankha Yuliannia, PhD.
Don't get me started about those stupid light bulbs. |