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

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

#71

Post by unclebucknasty » Sun, Mar 12, 2017, 4:33 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.

Definitely remember those discussions. Enter the rise of the manager class!

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

#72

Post by fnord123 » Sun, Mar 12, 2017, 4:33 PM UTC

SNBasti wrote: post #45

Adding my two cents : To some point I can follow the argumentation of the author. However, I do not see any superior alternative to the OO paradigm especially combined with Unit testing. Thus, HN, what are the alternatives to OO ?

I think there's a sentiment that OO means deep type hierarchies and using inheritance a lot. Instead of an alternative, per se, people prefer to keep type hierarchies shallow and preferring composition to inheritance to prevent overspecification of types and retain flexibility in the architecture.

In this sense, I think there's a distinction between textbook OO and cultural OO. One is a benign tool in a toolbox that you can reach for and the other is when people reject merge requests because 'it looks like type A 'is-a' type B. So make it inherit '.

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

#73

Post by jimmaswell » Sun, Mar 12, 2017, 4:44 PM UTC

alkonaut wrote: post #65

It's not a failure, and it was an improvement over some paradigms. But it's been oversold and parts of it are terrible. It was sold on the promise of reuse but accomplishes it at the expense of understandability and maintainability. As such it's a huge foot gun: it's very easy to solve complex problems with complex solutions, and that's not a feature it's a bug. The right level of OO is "very little". Some mostly-FP…

>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?

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

#74

Post by zzzzzzzza » Sun, Mar 12, 2017, 4:48 PM UTC

watwut wrote: post #30

_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…

React itself does much less then what component oriented oop frameworks used to do. Achieving same functionality with react is more work. They were not on the Web tho, so the comparison is a bit weird.

"achieving same functionality is more work" this is part of the advantage of react (and fp in general over oo). you don't need to incorporate an entire object to use a single extra function. The increased modularity also allows you to spread the maintenance burden of the project over a much larger community.

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

#75

Post by jghn » Sun, Mar 12, 2017, 4:51 PM UTC

unclebucknasty wrote: post #68

jghn wrote: post #40

Earlier quoted context omitted.

Inheritance is arguably one of those things. It certainly goes against Kay's original scheme, which was more like actors. To me OOP winds up looking a lot better without the inheritance

Yeah, there are probably degrees of purity. With inheritance, I can at least see how it tries to respect the OO paradigm, by giving you ways to extend without breaking some of the core concepts like encapsulation. While, on the other end, immutability fundamentally undermines the very premise of OO, which is to model the domain as state and behavior vs treating objects as data wrappers to be manipulated externally.

Fair point. In a true, classic Kay OO model the object is providing a well known interface to guard the mutation of the state. While I am definitely in the "prefer immutability" camp in the FP sense I'd argue that this push in the OO world is to cover up people's bad habits.

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

#76

Post by zzzzzzzza » Sun, Mar 12, 2017, 4:54 PM UTC

indymike wrote: post #48

Started programming in 1982. Object oriented programming was a huge advance - especially in developer productivity. A side effect was the dramatic improvement in developer tools: gui builders, IDEs, etc all improved dramatically. Probably the watershed moment for OO was this NeXT video that showed the difference: https://www.youtube.com/watch?v=UGhfB-NICzg

going from emacs to eclipse hardly seems like an improvement.

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

#77

Post by Koshkin » Sun, Mar 12, 2017, 4:58 PM UTC

When using any methodology one could either be successful or fail. OOP, in particular, has been very successful as a user interface engineering methodology. Windows API is one example. Even when taken to the extreme (Smalltalk, Ruby), it can be relatively successful. It is just that as everything else it is only an approximation to the sheer complexity of the world we are trying to model, and so one has to be careful enough not to end up following the road to complexity hell - the one that is paved with the good intentions to try and use the OOP as a way of managing complexity in the first place.

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

#78

Post by pdkl95 » Sun, Mar 12, 2017, 4:58 PM UTC

"OOP" means, in practice, two very different concepts.

It was probably C++ (and later Java) that interpreted OOP as a mandate that your types should fit in some sort of hierarchy. Inheritance (usually with polymorphism) was seen as a primary way to reuse common code. Fortunately, more and more people are realizing the problems that arise when the real world doesn't map easily to the overly-simple inheritance hierarchy. This type of OOP failed a long time ago.

On the other hand, OOP in the original Alan Kay sense[1][2] is about message passing. This happily lives as a key part of languages such as Ruby.

[1] "I invented the term Object-Oriented and I can tell you I did not have C++ in mind."

[2] http://wiki.c2.com/?AlanKayOnObjects

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

#79

Post by jpalomaki » Sun, Mar 12, 2017, 4:58 PM UTC

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 reminding how important it is to protect the private members by creating a list of get/set methods that are used to access them.

This leads to objects with interface like this:

  class Person {
    public void setStomachContents(...);
    public void getStomachContents(...);
    public void setThoughts(...);
  }

While I believe a "proper" object would have interface more like this:

  class Person {
    public void eat(...);
    public void listen(...);
    public Event output;
  }

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

#80

Post by unclebucknasty » Sun, Mar 12, 2017, 4:59 PM UTC

geophile wrote: post #70

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…

> immutability and OO are diametrically opposed concepts. Why do you say that? It is completely reasonable to define objects whose state is fixed at creation, hide a representation, and have methods that implement some abstraction. E.g., strings, complex numbers, points in a space, and possibly even more complex things like sets. All the advantages of OO apply, even for objects whose interface does not provide a way…

It may be reasonable, but it's not OO.

There are those who believe that all objects should be immutable, particularly at the domain level. In my view, that defeats the purpose of OO. There really is no state in this case in any meaningful sense because to get a new state, you must create a new object. So, the object is simply a collection of data.

And, even in limited use it's not strictly OO, which is a separate question from whether it can be useful. The entire purpose of OO was to model the real world. In the real world, you have a bus with passengers. When one passenger gets off, you have the same bus with one fewer passengers, not a completely new bus with all but one passenger The turn signal goes on and off vs. having a new bus with a different turn signal state.

So, at the domain level, it completely breaks the OO concept. And, even at the utility level with language constructs like Strings, immutability tends to oppose OO in the strictest sense. In fact, in many languages (like Java) the String is immutable for technical reasons (security, etc.), not because it's particularly good OO design. To wit, you now need a completely parallel "real" class (StringBuilder) to do the real "object work" of the String (append, delete, etc.) without creating object copies everywhere.

Where OO is concerned, immutability is generally an encumberance.