5 ms·

The article is good at pointing the logic faults. As you correctly say, the abstraction is wrong. If you were abstracting classes for a graphics program the ab

by yannis 17y ago

The article is good at pointing the logic faults. As you correctly say, the abstraction is wrong. If you were abstracting classes for a graphics program the abstraction could even go one level higher in abstracting p o l y g o n s, rather than rectangles and squares. You can even have crossed rectangles (http://en.wikipedia.org/wiki/Rectangle http://en.wikipedia.org/wiki/Rectangle). Using such an abstraction IMHO any polygon shape would consist of line objects which would consist of points (x,y and even z)! OOP abstractions can sometimes be masochistic! ;)

deleted 17y ago
[deleted]
toadpipe 17y ago
> OOP abstractions can sometimes be masochistic! You think? The article is a train wreck of analysis piled on the train wreck of "OO Design", which is itself a train wreck of an attempt to promote reuse by modeling code with data types, which is itself a train wreck of an attempt to imagine what hypothetical programmers in some hypothetical universe might find "useful" as masturbatory aids, hypothetically speaking. (This is not actually true - OO[D] is really an attempt to commoditize programming.) Most of the comments here are just dumping more trains on the pile. The abstraction shitheap is so high at this point that we can barely even remember that we are supposed to be solving some kind of actual problem. The best part of the article is when the author acknowledges that the code might not actually need to be thread safe and so avoids wasting his time with that particular assumption. There is nothing else to be salvaged. A square is not a rectangle? Goodbye mathematics - what is the point of a type system again? More to the point: what planet are the users of this API from? Obviously not this one, and just as obviously no one knows or cares. Not ONCE does the author stop to wonder what services the actual users actually need; it's only about what this guy thinks MIGHT comply with some random "design" rules. One wonders if the users even exist as anything other than just another abstraction, and wondering about what problems those users might actually be trying to solve is right out. Object Oriented Design can be seen as a case of reusing a cliche and butchering it at the same time, with the cliche being the shooting of ones self in the foot, and the butchery being the placement of said foot squarely upon the face of beauty immediately before pulling the trigger.
- barrkel 17y ago
  I think you're going way overboard with your cynicism and criticism of OOP - cynicism bordering on paranoia. I've read your other comment, alleging that OOP "was pushed by manager types who just wanted as many reports as possible". The dominant paradigm before OOP was procedural programming, and it had (and has) real problems: tendency towards storing data in globals, lack of a machine-checked mechanisms for subtyping, less discoverable APIs (often a namespacing issue), and difficulty in sharing code when representing abstractions where many kinds of values need to be treated very similarly but with little differences, GUI widgets in particular. OOP is unmistakably a better approach for a large class of problems, primarily because it encodes good procedural practice into well-defined concepts that are checked by the machine, either at compile time, run time, or both. Functional programming has a different kind of benefit: whereas OOP helped modelling values, FP helps modelling algorithms. Because strict FP demands pure functions and immutable data, you can reason about complex functions and expressions knowing that there are no side-effects that can bite you. The benefits of FP over OOP aren't as clear as OOP over procedural programming, as taking the strict approach makes state management problematic and limits freedom in data structure design and ultimately algorithmic complexity, but the benefits are very clear in certain areas.
  - toadpipe 17y ago
    I note that every advantage of OOP you cite is a modularization feature (even subtyping, since OOP basically conflates modules with types). Clearly you are not entertained by rants based on my experiences, so maybe I should just cut 'n paste pg: "Object-oriented programming is exciting if you have a statically-typed language without lexical closures or macros. To some degree, it offers a way around these limitations. (See Greenspun's Tenth Rule.) Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway. Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work." http://www.paulgraham.com/noop.html http://www.paulgraham.com/noop.html

by yannis 17y ago

deleted 17y ago

[deleted]

toadpipe 17y ago

> OOP abstractions can sometimes be masochistic! You think? The article is a train wreck of analysis piled on the train wreck of "OO Design", which is itself a train wreck of an attempt to promote reuse by modeling code with data types, which is itself a train wreck of an attempt to imagine what hypothetical programmers in some hypothetical universe might find "useful" as masturbatory aids, hypothetically speaking. (This is not actually true - OO[D] is really an attempt to commoditize programming.) Most of the comments here are just dumping more trains on the pile. The abstraction shitheap is so high at this point that we can barely even remember that we are supposed to be solving some kind of actual problem. The best part of the article is when the author acknowledges that the code might not actually need to be thread safe and so avoids wasting his time with that particular assumption. There is nothing else to be salvaged. A square is not a rectangle? Goodbye mathematics - what is the point of a type system again? More to the point: what planet are the users of this API from? Obviously not this one, and just as obviously no one knows or cares. Not ONCE does the author stop to wonder what services the actual users actually need; it's only about what this guy thinks MIGHT comply with some random "design" rules. One wonders if the users even exist as anything other than just another abstraction, and wondering about what problems those users might actually be trying to solve is right out. Object Oriented Design can be seen as a case of reusing a cliche and butchering it at the same time, with the cliche being the shooting of ones self in the foot, and the butchery being the placement of said foot squarely upon the face of beauty immediately before pulling the trigger.

barrkel 17y ago
I think you're going way overboard with your cynicism and criticism of OOP - cynicism bordering on paranoia. I've read your other comment, alleging that OOP "was pushed by manager types who just wanted as many reports as possible". The dominant paradigm before OOP was procedural programming, and it had (and has) real problems: tendency towards storing data in globals, lack of a machine-checked mechanisms for subtyping, less discoverable APIs (often a namespacing issue), and difficulty in sharing code when representing abstractions where many kinds of values need to be treated very similarly but with little differences, GUI widgets in particular. OOP is unmistakably a better approach for a large class of problems, primarily because it encodes good procedural practice into well-defined concepts that are checked by the machine, either at compile time, run time, or both. Functional programming has a different kind of benefit: whereas OOP helped modelling values, FP helps modelling algorithms. Because strict FP demands pure functions and immutable data, you can reason about complex functions and expressions knowing that there are no side-effects that can bite you. The benefits of FP over OOP aren't as clear as OOP over procedural programming, as taking the strict approach makes state management problematic and limits freedom in data structure design and ultimately algorithmic complexity, but the benefits are very clear in certain areas.
- toadpipe 17y ago
  I note that every advantage of OOP you cite is a modularization feature (even subtyping, since OOP basically conflates modules with types). Clearly you are not entertained by rants based on my experiences, so maybe I should just cut 'n paste pg: "Object-oriented programming is exciting if you have a statically-typed language without lexical closures or macros. To some degree, it offers a way around these limitations. (See Greenspun's Tenth Rule.) Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway. Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work." http://www.paulgraham.com/noop.html http://www.paulgraham.com/noop.html