[kaens]

i have found larger real world fp codebases to have essentially the same organizational problems as OOP codebases, just expressed in different ways.

most of the problem wrt code organization has to do with communicating meaning to humans, fp codebases written by people with a weak and evolving understanding of their problem domain are prone to the same sort of spaghettish expression of intent as OOP codebases in similar spaces, albeit often less verbosely by LOC.

the assumption that all you have to think about is the implementation of the transformation of the function you are currently looking at's inputs to its outputs is often incorrect, or only true in small or idealized cases.

this isn't a diss on FP styles as a whole, i prefer them, but it is not in my experience a great model for everything nor do i find it to significantly aid clarity of purpose in many cases. it is well suited to a lot of shapes of problems that currently pop up often, particularly stream transformation / aggregation types of things.

edit: for clarity, the thing that happened in this industry where "OOP" became synonymous with "how you write code / how you model problems" was a terrible mistake and the influence of fp mindsets on the whole has been a positive, especially considering that context. anything that disconnects seriously thinking about how what you're writing is being understood by humans and ran by machines and how that intersects with your domain is imo a mistake, however this is a bit idealistic of me.

[pbw]

One of the reasons Linus cites for disliking C++ is he dislikes C++ programmers. He considers the average C++ programer to be of much lower quality than the average C programmer. And I don't really doubt him.

I think the same can be said for FP vs. OOP. People really into FP have passed through a filter. If you take a very mediocre OOP programer and track them over the next 5 years, they are unlikely to get into FP. But if you take a very bright, motivated, curious OOP programmer who likes to test limits and explore, they are a prime candidate for maybe drifting into FP. So I think it's obvious the caliber of FP programmers is higher on average than C++ or Java programmers.

As you say, though, it's possible to write bad code in any language using any programming paradigm. Not just possible, it's trivial! So I don't think FP magically solves all your problems. I think FP has some great properties and does 100% avoid some specific pitfalls that plague OOP, but it's not magic.

Great FP programmers can write amazing programs, but great OO programmers can as well. Just like you can write great (or horrible) literature in English, French, German, or Chinese.

[kaens]

While I recognize what you're saying here wrt types of programmers and what they're likely to get into, I am not convinced that this doesn't have more to do with relative popularities of terms + the tendency for people who are "into" a subject to explore the subject / be open to explorations of different ways of thinking about the subject.

neither fp or oop are well defined terms in actual usage, more of smears of approaches really. moods almost. We have an awful lot of this sort of thing and often a term will get smeared out into a kind of emotional suggestion + some things that help you avoid types of bugs or accomplish a specific sort of goal.

I don't like this much but for a lot of situations it just means you have to understand things well enough to talk about them without using their name or take the time to establish contexts of meaning w/whoever you are talking to, both of which are good things to have in programmers in general.

That is to say: I think you are correct they have passed through a filter, particularly if they came from an oop background, but I suspect that filter isn't much related to fp vs oop principles as a matter of comparison

edit: just noticed you're the author of the article. here's a thought: the reason you want to avoid mutability can be framed in terms of it causing the number of things you have to hold in your head to very quickly exceed nine, often in ways you may not be aware of unless you have pretty comprehensive knowledge about the runtime characteristics of your entire system's stack.

[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

[valand]

Simplified and abstracted, Great programmers think things through. They don't just figure out how to make things work. They think about the tools itself (in this case their tools are the programming language) and see whether certain pattern in a PL produce the best outcome, either the semantic or the performance.

I think what Linus saw was the pattern where bad programmers tend to intersect with the demographic of c++ and java

It is an unfortunate generalization, since I have one person in mind who is very mature in software development and spends a lot of time in c++ due to job and experience circumstances.

But since it's Linus, it might be a valid generalization for us to watch out for, regardless if it is accurate or not

[AnimalMuppet]

I wonder if the "filter" is because OOP is the default way of teaching programming at the moment. If we changed to FP being the default, then only the great programmers would become OOP programmers, and the mediocre ones would be stuck in FP.

[kaens]

i think so, largely yes. large industry immersion for a long time (still) lead to, in my view,teaching people wage work skills as opposed to, say, trade or craft skills if that makes sense.

i don't think they'd necessarily become OOP programmers if fp was the default, but i do think we would see a similar trend of fp becoming a distasteful term. all approaches have edge cases and pain points, all those edge cases and pain points get amplified very loudly when they're not accounted for. a lot of fp requires at least as much subtlety in this regard as anything else.

within the framings of software development, i think it is the maintaining of rotting systems that ultimately causes distaste. it is not hard to imagine someone only ever running into, eg, oop systems that are a mess because that's basically all there was for many companies building many things under burnout schedules with no one with more than 5 years of experience working on them.

the problems that fp makes go away easily, the big wins, particularly things like mutability, are things that just happen to fit very well in the problem spaces a lot of software in "the discourse" is written for. if and when those spaces change, so will favored approaches, whatever they end up being.

all that said, i do not think that everyone writing software needs to be a mega computing wizard. the industry is very broad in terms of what types of skillsets are wanted or needed where. i don't think we support this idea very well as a whole.

[LkpPo]

> I don't think they'd necessarily become OOP programmers if fp was the default, but i do think we would see a similar trend of fp becoming a distasteful term.

Inevitable! You only have to see how the abuse of GOTO has traumatized memories with very dogmatic contrary reactions. While used well there is no harm.

> because that's basically all there was for many companies building many things under burnout schedules with no one with more than 5 years of experience working on them.

Not only. There are people who will never learn even after 15 years of career. It doesn't interest them or they don't have strong enough fundamentals and will never catch up.

[didibus]

That's a different way to approach the challenge though.

You're hoping that some technique or tool can be so rigid and fool proof that no one can write a bad program in it.

Where as I'm hoping to find some techniques and tools that let me write programs with better designs.

Nothing fulfills the former, even though lots of people are researching it. On the other hand, I'd say FP fulfills the latter.

So the questions for me become about the spread of quality. Is the worst FP program worse or better than the worse OO program? And what about the best?

I'd personally say the worst of FP is better than the worst of OO, and similarly, the best of FP is better than the best of OO. That makes me prefer it overall as my paradigm of choice.

Even though this does mean you will find FP code bases that are worse than some OO code bases, but if you wanted to pick a paradigm in order for you to write a well designed program, FP would probably be a better choice, obviously, in my own opinion, so that's why I personally pick FP over OO.