Was object-oriented programming a failure? (2015) • Hacker News Board

Re: Was object-oriented programming a failure? (2015)

#91

Post by sbov » Sun, Mar 12, 2017, 6:49 PM UTC

jpalomaki wrote: post #79

I think one major problem with OO was that many people did not really get object oriented thinking (and I was probably among them). It is very easy to do objects that are just dummy data container instead of smart things that interact with each other. Just think how many Java tutorials started with the procedural "Hello World" example and then proceeded to introduce objects and taught the idea of encapsulation by rem…

You are glossing over a lot of design decisions by excluding method arguments.

Whether or not that is a proper solution depends upon the requirements.

A more useful example for beginners would be showing when you want an "eat" on a person class vs an "eaten by" on a food class vs when you need to pull out something more heavy handed.

Eg if your only axis of change is the foods you eat, and behavior is based primarily upon food, person as a dumb bag of data is likely the correct answer. Your behavior should probably be in a food class.

Re: Was object-oriented programming a failure? (2015)

#92

Post by vatotemking » Sun, Mar 12, 2017, 7:04 PM UTC

geophile wrote: post #6

I view OO as analogous to the earliest control structures added to programming languages. We all remember "GOTO considered harmful", including generations of programmers who weren't alive when the letter was written, and may not have read it. Around that time, language designers realized that GOTOs were used to implement the same patterns over and over: Conditional execution, looping of various kinds. And we ended up…

I find goto useful when writing windows batch files. :-)

Re: Was object-oriented programming a failure? (2015)

#93

Post by ZakTaccardi » Sun, Mar 12, 2017, 7:14 PM UTC

I started off a recent project in Java (heavy use of RxJava). Over time it migrated to a largely Kotlin codebase, which lends itself well to either OOP or functional.

I realized, so many of my method calls on my objects were only ever used once. Sometimes I'd create a class which just had one method. I had to assign a good name to this class, and it's method. I've since switched to heavy use of extension methods in Kotlin, and found I was mocking less for many tests, and writing less code that accomplished more. And variable naming was simpler.

At the end of the day, a good blend of OOP and functional programming are where it's at

Re: Was object-oriented programming a failure? (2015)

#94

Post by ziotom78 » Sun, Mar 12, 2017, 7:37 PM UTC

_0w8t wrote: post #16

gpderetta wrote: post #4

Earlier quoted context omitted.

Exactly. "Everything is an object" was an extremism (today's extremism is the crusade against 'mutable state'), but otherwise OoO has been useful. For example it has seen great success in GUIs.

I can definitely state that OOP allows to implement GUI. But "great success" I can see only for vendors selling OOP tools for GUI development. Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better. Or consider QT. My colleagues with a lot of QT experience use QML to create GUI. They avoid any C++ GUI code unless it…

Well, I used to bash C++ and OOP programming till not a long time ago, but I am slowly reconsidering my ideas.

I am now learning Rust, and for this purpose I am trying to implement a small TUI (Text User Interface) framework. In order to get some ideas, I dug in my library and found the Turbo Vision User's Manual that was bundled with Borland Pascal 7.0 [1]. Reading it after so many years made me wonder how could they create such a complex and well-thought framework that was truly usable for your own stuff, given the technology and knowledge available 30 years ago. The text often underlines that a lot of features were possible thanks to the OOP constructs implemented in Turbo Pascal, and I believe them. I think that OOP importance might have faded today, but its historical significance for the development of GUIs and TUIs should not be underestimated.

P.S. I am trying to implement my library in Rust, which is not an OOP language, and so far have found no blocking point: traits and containers are more than adequate replacements for the kind of polymorphism and inheritance used in libraries like Turbo Vision. But my point still stands: once we learned that polymorphism and inheritance were useful to solve some specific problems, we have derived better ways to achieve the same purpose.

[1] https://archive.org/details/bitsavers_borlandTurrogrammingGu...

Re: Was object-oriented programming a failure? (2015)

#95

Post by coldtea » Sun, Mar 12, 2017, 7:55 PM UTC

mattmanser wrote: post #87

coldtea wrote: post #36

Earlier quoted context omitted.

> Admittedly, it's one of those projects which has had a bunch of freelancers/contractors work on it, but I personally really don't see what it added to move the methods off the classes apart from confusion, code duplication and code bloat. Moving the methods off the classes would actually lead to less code duplication -- as now different data that need the same treatment can be handled with the same methods. "Loads…

as now different data that need the same treatment can be handled with the same methods. That just doesn't happen enough in real life to design around. In the rare instances when you do need to that, it's trivial to handle with interfaces and a wrapped method that calls a shared function.

>That just doesn't happen enough in real life to design around.

On the contrary, I think it does. Especially for web, enterprise and application programming, 90% of the logic is the same tired data transformations.

Re: Was object-oriented programming a failure? (2015)

#96

Post by oblib » Sun, Mar 12, 2017, 8:13 PM UTC

Funny how this subject has progressed. I recall writing perl code and being pretty happy with the results until I heard that "functional" programming was crap. Soon after Perl added a "OOPs" layer that coders either rejoiced over or complained about and I couldn't help but think "Do I really need to write code this way?"

After a couple decades of coding I've come to the conclusion that "easy" is almost always better. There isn't much code I wrote 20 years ago that anyone is using today but where it is in use it runs without needing to be updated or maintained.

Most of my apps are now mostly written in Javascript, and I write them very much the same as I did in Perl. I use a mix of both "functional" and "object oriented" methods and don't worry about what others think of it.

Of course, I'm not doing "AI" or anything close to that. I make apps for business management and they care a whole lot more about the UI, reliability, and security, than what the code looks like. The only thing I ever get when showing them code is a glassy eyed look of despair and worry that I won't stop.

Re: Was object-oriented programming a failure? (2015)

#97

Post by jimmaswell » Sun, Mar 12, 2017, 8:41 PM UTC

alkonaut wrote: post #82

jimmaswell wrote: post #73

Earlier quoted context omitted.

>It was sold on the promise of reuse but accomplishes it at the expense of understandability and maintainability. I have never dealt with code in practice that was less maintainable and understandable because of OO. Do you have a specific example?

I think it's usually the case that mutability and inheritance is overused leading to deep and/or unnatural abstractions and code that is hard to reason about. Working with a hierarchy many levels deep with overrides on every level means it's very hard to reason about the code as the call stacks ride an elevator up and down the class hierarchy. Don't get me wrong - this is not an inherent drawback with OO, this is bec…

A codebase I work on at the moment has some hierarchies go to at least 6 or 7 levels, and I haven't had a problem with it. The way it's used doesn't hurt the ability to reason about it, it's just a logical progression of categories of objects getting more specific as they branch out. This is at the same time that a lot of composition and components are used.

I'd say excessively deep class hierarchy or bad abstractions are still a lot better than similarly "bad" imperative or other code, not sure about functional though.

Re: Was object-oriented programming a failure? (2015)

#98

Post by braveo » Sun, Mar 12, 2017, 8:41 PM UTC

coldtea wrote: post #35

_0w8t wrote: post #16

Earlier quoted context omitted.

I can definitely state that OOP allows to implement GUI. But "great success" I can see only for vendors selling OOP tools for GUI development. Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better. Or consider QT. My colleagues with a lot of QT experience use QML to create GUI. They avoid any C++ GUI code unless it…

> Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better. That's because there are no decent OO based web UIs, because the web development experience and stack is a total mess to begin with.

ASP.Net Web Controls was an attempt at bringing the desktop technologies like MFC to the web, and it was a horrible horrible idea.

The worst part is that everything else about the original ASP.Net was mostly really good ... but Web Controls completely destroyed it's reputation.

Re: Was object-oriented programming a failure? (2015)

#99

Post by jimmaswell » Sun, Mar 12, 2017, 9:02 PM UTC

hasbot wrote: post #54

unclebucknasty wrote: post #31

Part of the problem with OO is the other stuff we heaped on it, while still calling it OO. So, we're not always assessing "pure" OO when we talk about it. For instance, immutability and OO are diametrically opposed concepts. Objects were supposed to encapsulate data (state) and expose operations that would mutate that state in a controlled fashion. But, we then imposed this immutability requirement, whereby we create…

Your comment reminds me of the class responsibility discussions we used to have. Should we have gasStation->fillUp(vehicle) or vehicle->fillUp(gasStation)? There is no right answer and depends on the situation.

What seems most natural to me is that the gas station would have a fillUp(IFillableWithGas) method that takes an object with the IFillableWithGas interface, which has a method that returns the amount it was able to take and a method to put that much in. The gas station is the one "doing" the action "to" things that are able to take gas, and it's the gas station's responsibility to know how to pump up the gas from the tank and calculate the price. gasStation->fillUp could look like (leaving it at a gas station with only one pump for simplicity)

    float price = 0;
    while (!vehicle.gasIsFull()){
        Gas gas = this.undergroundGasTank.getGas();
        vehicle.depositGas(gas);
        price += gas.getAmount() * this.gasPricePerGallon;
        this.display(price);
    }

It would be out of place for a car or gas canister class to know how to use the undergroundGasTank object and to calculate the price themselves.

Re: Was object-oriented programming a failure? (2015)

#100

Post by alkonaut » Sun, Mar 12, 2017, 10:00 PM UTC

jimmaswell wrote: post #97

alkonaut wrote: post #82

Earlier quoted context omitted.

I think it's usually the case that mutability and inheritance is overused leading to deep and/or unnatural abstractions and code that is hard to reason about. Working with a hierarchy many levels deep with overrides on every level means it's very hard to reason about the code as the call stacks ride an elevator up and down the class hierarchy. Don't get me wrong - this is not an inherent drawback with OO, this is bec…

A codebase I work on at the moment has some hierarchies go to at least 6 or 7 levels, and I haven't had a problem with it. The way it's used doesn't hurt the ability to reason about it, it's just a logical progression of categories of objects getting more specific as they branch out. This is at the same time that a lot of composition and components are used. I'd say excessively deep class hierarchy or bad abstraction…

> it's just a logical progression of categories of objects getting more specific as they branch out.

That's the benefit of it. On a type abstraction level it's perfect to write Organism > Animal > Dog. That's the benefit of inheritance. The drawbacks are more subtle though and manifest like mad stacktraces that are very brittle to change (what happens when I change what I return from this method? Who are the downstream and upstream users? What does this stacktrace mean? When it becomes difficult to reason about is when you have all these kinds of abstractions executing at the same time - which easily happens.

at Dog.CreateName at Animal.CreateName at Dog.SetNewName at Animal.ResetName at Animal.Create at Organism.Create...