Why don't I like objects?

https://news.ycombinator.com/item?id=3246533

by throwawayplz • 15 years ago

10 23 15 years ago

news.ycombinator.com

I have been writing programs for 17 years, a 'professional developer' for 13 years, an academic computer scientist, a hacker, and a systems guy. I have never admitted it, but despite years of professional OO development, I have never really "gotten" the object model, nor do I ever expect to. Am I missing something HN? Is there something wrong with me? Or am I just a wannabe lisper who needs to see the light?

there2• 15 years ago

what don't you "get" about it? or do you get it but not find it beneficial?

throwawayplz6• 15 years ago

Maybe a little hard to describe, but why should everything be an object? Why should everything I want to operate on have to have methods? Etc.

I actually really see the benefit of inheritance in many OO settings, in that it encourages abstraction. But, what's always baffled me is the insistence on the Nouns as a central point of focus in our programs.

To throw more heresy on the fire, I think the MVC paradigm is absolute crap, and don't want to see it ever again if I can avoid it.

there2• 15 years ago

do you have any code online that shows how you prefer to write? i'm curious to see how you organize things without objects (or mvc) and maybe being able to use your code to explain things may make it clearer.

devs1010• 15 years ago

You can just think of objects as containers, if you have a bunch of functions that are related, but don't need to hold a specific "state" around them, then the class is essentially just a grouping (i.e. classes that just hold static methods), if nothing else, having them in a static class makes code more readable and organized, IMO. Its always been my belief that OO makes code easier to understand in a large codebase but I would agree that not everything necessarily fits cleanly into an object, however I can't envision any other way of making a large project work for a higher level business application, I can see why they may not be as needed in lower level programming.

You mention that you're a systems guy, so maybe the type of programming you do isn't necessarily best suited for OO, but for some domains, like business-specific web apps I don't think there would be another logical way of organization, it is a form of fairly "high abstraction" from the 1's and 0's so it only lends itself to certain uses

davidhansen• 15 years ago

But, what's always baffled me is the insistence on the Nouns as a central point of focus in our programs

As opposed to what? LISP has lists, C has structs. These are both nouns, and they are represented as memory-backed data structures in exactly the same manner that objects are. The boxes on a turing machine tape are nouns. What mystical language or platform supports verb-only development? I am completely missing the point of your objection to nouns, here. Please enlighten me.

saiko-chriskun• 15 years ago

not very huge on the OO way of things myself, so you're not alone ;)

makecheck• 15 years ago

Some examples of what you mean would help.

Anything can be overused; I've seen "object models" that almost make me cry from their unnecessary complexity. Maybe you've just seen too many examples that took OO to an extreme, and those soured your taste for the whole style of programming.

Objects can be used judiciously and combined with other programming styles to do very powerful things. Even in 2011 it's not shameful to fall back on a plain C function or data structure in cases where objects don't really add anything of value (not that many programmers seem to, but I digress).

It also depends on the language and what the code does. In C++ for instance, if you happen to be working in code that relies on the C++ exceptions model (ignoring for the moment that some argue quite correctly to avoid C++ exceptions), you must use objects in order for cleanup code to be executed in every possible case. So although object-oriented programming is often just a matter of convenience or clean design or whatever, it can also be a requirement for correct behavior.

nandemo• 15 years ago

One way of seeing is that OO design and programming is an outgrowth of structured design and programming. So if you've never done it, try and design a large system using only structured techniques.

Another way of seeing is that while OO design solves some problems, it introduces a whole bunch of new ones, e.g.:

Subtyping, Subclassing, and Trouble with OOP http://okmij.org/ftp/Computation/Subtyping/

http://harmful.cat-v.org/software/OO_programming/

So yeah, you might turn out to be a Lisper (or an MLer or Haskeller) and you just don't know it yet.

signal7• 15 years ago

Is it objects themselves or their use that you don't like?

90% of objects I come across at work are superfluous cargo-cult bullshit which, in being presented in the name of best practice, pose a very real threat to the space-irony continuum. IMHO, of course.

Oblig: http://xkcd.com/974/

r3demon• 15 years ago

OO is just one of the programming paradigms, somehow it has managed to dominate all others in the mainstream languages. I'm trying to avoid using OO myself, but very often it's just impossible.

jinfiesto3• 15 years ago

While I'm not a big fan of the OO paradigm, I program functionally when I can, I think it makes a lot of sense. In my mind, the difference between OO and regular old imperative programming is where "functions" go. In imperative programs, functions generally operate "on" data, whereas in object oriented programs, functions/methods "are" data.

I think that makes things convenient sometimes, because objects by default tend to know what to do with themselves. I guess OO gives you ad hoc polymorphism for free.

Additionally, making everything an object does have the benefit of giving everything a uniform interface vis a vis message passing.

throwawayplz6• 15 years ago

The consistent interface point is well taken, and I think that's the main reason for OO's commercial success. If you force everyone to be verbose in their interface definitions, code is far less likely to break across distributed teams of devs.

I take issue with your "functions/methods are data." remark. They are not. If they were, they'd be mutable, and I could process them, make copies of them, and change them the way I do other data. This is the wannabe lisper in me getting out, but there's a world of difference between treating your methods as data that you can pass around, and having them be data items that you can actually transform.

In C I can pass function pointers around, and do with some regularity, without making everything in my programs objects.

I realize that some OO languages have this ability, but the mainstream ones (java, C++, python, ruby) generally do not.

jinfiesto3• 15 years ago

I worded that wrong. I'm a lisper as well. I should have said "The interface for functions/data is uniform across both." That's much more verbose. It's why I quoted the "are" I used in my initial post.

My original post was also incomplete. When I said "everything is an object," I meant in a scope larger than the language itself. If you've ever played around in a smalltalk environment, you quickly realize how powerful the OOP idea is, when the programming language becomes a uniform interface for EVERYTHING. You can literally send messages to the objects that make up the environment. I can create and modify a GUI program live simply by sending messages to the Window class. OOP is very powerful when it's turtles all the way down.

To be fair, I didn't "get" OOP until I did Smalltalk. Honestly, everything else SUCKS compared to it. All the same, learning Smalltalk gave me an appreciation for the paradigm and I grokked it in a way I hadn't before.

Also, since you're a Lisper, the third chapter of Structure and Interpretation of Computer Programs is implicitly about Object Oriented Programming. It's surprisingly helpful. It focuses on "message passing" and how it affects program design. It also addresses how OOP creates an informal type system and the problems associated with that. It manages to do all of this without ever talking about OOP by name, or bringing up anything stupid like inheritance.

I can't really comment on your C comment. While I "know" C, I've never done any extensive programming in the language (sadly,) so I'm not really qualified to comment.

simon• 15 years ago

I'm with you. I have twenty one years earning my living as a programmer and I still don't particularly like objects.

There are times where they work really well, especially for representing domain concepts, but procedural code makes more sense to me in many places where the actual computing takes place.

Time for Objects Anonymous perhaps? "Hello, my name is Simon and I don't like objects."

(I suppose I should reassure folks that I understand objects ... I'm addressing whether I like them and see them as the sliced-bread of programming.)

reuser3• 15 years ago

Maybe one part of the reason you hate them is that they have been associated with so much marketing bullshit and pseudo-religion. It helps to realize that actually there is not one unitary concept of what 'OO' means. You can defeat your object allergy if you stop engaging with people's rhetoric and ideology about objects, and just evaluate particular language features individually.

If the same task can be done with a function/sub or with an object, objects typically add two problems:

1. Added boilerplate: before I do work I typically instantiate an object, etc. In many cases it is really obvious that this is just adding pointless lines of code and pointless plumbing. It doesn't help that the big OO languages have accreted so many bad, verbose coders and cargo-cult methodologies, enhancing the extra-boilerplate effect.

2. Unlike locals inside a function, objects' mutable state is accessible in multiple places at multiple times (and merely using getters and setters does not fundamentally change this - and add even more ridiculous boilerplate of the sort which causes people to have gigantic IDEs writing highly repetitive code for them)

Here's what you are missing: objects are just a kind of mini-program, with a more flexible interface and execution model than subprocesses. It's a generalization of the subroutine and largely equivalent to a coroutine.

Even if that doesn't work for you, they are still handy as 'bundles': e.g. a point in 3-space with x, y, z components AND an attached set of methods for doing normal things like dot products, all passed around together. This isn't necessary, but it can make things neater just like bundling certain wires together into a cable.

Evaluate them like 'here is this thing, what can it be used for?' You might decide you like objects, or perhaps just that they have their place.

throwawayplz6• 15 years ago

I suppose my allergy is to the verbosity and code vomit that comes out in most production java/C++ and even OO Python code I've seen.

In C I would use structs and pass around pointers, then have functions that take those as arguments. This obviously sucks in the asynchronous case, but that paradigm has always felt more natural to me.

Put it another way: two examples. A) class Point with locals x,y,z and method 'distance' which takes a parameter that is another point. B) struct Point with components x,y,z. Then we have a function 'distance' which takes pointers to two Points.

Case B's - int d = distance(p1,p2); feels way more natural to me than Case A's - int d = p1.distance(p2);

Totally agree with the toolbox mentality, I've just rarely felt like the object hammer has felt like the right tool.

hardboiled• 15 years ago

There is nothing wrong in not liking OO. But OO is an ambiguously defined paradigm and unlike functional programming doesn't really have a definitive calculus. However, Peter Landin did show that untyped OO could be reduced to lambda calculus.

I think there is a difference between OO as it is practiced and interpreted by mainstream languages such as Java, C++ and how it was originally intended to work (a la Smalltalk, Self). Interestingly as someone who got started with Scheme, I found that Javascript actually helped me understand OO and FP in a more integrated way: Functions/closures as these hybrid Objects or vice versa Objects as Functions/closures. Objects were intended to just abstract away the structure of data and state (but I see lots of OO that treats objects like data structures with lots of mutable state) whereas with functions they are coupled to the representation of the data structure, which is fine if there is either a small set of data structures (lists/trees for Lisp/Scheme) or the domain you're modeling has an optimal stable data representation.

Also after looking at Self, I think class based OO is a more difficult starting point into OO. Inheritance is one modeling method of OO but is way over used. And cause me all sorts of frustration when I started OO.

So if you think you don't like OO, you have to really define for yourself what OO to you means. It means a lot of things to different people. For java programmers it means making everything into classes and interfaces, lots of types and hierarchies, no lambdas(yet?). Some assume the difference between FP and OO is mutable state or first-class-functions. But I don't believe so.

It is really an approach to abstraction: does the structure of the data change more than the operations on that data, then OO is better suited there.

Why don't I like objects?

Related Stories