

Why don't I like objects? - throwawayplz

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?
======
reuser
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.

~~~
throwawayplz
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
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.

------
makecheck
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.

------
signal7
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/>

------
nandemo
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.

------
jinfiesto
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.

~~~
throwawayplz
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.

~~~
jinfiesto
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.

~~~
throwawayplz
Thanks for the info - I'll give Smalltalk a look.

------
simon
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.)

------
r3demon
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.

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

~~~
throwawayplz
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.

~~~
devs1010
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

~~~
reuser
If you write some gnarly asynchronous GUI code, it is a lot easier to point to
why it is nice to have objects.

(And MVC, for that matter).

I think this is part of why objects blew up in the 80s

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

