Fork me on GitHub
#architecture
<
2024-07-04
>
tengstrand07:07:48

"OOP is more suitable for creating large, complex systems". That's the final conclusion in https://fluxtech.me/blog/object-oriented-programming-vs-functional-programming/ blog post. I don't agree. You are in a much better position to fight complexity if you use a functional language like Clojure together with some modular approach like https://polylith.gitbook.io/polylith, if you ask me. What do you think?

1
Rupert (All Street)07:07:40

OOP is more suitable for creating large, complex systems, while FP is more suitable for creating small, reusable componentsAuthor is so close to coming to the right conclusion but can't quite make the final mental leap! To build important software you want to make it out of "small reusable components" - because that's scalable to thousands of developers. OOP does lead to "creating large, complex systems" but that isn't a positive thing.

💯 2
Ludger Solbach07:07:03

Written with the kind help of your friendly AI?

1
Ludger Solbach07:07:47

Of course OOP is better in creating large, complex systems, but the goal is to create large, simple systems, that you can still reason about. So the article is missing the point completely, IMHO.

4
tengstrand07:07:09

He indirectly says that FP is not suitable for large systems!

Ludger Solbach07:07:42

That's bullshit, IMHO

tengstrand07:07:12

Of course it is, but that's what a large majority of this industry believes.

Ludger Solbach07:07:04

Beating the averages?

tengstrand07:07:20

Yes, that's what we do, in my opinion. So we shouldn't maybe complain! 🙂

💯 1
stas09:07:46

Why would anyone care?

didibus04:07:08

I've now read the article. It's garbage haha. Definitely either AI assisted or just a poor writeup for SEO. But ignoring the quality of it, the thing is that it's not really talking about everything in FP related to code organization. In that way it's not totally comparing the same things. If you look into FP, off course there's more, you have modules, you often have some form of polymorphism, you can encapsulate when needed, you've got ways to manage state and side effects, etc. All that was ignored, like you're stuck with no way to organize a larger code base.

tengstrand04:07:36

I agree, well summed up! It's just a little sad that information like this about FP is being spread. My personal view is that there is a lack of a deeper understanding of where complexity arises from within the OO community, which leads them to focus on the wrong things.

stas04:07:59

I don’t think FP, OOP or whatever communities are concerned about this. In professional world there are significantly more impactful constraints than a programming paradigm of choice. I’ve seen terrible OOP source code, I’ve seen beautifully elegant assembly code :man-shrugging::skin-tone-2: Alex Stepanov started his “universal library” in 1975 in Scheme, moved to ADA in 1985 and finally landed with it in C++ as STL in 1995. And it still is the best engineered library that I have seen. Moreover, some internet guy’s post is “an opinion”, not “spreading information”. The university curriculums are more important there. However, that does not limit you in any way. Make your choice, step over that post and move on.

didibus05:07:42

Ya, but the STL is not very OOP ? I don't know, C++ templates feel more Lispy to me than anything else, almost like macros. I don't know if OOP or FP even applies, kind of it's own thing.

tengstrand05:07:23

I agree that you can write elegant assembly code as I have spent thousands of hours doing just that. What I don't agree with is that FP wouldn't be suitable for writing large systems, and that choice of language wouldn't matter in terms of how easy it is to keep complexity down (increasing changeability). For example, I wouldn't choose assembly for the system I'm working on right now (600,000 lines of code) as it would be immensely more complex and very difficult to maintain, but in some other situations, it could be the right choice if I needed maximum performance and be in more control of the generated machine code @U06NTEH1P3L.

2
didibus05:07:17

It's not about being categorial either, OOP/FP are set of ideas and come in various forms inspired from those basic ideas. But code structure is obviously important to maintenance of a code base over time, and the constructs available to you or missing from your language impact how you can structure code. It seems when discussing FP, people focus on some of the ideas that are "in the small", a function and what it can do, immutability, etc. But in OOP, people often talk Gang of Four design patterns, etc. Even a "class" is a much larger unit, which imposes "in-the-medium" structure. Naturally people might conclude, OOP seem to have more ideas and provide better constructs for structuring in-the-medium/large. This is false though, it's just the ideas and constructs in FP around those medium/large areas I think are just less often brought up. In Clojure for example, we have namespaces, it's a very important part of the language, and it allows structuring larger programs. You also have protocols, types, DSLs, macros, and so on.

2
didibus05:07:08

And Clojure has all the ideas around state management as well, central state as a in-app DB, and so on.

didibus06:07:05

One piece that is often lost as well, and I see it often. People say OOP has encapsulation, and FP does not. But, that's not nuanced enough. FP or Clojure says that immutable data need not be encapsulated, because the immutability already protects the invariants. Off course, you can often still encapsulate behavior, Clojure has private functions behind namespaces for example. Even though in practice people tend to prefer convention over it (like with -impl namespaces). You can also encapsulate "data", with private vars, or with locals, or closed over variables, etc. Just not together with a set of functions. And for cases where you might really need it, Clojure has deftype, where data will be encapsulated, but only when mutable. Because that's the big difference conceptually, immutable data does not need to be encapsulated, but mutable data definitely benefits from it to protect unwanted external interference that could break invariants.

ozzymcduff06:07:58

Yes, clearly it is marketing nonsense in favor of OOP…

👍 2
Ludger Solbach06:07:11

Also large systems nowadays are seldom monoliths but composed of smaller services with defined APIs and message queues, The unit of code a team has to deeply understand and maintain is the service, not the whole code base of a huge system.

stas06:07:16

My point was that I would rather work with a well-designed OOP code than with poorly designed FP code. Systems design has more influence than the paradigm or the language of choice. Design is the idea, paradigm is the language. Joyce and Dostoyevsky are honoured not for their language, but for their ideas. Yes, Joyce is better read in English, Dostoevsky is better read in Russian. But that is an artefact of their familiarity with the tools at their disposal.

Ludger Solbach07:07:34

Sure, the language does not necessarily lead to a good design, but it facilitates a good design by providing mechanisms, like immutability and data literals in clojure. But you have to use them wisely, of course. Also the architecture of a large system is not so much dominated by the language, each service could be implemented in a different language without an effect on the large scale design.

didibus17:07:08

@U06NTEH1P3L It's true the actual design of the code base matters more than just trying to use one or another paradigm poorly. But given two well designed code base which style would you prefer? And similarly, given two poorly designed code base which style would you prefer? They're going to exhibit different properties and capabilities, and how you have to approach them in order to extend, enhance, or modify the code's behavior, or fix bugs, or scale them, or optimize them, or test them, or debug them, or deploy them, etc. will be different.

stas18:07:47

As an IC, I would prefer the one that is better documented, then the one my peers know better, then the smaller one, then 10 more really important factors and then I would side on FP, just because I will turn it into FP anyway. In the end it does not matter how much I love FP, the simplest way to transpose a matrix is still 3 nested loops, I would say.

stas18:07:08

As a business owner, I would prefer the one for which it is easier to hire the workforce.

stas18:07:20

But hey, we do not have to agree on everything to co-exist. I am sure there is something else we 100% agree on 😄

didibus21:07:56

I think it's more that we're putting different constraints. Like with gasoline vs. electric cars. Gasoline cars offer reliability, availability, lower cost, and easy access to repairs and fuel, making them more practical for now. However, people recognize the potential advantages of electric cars, and in 10-20 years, those advantages could make electric cars the norm. Similarly, when debating OOP vs. FP, we need to consider their inherent merits. If FP has more inherent merits, it might be worth pushing for a shift towards it. In 10-20 years, FP might no longer be niche, hard to hire for, or lacking in documentation and tooling. We've already seen this shift, with many popular languages incorporating more FP features. You're debating what's best for a business starting a new project in the immediate and current context. I'm talking more broadly about the inherent qualities of each paradigm and deciding if a long term push towards FP seems appropriate. Actually not sure we disagree. I'm not able to push for full on FP solutions very often at work, but I can evangelize, educate and often bring an FP like approach because Java 17+ lets you do things a lot more functional if you want. And that's been possible because of people evangelizing FP prior, influencing the direction that newer versions of Java took. And generally the architecture at a higher level matters more nowadays, what are all the services, server less, front ends, back ends, cloud, on-prem, look like, structured, their interface, the DB you use, how data is modeled, etc. And it seems you'd agree that it's worth pushing towards FP in the long term, I assume, since you said you'd bring FP to an OO code base already.

stas21:07:33

I tend to avoid absolute categories and as such take everything in the context. I do not have strong bias either way. I prefer FP, because this is most comfortable to me. There is a general tendency to gravitate towards FP when the practitioner realised that software engineering is closer to math than bin packing. And math is about laws and relations, not numbers per se. On the other hand Smalltalk is a beautiful OOP system, sort of dual to Lisp.

stas21:07:21

And in 10–20 years we may be surprised to discover that Forth or Prolog is the way :man-shrugging::skin-tone-2:

didibus03:07:58

That article confuses me. Smalltalk isn't homoiconic, and code isn't data, and data isn't code. And it still suffers from typical OOP downsides like issues related to mutable state, inheritance, and object encapsulation. It's clean syntax wise, is quite consistent in it's OOP approach and has awesome live coding/IDE capabilities. So I'm not really following what the article means here?

Ben Sless14:07:29

I think systems like Spark, Kafka, Datomic, xtdb, Rama, Erlang/OTP show that functional programming is an excellent fit for large, complex stateful system. They just end up looking rather different

👍 2
Ludger Solbach15:07:21

Not sure, if I would call the Spark implementation as functional programming, even if the problem solved is inherently functional.

Ben Sless15:07:17

Isn't spark implemented in Scala?

Ludger Solbach15:07:56

Yes, but it's a mix of OOP and FP, as far as I remember from looking into the code base a few years ago. Maybe a tribute to the Java API of spark.

didibus21:07:56

I think it's more that we're putting different constraints. Like with gasoline vs. electric cars. Gasoline cars offer reliability, availability, lower cost, and easy access to repairs and fuel, making them more practical for now. However, people recognize the potential advantages of electric cars, and in 10-20 years, those advantages could make electric cars the norm. Similarly, when debating OOP vs. FP, we need to consider their inherent merits. If FP has more inherent merits, it might be worth pushing for a shift towards it. In 10-20 years, FP might no longer be niche, hard to hire for, or lacking in documentation and tooling. We've already seen this shift, with many popular languages incorporating more FP features. You're debating what's best for a business starting a new project in the immediate and current context. I'm talking more broadly about the inherent qualities of each paradigm and deciding if a long term push towards FP seems appropriate. Actually not sure we disagree. I'm not able to push for full on FP solutions very often at work, but I can evangelize, educate and often bring an FP like approach because Java 17+ lets you do things a lot more functional if you want. And that's been possible because of people evangelizing FP prior, influencing the direction that newer versions of Java took. And generally the architecture at a higher level matters more nowadays, what are all the services, server less, front ends, back ends, cloud, on-prem, look like, structured, their interface, the DB you use, how data is modeled, etc. And it seems you'd agree that it's worth pushing towards FP in the long term, I assume, since you said you'd bring FP to an OO code base already.