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.
Does OO really match the way we think (1997) [pdf]
21–30 of 253 posts
Re: Does OO really match the way we think (1997) [pdf]
#22Re: Does OO really match the way we think (1997) [pdf]
#23Earlier 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…
Re: Does OO really match the way we think (1997) [pdf]
#24OOP 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.
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]
#25I 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]
#26Re: Does OO really match the way we think (1997) [pdf]
#27All 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.
Not sure what you mean. Do you mean oblivious?
Re: Does OO really match the way we think (1997) [pdf]
#28One 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]
#29All 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.
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]
#30All 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 ?