The Case Against OOP Is Wildly Overstated • Hacker News Board

Re: The Case Against OOP Is Wildly Overstated

#261

Post by UnFleshedOne » Sat, Aug 01, 2020, 3:23 AM UTC

winstonewert wrote: post #155

karpierz wrote: post #106

Earlier quoted context omitted.

In what versions of OO does a hash map hide the data? The definition of a map requires that you can access the data.

A hashmap wouldn't hide the data. But say, a Customer object might. A purist OO might insist that you shouldn't have a GetName() method because any code which needs the Customer's name should be method on Customer.

This particular example is probably a bad illustration, with all the recent rage about PII and privacy. In some cases (such as this) you want to make sure data doesn't leak all over the place and anything accessing it follows a strict path.

Anybody modifying Customer object would hopefully be in the right mindset regarding personal information, but once it gets out as a string from GetName or GetEmail, all bets are off, it gets into all kind of logs.

Anything security related is the same.

Re: The Case Against OOP Is Wildly Overstated

#262

Post by mnm1 » Sat, Aug 01, 2020, 4:00 AM UTC

zbentley wrote: post #233

mnm1 wrote: post #133

Earlier quoted context omitted.

Yeah, why spend hours on the most important part of the application and likely the most important part of the business when you can gloss over with with an ORM and not worry about designing the database until it comes back to bite you in the ass when you can no longer grow your business because of the incredibly stupid thing you did which is not designing your database. Frankly, those businesses deserve to fail if th…

I suppose they deserve the same fate if they didn't get security right from day 1? Or accessibility? Or monitoring? Analytics? GDPR compliance? Etc.? Businesses are confronted with different problems at different times. Insisting that everything be solved/designed perfectly up front is silly.

None of those things can even remotely compare to the importance of the database design for most software businesses, especially ones just starting out. Most of them can also be addressed later in the company's life unlike a bad database design.

Re: The Case Against OOP Is Wildly Overstated

#263

Post by nostrademons » Sat, Aug 01, 2020, 6:36 AM UTC

lmm wrote: post #256

nostrademons wrote: post #98

Earlier quoted context omitted.

More concretely, for every bit of state in the program I'm interested in two big questions, each with two subquestions: 1.) Who can access this state, and which of those accesses allow writes vs. which are read-only? 2.) What is the lifetime of that state, and what portion of that lifetime is mutable vs. read-only? Java-style OOP can control #1, but makes no distinction between reads & writes. C++ const correctness a…

> I'm still waiting for a language feature that lets you say "This field of this struct is only mutable while this module is running, and once it completes it will never be changed", though. A lot of data structures are initialized in passes and then passed along as constant data: you construct the basic object structure with nothing but a few IDs, then you compute extra fields as necessary, then you're done and the…

You can do this, but unless all the intermediate types are auto-generated by the compiler, it's going to be a lot of typing (of the keyboard type). Many structs that require multi-pass initialization have many, many fields. Each field that isn't late-initialized is going to be duplicated for each following pass. That's the type of maintenance headache that compilers are meant for.

Re: The Case Against OOP Is Wildly Overstated

#264

Post by Ace17 » Sat, Aug 01, 2020, 7:57 AM UTC

cellularmitosis wrote: post #240

lkrubner wrote: post #93

Earlier quoted context omitted.

I was about to write exactly this. In 2014 I wrote an essay that has been discussed here on Hacker News several times [1]. When I re-read it now, parts of it seem very subtle, parts of it seem to be matters of opinion, but what jumps out is how really dangerous it is to tightly bind data with behavior, especially because this then leads to the problem of initiation (which I devote a lot of time to talking about in th…

Thank you for this. I am so tired of this exchange: A: OOP isn't so bad, actually. B: But what about all these terrible messes? A: Oh, that's not a problem with OOP, they're just doing it wrong. I'm sorry, but when 80% of the industry (and 100% of new grads) are "just doing it wrong", it isn't helpful to no-true-scotsman the critics. The only way I see out of this endless game of semantics is for someone to canonize…

> The only way I see out of this endless game of semantics is for someone to canonize the tightrope of practices which are "OOP done right", and then give it a different name.

Our industry has a naming problem when it comes to practices, especially when the practice is subtle and complex but its name is simple and trendy (maybe it's not specific to software, IDK).

Dev teams are mislead into thinking that they can deduce the practice from the name (and maybe a 1h training with a self-proclaimed expert in the practice).

This is how we got aberrations like: - "TDD" devs writing their tests afterwards - "Agile" teams with 6-month release period - "SCRUM" masters that act as classic managers

New names referring to "good/right/trendy" practices are doomed to get claimed by "80% of the industry", in a way that doesn't respect the original practice.

Alan Kay recently said that maybe he should have called it "Message-oriented programming" ( instead of OOP ). While not having "object" mostly eliminate the risk of the "one-class-per-real-world-object" antipattern, we might as well had ended up with other anti-patterns based on wrong interpretation of what constitutes a "message".

This is why I think changing the name of any practice is inefficient. The misunderstanding isn't accidental, it's systemic (Moreover, renaming a practice would probably create even more confusion)

Names that refer to common mistakes wouldn't get claimed ; no team is going to proudly explain to their customer that they're using the "big ball of mud" antipattern, the "scrum but" team organisation, or the "debug later" dev practice.

So maybe we should better canonize OOP antipatterns?

Re: The Case Against OOP Is Wildly Overstated

#265

Post by lmm » Sat, Aug 01, 2020, 8:04 AM UTC

nostrademons wrote: post #263

lmm wrote: post #256

Earlier quoted context omitted.

> I'm still waiting for a language feature that lets you say "This field of this struct is only mutable while this module is running, and once it completes it will never be changed", though. A lot of data structures are initialized in passes and then passed along as constant data: you construct the basic object structure with nothing but a few IDs, then you compute extra fields as necessary, then you're done and the…

You can do this, but unless all the intermediate types are auto-generated by the compiler, it's going to be a lot of typing (of the keyboard type). Many structs that require multi-pass initialization have many, many fields. Each field that isn't late-initialized is going to be duplicated for each following pass. That's the type of maintenance headache that compilers are meant for.

If you have higher-kinded types and a working record system you can do it by transforming your existing types. Even in more limited languages you might be able to make it manageable with phantom types, e.g. Java's "type-safe builder pattern".

Re: The Case Against OOP Is Wildly Overstated

#266

Post by mpweiher » Sat, Aug 01, 2020, 8:15 AM UTC

liability wrote: post #47

xtian wrote: post #24

Earlier quoted context omitted.

Is there controversy about what FP “actually means”?

The only real contention seems to be whether "functional programming language" should describe languages that merely facilitate functional programming (e.g. lisp), or only to those that enforce it (Haskell.) Otherwise, whether or not a procedure is a function is about as clear cut as you can get. It either is or it isn't, it's not subjective.

> whether or not a procedure is a function is about as clear cut as you can get

Definitely.

If it returns a single value then it's a function. If it does not return a value, it's a procedure. (Pascal)

All procedures are functions (C)

All procedures and methods are functions (Swift)

A Function procedure is a series of Visual Basic statements enclosed by the Function and End Function statements. (Visual Basic)

...

Re: The Case Against OOP Is Wildly Overstated

#267

Post by chongli » Sat, Aug 01, 2020, 10:51 AM UTC

Barrin92 wrote: post #13

lgessler wrote: post #4

This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.

The entire point of OOP is to encapsulate state within objects and to have objects communicate through messages, that is to say to 'program without a center'. Global or interconnected state is if anything a violation of OO principles. In proper OO state is hidden and insofar as it causes issues it does so in a way that is handled by the object rather than the program overall. Also treating code as data isn't a featur…

entire point of OOP is to encapsulate state within objects

And that’s the fundamental problem with OOP. State can’t be encapsulated. It’s highly radioactive. State should be kept to the boundaries of your application, where it interfaces with the real world, and minimized as much as possible. The core should be immutable.

Re: The Case Against OOP Is Wildly Overstated

#268

Post by thu2111 » Sat, Aug 01, 2020, 10:53 AM UTC

mhoad wrote: post #241

correct_horse wrote: post #216

Earlier quoted context omitted.

This is generally accurate, but I want to highlight the awesomeness of opaque structs. In C you can declare a struct in a header file, but not its fields ie struct point;. Then in the corresponding c file you can write out the whole definition ie struct point {x: float; y:float;};. Any code that includes the header can pass pointers to struct point (or pointers to pointers, etc) but can't directly pass points around…

This might sound stupid but I have ONLY ever known OOP in the Ruby / C++ / Java sense before but this idea blew my mind as such an interesting and different way of thinking about it and I can't tell if it is just my own bias but my initial thought is that it seems like such an additional level of mental overhead that you would always have to carry around on top of everything else you already have to think about. I as…

It's just an attempt to make C slightly more OOP without using C++. A very common design pattern in GNOME, for instance.

Re: The Case Against OOP Is Wildly Overstated

#269

Post by GordonS » Sat, Aug 01, 2020, 10:57 AM UTC

vsareto wrote: post #102

skrtskrt wrote: post #8

The author is right about ORMs. They are ridiculously over engineered solutions. (My experience is largely with Django and SQLAlchemy ORMs) As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Autogenerated Django migrations are unstable and often need to be edited to to be correct or make any damn sense. It also encourages to people to blur or ju…

>As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Use the ORM for perfectly built in things, but also use raw SQL when it's not.

This is a pattern I've used before with dotnet, and I think it works quite well.

Generally we start with Entity Framework Core, because it's well known and let's us compose and execute queries really easily (I should add we always use a "code first" approach; the actual database is created carefully by us, not the ORM).

For some apps, you need to do more complex stuff, such as use composite keys, duplicating rows, etc - while this might technically be possible with EF Core, it's horrible in practice. Also in some cases you just can't coax EF to generate a performant query. In these cases we either add a view, or we add a micro-ORM into the mix, like Dapper - you basically write the SQL yourself, but Dapper helps marshal data from the database to your classes.

Re: The Case Against OOP Is Wildly Overstated

#270

Post by phendrenad2 » Sat, Aug 01, 2020, 11:57 AM UTC

wvenable wrote: post #156

phendrenad2 wrote: post #131

OOP is a crazy academic-esque idea that happened to stick because it works at scale. When you have hundreds of programmers working on a codebase, it's useful to constrain people with UML diagrams and rigid hierarchy. Otherwise, cowboy coders hack up something the other 90% of coders can't understand. This is why languages like Scala and Haskell haven't taken off outside of a few small-team-focused niches, like data s…

> OOP is a crazy academic-esque idea that happened to stick because it works at scale. I suppose it's weird to be young enough that you're first exposure to OOP is it being taught in an academic environment. It must make it seem like it was dreamed up like some kind of formalism and spewed into your brain. But before OOP languages and everything that you describe, people using plain old procedural languages were alre…

True, a lot of OOP is stuff that you might develop on your own, if you were writing a lot of code back in the procedural days. But computer science has been with us since the beginning of computers, and certainly OOP as we have it today, with all of it's formalism, probably started back then in computer research institutions like MIT and Stanford.