I've felt that way for years. OO perhaps makes sense for certain things, mainly things that someone else writes and you use as a library. Using OO more widely leads to very inflexible code, and since specs are not inflexible, the result is disaster.
Why OO Sucks by Joe Armstrong (2000)
101–110 of 396 posts
Re: Why OO Sucks by Joe Armstrong (2000)
#102I'm really sick of these 'why blah sucks' posts. Clearly OOP works for a lot of people. If it doesn't work for you, don't use it. My personal feeling is that FP works better when the problem domain is more data oriented, requiring transformation of data streams whereas OOP is good when the problem domain is about simulating or modeling where you want to think about interacting agents of some kind. The whole 'X is one…
> I'm really sick of these 'why blah sucks' posts. Clearly OOP works for a lot of people. If it doesn't work for you, don't use it.
Most of us work in teams. If people I work with believe something that's not true, then it directly effects my work. If the majority of the profession believes something, it significantly effects my entire career. I don't actually hate OOP, although I have criticisms, but the attitude of "if you don't like it go somewhere else" is missing the point. Criticism isn't meant to be mean or nasty, it's meant to point out bad thinking for the benefit of us all. What bothers ME is the positivity police on hacker news that thinks that "if you don't have anything nice to say don't say anything at all" applies to all of life.
Re: Why OO Sucks by Joe Armstrong (2000)
#103Earlier quoted context omitted.
In this context, C and JavaScript would not be considered functional. They have functions, but that's not what most people mean by "functional". While it's possible to restrict yourself to a functional subset in both of them, they would typically fall into the "imperative" category. Imperative programming languages (like C and JavaScript) don't generally impose any discipline on the users.
I think this might be a little unfair to JavaScript. No doubt it's a multi-paradigm language, but there's a huuuge FP community in JS, and loads of code bases (esp. in React) are written in a very functional style. Definitely not comparable to passing function pointers around in C.
If we are talking languages of certain paradigms imposing discipline then JS not being a language conceived or further developed with FP in mind is not one of those, regardless of how folks use it.
Re: Why OO Sucks by Joe Armstrong (2000)
#104OOO sucks too
Re: Why OO Sucks by Joe Armstrong (2000)
#105IF you don't like data and functions bound together, then use a CLOS-like object system with generic functions that don't belong to classes, but have methods whose arguments are merely specialized by class types.
Functions and data are in fact tied together. Almost any thing in mathematics is described in terms of some collection of properties which are elements of sets, and operations. The operations are part of the representation.
A Universal Turing machine is the tape, the symbols, the rules of how the head moves and reads and writes symbols, all together.
Re: Why OO Sucks by Joe Armstrong (2000)
#106Objected oriented programming became popular because a skilled software engineer could create an application outline/spec and then pass that on to lower skilled programmers who would implement the spec without completely fucking it up. It made it easy to separate out work among large teams and write tests (ok we are going to divide up the work between these implementations, each of which gets its own set of unit tests for each function) and standardized some of the high level interactions ahead of time (see: convert spec to code). It was never meant to be a surgical scalpel that a highly skilled developer could use to attain high individual productivity.
Also I highly disagree with the assertion that "Data structure and functions should not be bound together". I would argue that if you are using any sufficiently complex or niche data structure that is not part of some standard library or a primitive, you absolutely do want to bind functions to the datastructure. It is much better to define a data structure with a set of logical human-readable functions for what you want to do with it than to keep it as some collection of primitives or standard lib datastructures you pass around everywhere. Let's say you are writing a spell checker. You really want to abstract away all the ugly details of the trie and any other helper datastructures. You also may want to create an interface for some "word library" that you can extend with different solutions to test e.g. performance (if you are trying to optimize for caching). Object oriented programming really simplifies things in a scenario like this.
Re: Why OO Sucks by Joe Armstrong (2000)
#107The thing is ‘filename’ is a bad example for a an object. Of course, it should be a string. However ‘File’ object is a better example that favors OOP. When you call ‘.read’ on a file object, you expect its content. It doesn’t matter if it’s a windows file, unix file, an IO string, or a web resource. When you call ‘.read’, it just work. Whereas in the functional world, you’ll have to 4 different ‘.read’ function calls…
I'm not sure polymorphism is the best justification for OO. There are plenty of functional paradigms that can abstract over file implementations just as easily as OO. I think the better argument is that a file represents a resource and thus has a more "thingly" character than other "dumb" data.
Re: Why OO Sucks by Joe Armstrong (2000)
#108Earlier quoted context omitted.
The important thing is restricting your public interface, hiding implementation details, and thinking about how easy your code (and code that uses it) will be to change later. It's not an OO vs anything thing. When you want a value from a module/object/function/whatever, whether or not it's fetched from a location in memory is an implementation detail. Java and co provide a short syntax for exposing that implementati…
I don’t think I’ve ever seen a useful “Getter” abstraction...
You're always using a getter. It's just a question of what syntax your language provides for different ways of getting values, and how much they say about your implementation.
Most people don't have a problem with getters and setters, they have a problem with writing pure boilerplate by hand. Languages like Python and Lisp save you from the boilerplate and don't provide a nicer syntax for the implementation-exposing way, so people don't generally complain about getters and setters in those languages, only in Java and C++ and things.
Re: Why OO Sucks by Joe Armstrong (2000)
#109A few notes: Binding data and functions together beats operating on global data visible to everything. One of the big wins of OOP is less exposed global data. A big problem with OOP in C++ was that it wasn't opaque enough. The headers needed to use an object contain info only useful to the object's private functions. This creates recompile hell. Multiple inheritance is seldom worth the headaches. Overriding a member…
> Binding data and functions together beats operating on global data visible to everything. One of the big wins of OOP is less exposed global data.
... These things are unrelated. Just write functions that don't operate on global exposed data? You know, like, function arguments.
Re: Why OO Sucks by Joe Armstrong (2000)
#110Earlier quoted context omitted.
The important thing is restricting your public interface, hiding implementation details, and thinking about how easy your code (and code that uses it) will be to change later. It's not an OO vs anything thing. When you want a value from a module/object/function/whatever, whether or not it's fetched from a location in memory is an implementation detail. Java and co provide a short syntax for exposing that implementati…
I don’t think I’ve ever seen a useful “Getter” abstraction...
getArea() {
return this.width * this.height;
}
getIcon() {
// if icon hasn't been loaded, load it
return this.icon;
}