Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Case against OOP is understated, not overstated (2020)

boxbase.org

Post reply on HN
Print view View original

541–550 of 557 posts

Re: Case against OOP is understated, not overstated (2020)

#541

Post by deltaonefour »

everyone wrote: post #536
deltaonefour wrote: post #288

Earlier quoted context omitted.

You don't understand. This is not what FP programmers are arguing about. What FP programmers are arguing about is that all code becomes shit if you do OOP. It doesn't matter how good you are. They argue that if you do FP your code is much less likely (note the word likely) to be shit. The analogy to carpentry or craftsmanship is bad. Programming is about managing complexity to a degree no one can fully hold in their…

It sounds like you don't understand about various crafts. To me they are a quite analogous to programming. Also, code has barely changed at all since C. It's all just some variables, loops, flow control, some math operations and doing stuff with strings sometimes. One can write functionally in an OO language. No paradigm or design pattern or whatever will save you from making a mess. For me, the more experienced I've…

> It sounds like you don't understand about various crafts. To me they are a quite analogous to programming.

I understand every craft. They are analogous in the simple minded way you're thinking about it. However complexity in these crafts does not rise to the heights like the way it does in programming. That is the key difference.

>No paradigm or design pattern or whatever will save you from making a mess

This is fundamentally backwards. The FP style saves you from all errors related to mutation. This single statement already proves you wrong. You can't mutate a variable so that's one mess literally taken off the table. There are patterns that can provably prevent errors from happening and you can create languages that strictly enforce certain patterns.

Elm for example, cannot have runtime errors. The language strictly prevents that "mess" from happening.

Outside of strictly enforced patterns the FP pattern promotes better organization. You can still make a mess. But you are less likely to make a mess. Additionally for extremely large programs the proportion of technical debt will be significantly less for an FP styled program than an OOP styled program. See below for one instance of this.

http://wiki.haskell.org/Why_Haskell_just_works

>For me, the more experienced I've become, the less those things matter.

I've found that people who brag about experience doesn't make them smart or good programmers. You have limited intelligence and no matter your level of experience there are just design mistakes you make all the time in extremely large programs. Technical debt is an unsolved issue. Though the claim here is that FP programs tend to have less debt than non-FP programs. The keyword is "tend" as there are exceptions but the generality is mostly true.

Re: Case against OOP is understated, not overstated (2020)

#542

Post by wpietri »

magpi3 wrote: post #380
wpietri wrote: post #305

Earlier quoted context omitted.

What sort of domains do you see as sufficiently well-understood and stable where this process is even achievable? A lot of my career has been in domains where we are exploring problems by building and shipping things to see what really works for users and customers. And other times there's domain volatility driven by changes in technology and competitive landscape. Even for domains that are stable and knowable, I hav…

Compilers maybe?

Ooh, interesting! You're right, there's a class of domain where one can just push the real-world change to the edges of the system and ignore it. E.g., there's surely software that's mainly about complying with laws.

But even there, I suspect adaptation has to happen. Python's had how many versions over the years? Indeed, I could argue that it's one of the world's most successful languages precisely because it keeps responding to user need. Or look at tax software, which is going to change at least every year, and more often in emergencies.

So I suspect at best these other domains have a slower iteration clock. Which might be slow enough for the sort of formal modelling that is described. But then I think there's an open question: do other methods also work just as well with slow iteration clocks?

Re: Case against OOP is understated, not overstated (2020)

#543

Post by spacechild1 »

aeldidi wrote: post #518
spacechild1 wrote: post #414

Earlier quoted context omitted.

> operator overloading caused more problems than they solved [citation needed] Just because operator overloading can be abused doesn't mean that it isn't a massive boon in certain problem spaces (e.g. math libraries, SIMD libraries, etc.)

I mean, the standard way to do IO in C++ involves spamming the left shift operator ( 1. translating format strings to other languages is extremely difficult because the position of expressions in the message is fixed. 2. modifying how things are printed requires modifying global state, and it's easy to forget to reset the flags on std::cout after setting the precision of floats or something. There's also the famous q…

> 2. modifying how things are printed requires modifying global state

This only applies to std:: cout and std::cerr. Other stream interfaces, like std::fstream or std::stringstream don't have this problem. Also, it is orthogonal to operator overloading.

Re: Case against OOP is understated, not overstated (2020)

#544

Post by ByteJockey »

jiggawatts wrote: post #85
ByteJockey wrote: post #66

Earlier quoted context omitted.

> Has anyone seen large scale development done successfully in an an "anti-OO" language like Rust? Taking "anti-OO" to mean languages that specifically don't have OO capabilities (rather than languages where you can choose not to use OO). Any of the large C code bases?

Very often in code like that you see "struct" types filled with function pointers.. Those are literal OO "vtables", just implemented manually instead of being generated by the compiler. The Linux kernel is huge, yes, and is written in a "pre-OO" language. It's also full of OO paradigms. For example, the core kernel developers don't want to have to write huge "switch" statements to handle the thousands of different dr…

> Very often in code like that you see "struct" types filled with function pointers.

Fair point. Though with the explicitness that's required to do this in C (you have to pass the actual struct pointer that would normally be the receiver, along with a general lack of inheritance) results in code that's much easier to understand than the patterns that the traditional OO languages have created for themselves. I suppose that's less of a criticism of OO itself and more of a criticism of the people who build languages that emphasize OO, and the general ecosystems that crop up around them.

> written in a "pre-OO" language

I would be remiss if I didn't point out that the "OO languages" go all the way back to Simula67, which predates C. Though at that point OO was still in its "academic" phase the way functional programming is today.

Re: Case against OOP is understated, not overstated (2020)

#545

Post by mycall »

agency wrote: post #70
taurath wrote: post #14

In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…

There's a really wonderful talk that I've recommended to almost everyone I've ever worked with called Simple Made Easy[1] by Rich Hickey. I also struggled to explain why I hated state so much. You can talk about races with shared mutable state but even single threaded code I found I couldn't stand it, that it made things harder to reason about and change. It's because state is complex , in the sense Rich discusses in…

> State intertwines "value" and "time"

Reminds me of deterministic finite automaton. Is that what you mean?

Re: Case against OOP is understated, not overstated (2020)

#546

Post by q-base »

sirwhinesalot wrote: post #392
q-base wrote: post #337

Earlier quoted context omitted.

Would you mind explaining this part a little more - I do not get the difference between a Customer class and a customer as a unique entity represented by an ID? "That said, best thing you can learn in your programming career is to get rid of "Customer" classes (or whatever the equivalent is for your particular problem). A customer is a unique entity represented by an ID, a private key if you will, which links data in…

Hi q-base, it all comes down to the single responsibility principle. What is the single responsibility of the Customer class? What methods should it have? What does a Customer do exactly? Or is it just a POD which simply stores customer data? If so which data? Does it mix authentication information with the user's purchase history? Maybe not that but what about the user's little Avatar in the UI? The answer is none o…

Thank you very much for for detailed response. Now I understand where you are going with it. It seems very powerful and would illicit endless expandability. Because I have not thought about modelling it on such abstract level before I am left with some questions as to how complex a model this leaves. I do not know if I am too locked in OOP-land but I like that with this thinking, you can have a SSN table for instance that references this ID and limit access to it on that level instead of having to scramble parts of tables for instance. I can also see it being useful for endless additions of tables that can relate to that ID.

But I cannot fully comprehend in which scenarios this would be a clear winner and which it would add too much overhead. There is something to it though, so thanks for opening my eyes.

Re: Case against OOP is understated, not overstated (2020)

#547

Post by deepsquirrelnet »

LadyCailin wrote: post #198
throwawaylinux wrote: post #65

Back in the 90s OOP was touted as revolutionary. The next big thing, would completely change programming. If something wasn't object oriented, it was looked down upon. SQL even got on the bandwagon. It was said that very complex inheritance structures, operator overloading, and all this other stuff would (somehow) make it far easier to write and understand complex projects. Many seemed to have taken and repeated this…

Wait, what’s wrong with NoSQL? It’s not good for shoving relational paradigms into, but it’s basically infinitely horizontally scalable, which, as far as I’m aware, isn’t possible with relational DBs, not at the same performance at massive scale, anyways. A bit annoying when people shove a relational DB into a NoSQL schema though.

Nothing is wrong with NoSQL except for how it (often) gets used. NoSQL is just a dumping grounds for less-structured data that allows startups to accumulate tech debt more rapidly, while providing enough functionality to be useful.

Where I've seen it used is to delay the decision making process of adding structure to data, or a prototype database, before you are certain what your application's needs are. For simple disconnected data in low performance applications, they provide a low barrier to entry. But eventually people start embedding foreign keys into documents and the whole thing goes South.

Re: Case against OOP is understated, not overstated (2020)

#548

Post by deepsquirrelnet »

indymike wrote: post #133

I'm convinced the big win with OOP was more about modularity and encapsulation than OOP. The whole object.method() or object.variable model was pretty nice after spending years dealing with global soup or using naming conventions. The not-so-good part in particular happened when you inherited one too many times... very easy to write, and very hard to debug, maintain, and sometimes test. A lot of OOP's success it was…

This is my thought as well. There are still good reasons for using inheritance. In the right use cases, overloading methods can be a life saver. But generally, I have gravitated away from using those patterns, and toward things like composition, which are simpler and seem to be much less fragile.

Recently, I've enjoyed the simple utility of python's functools library. Small-inheritance-like functionality seems to find a happy medium in a lot of cases, while avoiding a lot of unnecessary abstraction and boilerplate.

Re: Case against OOP is understated, not overstated (2020)

#550

Post by alatkins »

baryphonic wrote: post #283
butwhywhyoh wrote: post #166

Earlier quoted context omitted.

The problem I have with talks like this is that they sound fantastic on the surface. They almost sound self-evident! "Duh! I want to make simple things, not easy things! That was great!" But where are the examples? Not a single example of something easy versus simple, or how something "easy" would resist change or be harder to debug. All of these concepts sound fantastic until you begin to write code. How do I apply…

If you want functioning, robust, maintainable software (or even better, software that doesn't require maintenance), then spend a long time modeling the problem domain. Build it as a system of types, a protocol, perhaps even a language (or at least an AST with semantics). Prove things about this model, particularly some useful things about soundness, consistency and (in)completeness. Learn all the funky symbols people…

Counterpoint is that the Big Design Up-Front utopia didn't win in software, giving rise to Agile (for better or worse).
Post reply on HN