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

241–250 of 557 posts

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

#241

Post by acchow »

lamontcg wrote: post #167
ctxc wrote: post #130

Earlier quoted context omitted.

I still don't understand why it's bad! Feels like spaghetti sentences tied together as a single article. Why is OOP so bad, anybody? With scenarios, code samples or alternate implementations?

I think the major problem is that base classes are really two different interfaces (public and protected) combined with a default implementation, all exposed as a public symbol that anyone can reference. So if you have a Vehicle base class with Car and Truck that inherit from it people will naturally externally do things like pass around List and will extend functionality with Lorry : Vehicle and start using it. This…

After quite some time with OOP, I rather just use it without inheritance (at least in business logic; inheritance is still useful in libraries).

In which case, it would be nice if the language supported ADTs

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

#242

Post by jackblemming »

butwhywhyoh wrote: post #166
agency wrote: post #70

Earlier quoted context omitted.

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…

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…

Easy things work until you have to extend them or do anything the least bit complicated. Think of SQL or most "easy" declarative APIs. Or even worse, ORM engines. Simple things are normally also easy to use, but you may have to write some more boilerplate and there's less "magic".

Steve wrote a simple CRUD API that gets some data and returns it. Bob tried to be clever and write a loosly typed declarative cluster fuck that nobody understands, but it's "easy" if you dont do anything interesting or useful with it.

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

#243

Post by nyanpasu64 »

dwohnitmok wrote: post #179
taurath wrote: post #164

Earlier quoted context omitted.

I appreciate the thought process here, and I'd want to spend more time thinking it over before a full response - though I think it maybe goes a little bit too into etymology for my taste! My immediate comment is that working memory is a measurable finite resource that developers have to use. The more entities they have to track in order to model the part of the system they're working on, the more usage of working mem…

First off I don't think this is quite the way Hickey thinks about the issue (though I suspect he would agree about the working memory part), especially with the comment about etymology /s!(it's a meme in Clojureland that every Hickey presentation and library must contain at least one slide on/mention of etymology) In particular Clojure as a whole embraces an ideology of "open systems" vs "closed systems" where we sta…

> But what if that's just a problem with our tools rather than an intrinsic issue? What if I had a tool that could automatically present all the mutable state of your system that is publicly accessible as a single screen and automatically link to different procedures that link to different parts of it?

The world needs this. I think Pernosco has a workable technical foundation, but the GUI is a debugger and I need a code exploration tool to "find my way" in big unfamiliar codebases. Encouraging developers to pick up and hack around in others' codebases is the only way to get enough eyeballs to make all bugs shallow.

> maybe it's nicer to have that implicit state strewn everywhere instead of having to carry around values which are irrelevant for the bulk of a function body and only relevant for a single part of a subfunction.

I think global state (which is unusually bad) or shared mutable state (which is omnipresent outside of Rust) is a mental overhead (more things to keep in mind). I don't think tooling can eliminate the overhead of worrying about moving parts, only make it faster to look up (and hopefully document) what touches each bit of state.

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

#244

Post by Nursie »

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.

> Wait, what’s wrong with NoSQL?

For a few years back there, it was going to take over the world and we were all going to throw away 'old fashioned' DBMSs because they were slow, clunky and overcomplicated.

Like many of these overhyped technologies, when the dust cleared about 5 years down the line, we are left with something useful that definitely has its place, but isn't like wow huge it's taken over everything maaaaan. Meanwhile SQL is still with us and still good at what it does too.

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

#245

Post by jcranberry »

ctxc wrote: post #130
zozbot234 wrote: post #20

This is basically a survey of a bunch of posts, and doesn't do much to provide a consistent critique. Regardless, the true weak point of OOP is arguably implementation inheritance, which just doesn't leave you with a consistent semantics that's open to extension and changes in the basic/derived classes (that is, the well-known "fragile base class" problem is still a showstopper). But that has always been a pretty ad-…

I still don't understand why it's bad! Feels like spaghetti sentences tied together as a single article. Why is OOP so bad, anybody? With scenarios, code samples or alternate implementations?

There is a famous paper called 'out of the tar pit' which may be somewhat related.

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

#246

Post by thangalin »

The PersonnelRecord isn't OOP and exhibits a widespread misunderstanding:

    class PersonnelRecord {
    public:
      char* employeeName() const;
      int   employeeSocialSecurityNumber() const;
      char* employeeDepartment() const;
    protected:
      char  name[100];
      int   socialSecurityNumber;
      char  department[10];
      float salary;
    }
As written, PersonnelRecord class will inevitably lead to code duplication, tightly coupled classes, and other maintainability issues. An improvement that's still not OOP, but exposes a more flexible contract, resembles:

    class Employee {
    public:
      Name name() const;
      SocialSecurityNumber socialSecurityNumber() const;
      Department department() const;
    private:
      Name name;
      SocialSecurityNumber socialSecurityNumber;
      Department department;
      Salary salary;
    }
OOP is more about the actionable messages that objects understand to carry out tasks on behalf of other objects. Wrapping immutable data exposed via accessors reaps few benefits. Rather, OOP strives to model behaviours that relate to the problem domain:

    class Employee {
    public:
      void hire();
      void fire();
      void kill();
      void raise( float percentage );
      void promote( Position position );
      void transfer( Department department );
    private:
      Name name;
      SocialSecurityNumber socialSecurityNumber;
      Department department;
      Salary salary;
    }
This allows for writing the following code:

    employee.transfer( department );
I don't know how to "transfer" an employee given the code from the article, but it would not be nearly as elegant.

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

#247

Post by jcranberry »

wainstead wrote: post #217
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…

> Were there ever any real objective [hah] studies done about how much it improved software development? And did they show a significant improvement? I think years of hard experience across the industry found out that, for example, multiple inheritance and operator overloading caused more problems than they solved. Both features were taught and advocated back in the day, and now "there be dragons" signs have sprung u…

I've actually never really encountered issues with operator overloading. Is it just ADL, or are there any other canonical operator overloading issues?

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

#248

Post by dwohnitmok »

jolux wrote: post #238
dwohnitmok wrote: post #229

Earlier quoted context omitted.

> Threading mostly-irrelevant state through a bunch of different functions is a sign that your program is under-abstracted. The problem is that often you do want fairly complex state in the leaves of the tree, but want very little of it in anything else. Web browsers are a classic example of this. Pure FP solutions such as Elm that completely eschew the idea of local mutable state require a lot more ceremony to imple…

I will say plainly that I think there are situations in which mutability offers more elegant solutions than immutability, but I think most languages that offer it do it badly. I’m most experienced programming the Erlang platform via Elixir, and I think it offers a really nice midpoint between locality of state and purity. Within a process everything is immutable, and mutation requires sending a message to a process t…

> to the example of a web browser I would say, most applications are not web browsers.

I should've clarified. I meant developing a web page to run on a web browser, hence the form example.

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

#249

Post by synergy20 »

I have no idea about the points that post is trying to make.

OOP like everything, using it incorrectly will lead to trouble, and it has its merits when done right. plus, it's used widely in practice that is really the best evidence in that, it's not bad at all.

use FP all the way IMHO will lead more spaghetti code, use it to complement OOP could be great however.

Last, what's the alternative? if you don't have a better alternative, you don't solve any existing problem.

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

#250

Post by nyanpasu64 »

sirwhinesalot wrote: post #39

I have not read the article but I've seen other blog posts on the subject. The issue with "OOP is bad" is that OOP means different things to different people. Abstract Data Types are sort of a subset of OOP and are massively useful, I certainly don't think it's a good idea to expose the internal implementation of a data structure most of the time. Any sort of plugin system works in an OO matter. It is a useful tool,…

Do relational models support sum types? I find them an essential feature in programming languages, nearly as important as structs or rows.
Post reply on HN