Live data from Hacker News

Does OO really match the way we think (1997) [pdf]

leshatton.org

21–30 of 253 posts

Re: Does OO really match the way we think (1997) [pdf]

#21

OOP did more to set back program design than anything else I can think of. It was incredibly wrong, has sent so many smart minds down a poor path. If for example functional has taken prominence in the 90s we'd be in a much better place now.

Fad X did more to set back program design than anything else I can think of. It was incredibly wrong, has sent so many smart minds down a poor path. If for example Fad Y has taken prominence in the 90s we'd be in a much better place now.

Re: Does OO really match the way we think (1997) [pdf]

#22
In reaction to some of the comments popping up re. OOP and functional programming: I've come across quite a bit anti-OO sentiment in my career now, and not nearly as much anti-functional sentiment. I suspect that the prevalence of OOP has something to do with it - you're more likely to have been exposed to bad OO code than any other type simply because there's more of it. People often seem to draw an artificial distinction between OO and functional styles - but they're both just techniques that can be applied to solving problems and work well in combination. E.g. purely functional immutable objects seem to yield very readable and maintainable code. You can write bad code in any paradigm; but the more open you are to combining a variety of techniques, the more options you have for creating a good solution to the problem at hand.

Re: Does OO really match the way we think (1997) [pdf]

#23
post #17
post #10

Earlier quoted context omitted.

Agree that Java and C++ are poor examples. However, OOP fundamentally results in a combinatorial explosion of state, which makes programs difficult to reason about. This can be useful in some niche applications but does not make a good general approach. The best part of OOP is arguably its support for first-class modules, but this feature could in theory be added to a functional language. EDIT: the reason why there i…

The combinatorial explosion of state is only problematic if some parts of your program can actually "see" the global state resulting from the combinations, and thus, depend on some specific combinations in an undesirable way. In this case, you might have a design issue. This is exactly one of the problems encapsulation and abstraction aim to solve, and has nothing to do with OO: you could also create a combinatoric e…

Any global state is potentially visible externally in terms of the behaviour of your system. Yes pure functions can be complex, but their behaviour is entirely reproducible and testable. For state not to be visible externally, i.e. true state encapsulation, then you need components that appear stateless externally, which is not how most people do OOP.

Re: Does OO really match the way we think (1997) [pdf]

#24

OOP did more to set back program design than anything else I can think of. It was incredibly wrong, has sent so many smart minds down a poor path. If for example functional has taken prominence in the 90s we'd be in a much better place now.

I have the polar opposite view. I love OOP because it provides a way to elegantly solve so many problems.

To take a concrete example, consider the undo-redo mechanism in a text editor. It seems natural to create a list of objects with each object representing the action that can be undone or redone, and a pointer to the most recent action object. Undoing executes the 'undo' method and moves the pointer to the previous action. Redoing moves the pointer to the next action and calls it's 'redo' method.

You would have a 'delete text' type of action which knows how to remove a particular chunk of text and put it back. You would have a 'change text colour' action which knows how to change text to a particular colour and revert back. You might have an 'insert jpeg' action which knows how to add a picture and remove it from the document.

Crucially, each action object in the list should encapsulate it's data and behaviour. It makes the undo-redo framework so much simpler if the framework knows nothing about each type of action, besides the fact that each action object has some kind of undo and redo behaviour.

I cannot see how you could get a simpler design without OO principles such as coupling the data and methods of each type of action, or without hiding the implementation details of each action from the undo-redo framework.

Re: Does OO really match the way we think (1997) [pdf]

#25
I think this latest resurgence of OOP skepticism could be a good thing, but I can see it easily turn into folks just using OOP as a scapegoat for bad design.

I worry as well about the push for FP to somehow 'replace' OO, when really they address different concerns, and can actually complement eachother.

Re: Does OO really match the way we think (1997) [pdf]

#26
All these guys bashing OO and in the meantime every software stack that ended up in their comment leaving their home connection is object-oriented (even if not necessarily written in an OO-friendly language): web browser, linux, windows or mac kernel, router firmware... Seriously guys, if you think OO has failed you are oblivious to the amount of successful OO software that everyone uses every day.

Re: Does OO really match the way we think (1997) [pdf]

#27

All these guys bashing OO and in the meantime every software stack that ended up in their comment leaving their home connection is object-oriented (even if not necessarily written in an OO-friendly language): web browser, linux, windows or mac kernel, router firmware... Seriously guys, if you think OO has failed you are oblivious to the amount of successful OO software that everyone uses every day.

> Seriously guys, if you think OO has failed you are obnoxious to the amount of successful OO software that everyone uses every day.

Not sure what you mean. Do you mean oblivious?

Re: Does OO really match the way we think (1997) [pdf]

#28
OO solves some problems and creates others.

One must remember that the competing paradigm isn't functional programming but imperative procedural programming. Very large code bases in C, Fortran, Cobol aren't all that nice either.

It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix.

Many of OO's flaws are being addressed and are even missing from new languages. Rust "feels" OO but isn't. If you write C#7 or Swift and avoid inheritance and prefer immutable types as long as possible - how OO is your code then?

The problem that OO solved is that it allows mediocre coders to iterate on large scale code bases until a problem is solved. This is no small benefit in industry. The drawback that the code is hard to maintain and prone to bugs is an acceptable one.

Modern multi paradigm languages such as F# or Rust are really the way forward I think. The Java/C++ way of OO was a good but expensive lesson.

Re: Does OO really match the way we think (1997) [pdf]

#29

All these guys bashing OO and in the meantime every software stack that ended up in their comment leaving their home connection is object-oriented (even if not necessarily written in an OO-friendly language): web browser, linux, windows or mac kernel, router firmware... Seriously guys, if you think OO has failed you are oblivious to the amount of successful OO software that everyone uses every day.

In what way is the Linux kernel or my router firmware object-oriented?

Linus Torvalds has even gone on record to express his distaste for C++ and OOP.

Re: Does OO really match the way we think (1997) [pdf]

#30

All these guys bashing OO and in the meantime every software stack that ended up in their comment leaving their home connection is object-oriented (even if not necessarily written in an OO-friendly language): web browser, linux, windows or mac kernel, router firmware... Seriously guys, if you think OO has failed you are oblivious to the amount of successful OO software that everyone uses every day.

> Seriously guys, if you think OO has failed you are obnoxious to the amount of successful OO software that everyone uses every day. Not sure what you mean. Do you mean oblivious ?

Amphibious pitcher debuts in MLB.
Post reply on HN