Love this essay, I still can't (don't want to) find an appropriate way to OO. | Hacker News Reader

Love this essay, I still can't (don't want to) find an appropriate way to OO.

paulgraham.com

18 pointsivan38 comments

Paul's essay sounds like a case against commercial OOP-"languages for the masses" like Java/C# more than it's against OOP. Ruby, JavaScript and Python are perfect examples of powerful languages he seems to have no issues with.

I can't stand Java for the very same reason: it was created with a very specific commercial purpose in mind: to have enterprise software projects done cheaply. This implies that language should be simple enough (inexpensive training, armies of dispensable coders) and restrictive enough (cheap QA) to cheaply build systems that transfer data from one database to another. Sun, do not forget, is a hardware company. And what many hardware companies want, is to turn software into irrelevant commodity.

_to have enterprise software projects done cheaply_

It was created to control embedded processors.

So you hate Java because it is easy to use and stable? I fail to see the negatives in ease of use and cheap QA?

Somebody else here. I do hate Java because it's unnecesarily complex. That is, I hate J2EE and all the f@#$%@#%g stuff I must do to simply pass a variable from one form to another. It's like having chains hanging from my body and trying to run. I hate that language and the stuff Java-only-heads do with it. I do, however, love the JVM.

I don't have Java. I also don't have pliers, hammers and I am totally fine with screwdrivers and nails. :-)

I don't use Java because it is too limiting, resulting in inferior/average performance (R&D team's performance, not code's).

I'd say, the Java language standard is maintained by software bosses for software bosses, not for developers.

Most of the problems I solve don't call for OO, but it's definitely useful. The one bug I can think of that I would have avoided by using OO was the one that I introduced just before asking news.yc to evaluate ourdoings.com last time.

I think pg is right not to rush to implement an object system in arc. There are many opinions about what the right object system looks like. Anybody without an opinion should stay out of the way. Someone else can implement an object system for arc later.

Let's not pretend there's nothing good about OOP. Obviously it doesn't solve any more problems than any other programming model (they're all Turing Complete), so personal preference will have to come into play.

Besides, most of pg's gripes about OO are mostly gripes about bad programming. I've seen some seriously elegant stuff done in even the uncoolest of languages. Google runs entirely on OO languages (C++, Java, Python), and you'd be hard pressed to find someone willing to criticize their codebase for bloat, duplication, or inefficiency.

"Google runs entirely on OO languages (C++, Java, Python)"

There're some interesting questions about what makes a language an 'OO' language. For one, does a language need only to provide facilities for OO, or must it enforce OO approaches? For another, what flavor of OO must it support or enforce?

Most 'modern' languages will provide facilities that can be seen as supporting some form of OO; data structures are mandatory, and methods are an easy extension of them. However, most of these languages don't mandate an OO approach to coding; for instance, C++ (aka C/C++) doesn't and Python doesn't, although Java may be more dogmatic on the question. (A language that mandates OO approaches wouldn't be to my taste, because I don't believe those approaches to be appropriate for all problems.)

So, it's a bit of a non-sequitur to proclaim that the virtues of OO are demonstrated by the use of 'OO languages'; unless those languages mandate OO approaches you'd need to look at how those languages are being used in practice.

OCaml is an object oriented language, yet people who do real work in OCaml (and yes, there are such people, and their work is very real) appear to rarely use the object oriented features at all. The reason seems to be that the combination of a fancy module system with the standard trappings of higher-order, typed functional programming (algebraic data types, pattern matching, and the like) solves most of the same problems as OO in ways that OCaml users find easier to use.

OO is good for you as long as you are not trapped into all-OO thinking.

In bad code you can see, for example, a lot of duplication (literally copy and paste) of some small 3, 4, 5-line pieces only because a coder was too lazy to declare another method in the class. In fact in most of such cases a simple static function was needed, not a method. These coders are usually surprised to hear that static/global functions aren't bad, if not best.

Bu that's, of course, is not the only problem with OO.

C++ has a healthy relationship with OO.

"The aim of the C++ class concept is to provide the programmer with a tool for creating new types that can be used as as conveniently as the built-in types. [...] A type is a concrete representation of a concept. For example, the C++ built-in type float [...]" --Stroustrup

This emphasis on concrete types is how I use and think about objects. If it doesn't cleanly act like a concrete type, I prefer to write a library that provides the data structures and related functions separately to the user. I hate how languages like Java shoehorn EVERYTHING into objects. It's very useful to keep the distinction between what cleanly forms a type and what doesn't.

In my spirit of hiding behind one-off quotes:

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." - Alan Kay

Agreed, and besides, you can think of objects as tiny modules with isolated names spaces and an additional feature: you can have multiple instances of a module in one process, which isn't possible otherwise in C/C++.

I really think OO has been a net loss for the industry and individual programmers. Attaching all functions to data structures, inheritance, hiding fields... these are a net loss. (And about that field hiding aspect of encapsulation - Who are we hiding them from? I ask you.)

It's not a security thing, simply a housekeeping thing. It is more readable and understandable if an object only exposes the methods that it's user needs. It's about reducing complexity.

I think in Java you actually can access the private methods of an object via Reflection, if you absolutely want to.

"It is more readable and understandable if an object only exposes the methods that it's user needs."

This sort of encapsulation is not specific to OO. You can hide data and methods within modules without using classes. In C++ terms you use anonymous namespaces. In C, perl, python(?) and other languages a leading underscore or "static" declaration conveys encapsulation, which is good enough as far as I'm concerned.

It makes sense to "hide" stuff when you're writing a library/framework that you might update in the future. It doesn't when you're just writing for your particular project.

I've never been that enthusiastic about OO but I've recently become a convert to a particular case. Perl's CGI::Application module makes your whole website a single class, and each page in that site is a method in the class. I believe web.py is similar in idea. So rather than a folder full of scripts for each page you just have a single script which contains the code for all the pages of the site.

Having your whole site as a single class is convenient firstly as your constructor can handle the code that's common to each page, though you don't necessarily need OO to do this. Where this OO approach really shines thought is that you can create a more general web site class such as an online shop, and then subclass it for a particular instance of a shop for a client.

This is typical. You, as well as Paul Graham, have gotten stuck in a certain programming model, based on your experience. You have both lost the flexibility of youth.

So, don't try to use pseudo arguments to say that object orientation is bad. It's not bad, it's very good. Defend your style, but don't do it by attacking our style. It's not politics here.

OO programming may be older than you think. I was in my early twenties when I first encountered it. At first (for about a year) I even believed in it. So whether I'm right or wrong to dislike it, it's not simply because I'm old.

Axel Schreiner's book _Object Orientated Programming with ANSI C_ was published in 1994 and OO easily predates that by a good few years in the mainstream.

Schreiner is the German translation of Kernighan's books and this one is a nice example of using a preprocessor for C, written in awk, to gradually add OO to C so you can understand all the nuts and bolts under the hood of a "native" OO language. English translation PDF available for download. http://www.cs.rit.edu/~ats/books/index.html http://www.cs.rit.edu/~ats/books/ooc.pdf

More than a few years. This was the book that got everyone interested in OOP:

http://www.amazon.com/dp/0201113716

As the name suggests, the language it describes was developed in 1980.

I said "in the mainstream", not academia. I'm talking about when personnel departments heard of it and when marketing departments started labelling everything OO.

Symbolics was advertising their FLAVORS object oriented system in the mid-80s. And Symbolics was, literally, the first dot-com.

http://smbx.org/index.php/index.php?option=com_content&task=view&id=18&Itemid=76

You're bringing up a pioneer in the commercial world of OO, I'm talking about suits using the term OO without knowing what the letters stood for.

OO is only an explicit design decision which can also be hidden in an implicit way of separating things which should be kept separated/dependent etc.

If you choose OO, you are automatically bound to the OO limitations (no matter how sophisticated this might be) of the designers of a certain kind of OO.

Already the fact that there exist so many different OO ways, shows clearly that OO is no really uniform, plain and straightforward concept. It is always designed with a certain kind of problems in mind, while in practice every problem has its own needs...

If flexibility is more important to you than some programming paradigm or scheme to follow, you certainly don't choose OO (if possible, depending on the language).

i hate OO programming because of inheritance. It pissed me off to have to look through layers and layers of parents to search for a method. Stick with good ol' functions for easy debugging.

Except you can't have just functions, because then you end up with a semi-object system anyway. For example, you might have a function "dot" which puts a period at the end of a string, and a function "dot" which returns the dot product of two vectors. The first should be a string method, and the second should be a vector method. Without an object system, you'd call it dot-string and dot-vector, which is okay, but semi-object-oriented. Lisp has something that specializes functions based on its first argument.. That might be useful for that.

CL's generic functions are a bit more sophisticated than just specializing based on the first argument. Peter Seibel's book has a good chapter on them: http://gigamonkeys.com/book/object-reorientation-generic-functions.html

I disagree. A language without OO can allow code to be organised in an intelligent way by providing a module system. See Standard ML as (what I consider to be) a good example of this.

i agree. i'm using a module system myself and it's way better than OO

How can it be better, it seems to me that a module system would be a subset of an OO system? So logically it can't be better, if you are not forced to use all features of the system.

Inheritance is helpful in some instances. I can't imagine JUint with inheritance. But it can definitely be misused.

Sounds like you need a better IDE. Or grep...

So don't use inheritance. Seriously. Inheritance is annoying, but unnecessary. I generally avoid it. You can still use other parts of OO.

Good advice, but it doesn't help when one's coding in a larger system not just written by oneself. Then there's operator overloading; you can't trust anything to be doing what it suggests in an unknown, or large, codebase. Code readability goes down the pan if too much is hidden by mis-used OO techniques.

Not all OO languages allow operator overloading.

Reply on news.ycombinator.com