OOP Is Dead, Long Live OOP • Hacker News Board

Re: OOP Is Dead, Long Live OOP

#321

Post by Gibbon1 » Fri, Oct 19, 2018, 9:58 AM UTC

letstrynvm wrote: post #318

vbsteven wrote: post #312

Earlier quoted context omitted.

I feel like this comment is exactly what the article refers to as the typical straw-man argument against OOP. Yes, a lot of bad enterprisey OOP code has been written in the last 20 or so years, but that does not mean things like design patterns, dependency injection and the Spring framework don't have their place. Don't throw the baby out with the bath water. Yes, AbstractClassFactorySingletonWhatever classes do exis…

> and still write maintainable, testable, extendable and configurable code. "reusable"... reusable code? That was the original point of OOP. After a few years being a believer n the late 90's as a C++ Ubermensch, I had the horrible realization neither I nor anyone else would reuse any of the classes I had given beautiful interfaces to, and carefully documented. Any time I spent planning for reuse I might as well have…

When I was doing hardware in the 80 early 90's I came to the conclusion that the 'reusable code' fans were all missing a point.

You are either writing a library,a framework, or something like that. Or you are implementing some 'business logic'

The point of the former is reusability. The point of the latter is utterly not and you should not waste your company's time and money or worse let schedules slip because of it.

Some further thoughts over the years.

Reuseable code must have a public, well designed, sable, and documented API or it won't ever be reused. Be honest how many programs are going to reuse this code? Enough to justify all the above? Didn't think so.

One of the problems with reusable code is dependencies. OOP code bases tend to have more than the ordinary number of dependencies.

Re: OOP Is Dead, Long Live OOP

#322

Post by barrkel » Fri, Oct 19, 2018, 10:21 AM UTC

DanielBMarkham wrote: post #67

FourthProtocol wrote: post #59

Took me a long time to grok OOP and OOD (was introduced to OOP in '91). At first I thought I knew it, and then realized I didn't. Plane into the side of the mountain, no survivors, call off the search. Which is when I really started to learn (around '96/97). And now I love it. Until I come across people who always start by defining an interface first and then think about what might follow. And dependency injection. H…

The thing I love about OOA/D/P is that it is a useful and productive way of thinking about things. It's probably even the most natural and intuitive way of thinking about them. Plato wasn't a C++ programmer, but classes and interfaces are direct descendants of his work 2k+ years ago. When I first fell in love with OO there was a time that I felt that there wasn't a problem in the world I couldn't solve using it. That…

Data flow. Closely related to functional programming, and also relational algebra. Different variants, whether reactive, push vs pull, streaming vs batch, restartable, etc.

Re: OOP Is Dead, Long Live OOP

#323

Post by vbsteven » Fri, Oct 19, 2018, 10:33 AM UTC

letstrynvm wrote: post #318

vbsteven wrote: post #312

Earlier quoted context omitted.

I feel like this comment is exactly what the article refers to as the typical straw-man argument against OOP. Yes, a lot of bad enterprisey OOP code has been written in the last 20 or so years, but that does not mean things like design patterns, dependency injection and the Spring framework don't have their place. Don't throw the baby out with the bath water. Yes, AbstractClassFactorySingletonWhatever classes do exis…

> and still write maintainable, testable, extendable and configurable code. "reusable"... reusable code? That was the original point of OOP. After a few years being a believer n the late 90's as a C++ Ubermensch, I had the horrible realization neither I nor anyone else would reuse any of the classes I had given beautiful interfaces to, and carefully documented. Any time I spent planning for reuse I might as well have…

I did not mention reusable anywhere in my comment. If you are writing code to be reusable, you are writing a library and in that case you better make sure that it is a separate project or module so no caller-specific details are leaking into your library.

Re: OOP Is Dead, Long Live OOP

#324

Post by letstrynvm » Fri, Oct 19, 2018, 10:57 AM UTC

vbsteven wrote: post #323

letstrynvm wrote: post #318

Earlier quoted context omitted.

> and still write maintainable, testable, extendable and configurable code. "reusable"... reusable code? That was the original point of OOP. After a few years being a believer n the late 90's as a C++ Ubermensch, I had the horrible realization neither I nor anyone else would reuse any of the classes I had given beautiful interfaces to, and carefully documented. Any time I spent planning for reuse I might as well have…

I did not mention reusable anywhere in my comment. If you are writing code to be reusable, you are writing a library and in that case you better make sure that it is a separate project or module so no caller-specific details are leaking into your library.

Yeah... you mentioned

>>> maintainable, testable, extendable and configurable

but not reusable. I'm not blaming you, or disagreeing... C++ didn't produce reusable results for me either.

I dunno what you were doing 20 years ago, but I was doing this... there wasn't any problem with the classes being unclean or the boundaries cut in the wrong place. It was simply I was almost never going to use those classes a second time. If they had been C functions, I would not have needed them a second time, either, almost always.

After a year or two I realized that being the case, the entire loving OO encapsulation of then was not simply worthless but an active waste of time. And I went back to C.

If you get value from other C++ things that make it worth paying the price, that's great. But file away for a possible future horrifying 3am realization, perhaps nothing is worth the price of a gyre like boost, and just writing it in high quality C may be a better answer.

Re: OOP Is Dead, Long Live OOP

#325

Post by cryptica » Fri, Oct 19, 2018, 11:07 AM UTC

vbsteven wrote: post #312

kamaal wrote: post #311

Earlier quoted context omitted.

>>When I read articles complaining about OOP, I just can't relate at all. Most problems start with OOP when people try to take the longest possible path to achieve a goal. Enterprisey code, like having to deal with thousands of classes(AbstractClassFactoryFactorySingletonDispatcherFacadeInitializer types), dependency injection, design pattern abuse. Then on top of this comes things like Spring framework etc. At that…

I feel like this comment is exactly what the article refers to as the typical straw-man argument against OOP. Yes, a lot of bad enterprisey OOP code has been written in the last 20 or so years, but that does not mean things like design patterns, dependency injection and the Spring framework don't have their place. Don't throw the baby out with the bath water. Yes, AbstractClassFactorySingletonWhatever classes do exis…

Yeah I have a feeling that some companies don't trust their engineers at all and so they want them to use as many tools as possible to reduce the likelihood of mistakes.

That's probably what functional programming, 100% code coverage and code linting trends are really about; allowing companies to not have to trust their engineers. I think this is a futile effort. If you want better code, just hire better developers with more experience who can be trusted. If you are not able to identify and recruit such people, then you shouldn't be a manager.

Bad developers will find a way to write terrible code; in any language, any paradigm, with strict linting rules enforced and even with 100% test coverage.

It really bothers me that most companies feel perfectly fine trusting financiers, lawyers and accountants with extremely sensitive company secrets and business plans but they absolutely refuse to trust engineers with their own code.

Re: OOP Is Dead, Long Live OOP

#326

Post by letstrynvm » Fri, Oct 19, 2018, 11:10 AM UTC

Gibbon1 wrote: post #321

letstrynvm wrote: post #318

Earlier quoted context omitted.

> and still write maintainable, testable, extendable and configurable code. "reusable"... reusable code? That was the original point of OOP. After a few years being a believer n the late 90's as a C++ Ubermensch, I had the horrible realization neither I nor anyone else would reuse any of the classes I had given beautiful interfaces to, and carefully documented. Any time I spent planning for reuse I might as well have…

When I was doing hardware in the 80 early 90's I came to the conclusion that the 'reusable code' fans were all missing a point. You are either writing a library,a framework, or something like that. Or you are implementing some 'business logic' The point of the former is reusability. The point of the latter is utterly not and you should not waste your company's time and money or worse let schedules slip because of it.…

Yes that's basically what I found too.

To practice OOP, its approach is every class should be a "library". Procedural code that doesn't have a class context is felt to be a shameful throwback to an earlier era degenerate C practices. From before some people feel they starting writing "good C++" apparently.

Re: OOP Is Dead, Long Live OOP

#327

Post by CMCDragonkai » Fri, Oct 19, 2018, 11:17 AM UTC

marcosdumay wrote: post #229

hota_mazi wrote: post #111

Earlier quoted context omitted.

You are confusing inheritance of implementation with inheritance of interface. The consensus is to use inheritance of interfaces and use composition to implement the interfaces. Hence my phrasing: "Inheritance is better achieved through composition".

> The consensus is to use inheritance of interfaces and use composition to implement the interfaces. A consensus by the "maximization of boilerplate" rule. Inheritance is the most powerful tool available at the OOP land. It's the one thing that FP languages still didn't replace with enough added advantages to make the OOP stuff look like a toy. So if you are programming in OOP while avoiding inheritance, you would be…

Check out extensible records or Nix language fix pattern for its attribute sets.

Re: OOP Is Dead, Long Live OOP

#328

Post by jcelerier » Fri, Oct 19, 2018, 11:57 AM UTC

maxxxxx wrote: post #273

spdionis wrote: post #224

Earlier quoted context omitted.

I think C++ is the only one that doesn't have interfaces.

An abstract class with only abstract methods is essentially the same.

It's most certainly not:

- you have to at least implement the destructor if you are going to use the abstract class across multiple DLLs - else, dynamic_cast won't work since each DLL may have its own type_info object for the abstract class

- even if a method is marked abstract, it can still have a default implementation: https://gcc.godbolt.org/z/bAE7v6 though other prominent OO languages are slowly catching up with this ;)

Re: OOP Is Dead, Long Live OOP

#329

Post by bunderbunder » Fri, Oct 19, 2018, 1:15 PM UTC

mikmoila wrote: post #162

bunderbunder wrote: post #49

Earlier quoted context omitted.

> But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. That may have been where Java wanted to go, but, when I'm working in Java, I don't feel like that's where I am. Ways of doing things in Java tend to be wildly inconsistent from project to project. Partially, I think, because so much core functionality in the Java ecosystem was allowed to be federated out to 3rd-part…

To be honest, I've never seen a problem I couldn't solve in easier way with core modern JDK libraries than with "3rd party" libraries.

It's definitely gotten better over the past 5 or so years. But there was a lot of time spent acquiring technical debt over the preceding couple decades.

Even if I don't use Guava or Apache Commons myself, for example, I still occasionally run into dependency conflicts that I need to resolve with awful hacks like package relocation because so many other major libraries rely on one or the other, and neither library is a particularly great citizen about breaking changes.

Re: OOP Is Dead, Long Live OOP

#330

Post by almostdeadguy » Fri, Oct 19, 2018, 1:45 PM UTC

cryptica wrote: post #325

vbsteven wrote: post #312

Earlier quoted context omitted.

I feel like this comment is exactly what the article refers to as the typical straw-man argument against OOP. Yes, a lot of bad enterprisey OOP code has been written in the last 20 or so years, but that does not mean things like design patterns, dependency injection and the Spring framework don't have their place. Don't throw the baby out with the bath water. Yes, AbstractClassFactorySingletonWhatever classes do exis…

Yeah I have a feeling that some companies don't trust their engineers at all and so they want them to use as many tools as possible to reduce the likelihood of mistakes. That's probably what functional programming, 100% code coverage and code linting trends are really about; allowing companies to not have to trust their engineers. I think this is a futile effort. If you want better code, just hire better developers w…

Where are there company executives that actually know and care about these kinds of things?

Some of what you're talking about can be overdone by engineers (i.e. 100% line coverage), but a lot of what you're talking about are tools engineers have developed to make their lives easier and to improve their code quality. A linter checks for common mistakes, clarity problems, and can help ensure code is written in a consistent style which improves readability. Functional programming is a coding style that doesn't always mesh well with the languages it's tried out in, but when it does it can provide enormous benefits in local reasoning about code and I think a large part of why it's seeing a resurgence is the experience of engineers having to build large, complex systems that become baroque and difficult to reason about in OO/procedural style.

This idea that good engineers have perfect competency and write code that immune from the problems these tools help solve is absurd and totally disconnected from the reality of the challenges involved in building software. Even the best, and most respected engineers write code that is riddled with bugs, and there are CVEs to prove it.

Engineering tools and new paradigms weren't invented to add friction and police developers, they were invented to aid our very real, human cognitive limits in writing software. If anything some of these things make the process more enjoyable and far less error prone.