[pbw]

I disagree that FP and OOP are aren't sufficiently distinguished from each other. There is substantial academic literature on both methodologies, and they are very different worlds in theory and in practice.

I do agree though it's possible and commonplace to do a blend of both, plus structured programming, plus just general hackery. I've often seen OO systems with a big pile of pure functions, particularly math functions, because math mostly is just functions. And it's quite nice! You don't have to worry about the interactions, the advantages of pure functions are quite clear.

I agree with you that mutability can explode the amount of state you need to be aware of. Milewski just tweeted in response to the article "The problem with OO is that, even if you expose 7 things on the surface, there are hidden dependencies that you cannot ignore: object A may store a pointer to B. You can write complex functional programs, but the syntax forces ugliness to the surface for all to see."

https://twitter.com/BartoszMilewski/status/12946650880543784...

However that's the nice thing about small objects, they better contain the mutability chain reaction. A small inner object cannot see anything else. Whereas in a big kitchen sink object every attribute and every method is in play.

[kaens]

not saying they aren't distinguished, am saying that a huge amount of the discussion around them in the workforce is being done by people who couldn't define them for you, and that a lot of everything in our field is driven by people who don't understand things copying the shape of them and repeating stuff they heard from people who sound like they do. in general, these aren't people who are going to cross-paradigm as a matter of honing their craft and the ones that are tend towards being good programmers in the end.

i'd further say that that mass lack of understanding is closer to the reason for there being such a mess in many oop systems, in combination with economic pressures, despite common OOP practices being not good for lots of things they got used for.

to quote you elsewhere in the thread:

> The reason bad OO is so common is some codebases become economically valuable right around when they start falling apart due to poor design, but you can hire more and more people if the software is bringing in more and more money.

this is a good insight, but i assure you this happens in fp codebases written by inexperienced programmers or poorly managed inexperienced businesses who hired someone to burn them out as well, in exactly the same way, for the same reasons, and that those fp codebases are just as bad, especially now that fp is a "attract the 10xers" item for companies. (would you rather figure out where the thing mutating the state under your nose is or where the hidden assumption that this state will mutate is? i'd prefer doing neither)

Milewski is correct with the caveat that people write the ugliness and build and maintain upon it, producing systems that themselves have tons of spooky action at a distance and get mitigated by bugpatch burn marches just the same

[pbw]

I guess I’ve lost the plot here. Sturgeon’s Law says 90% of everything is crap. Half of programmer’s and their programs are below average. The article is just saying that objects with lots of attributes can be problematic and so we should avoid doing that. I stand by that suggestion.

[kaens]

oh yeah i absolutely agree with you there honestly i just got too in the weeds here, sorry