Hacker News Reader

Comment by cousin_it | Hacker News Reader

I think Java-style OO was successful because it made code organization obvious, more so than any other programming language I've seen. The key insight is that source files are the natural unit of writing code. Each source file has an explicit public API and private internal state, and a dedicated namespace that always reflects the file's name and location in the source tree. That makes it easy to see the big picture by just looking at the directory structure and the imports.

View on HN

But what you describe are basically namespaces. All the rest of OO is overkill. Recipe for success: take a simple language with only functions (like Lisp or C) and add namespaces. Result: this language can do 90 % of what OO languages are useful for, with only 10 % of the features.

OO is simply a layer of human-readability on top of functions and data. As far as the CPU is concerned, both object and method arguments are just data to operate on. So `steve.drink(water)` in another context is just `drink(steve, water)`, which is a little more difficult (at least in English) to reason about.

OO principles are for the limitations of people, not computers.

I should hope it'd be obvious to most people that you don't actually need all of OO just to get that little bit of syntactic sugar. I'd also like to point out another obvious fact: this idiom completely breaks down when the subject happens to be more than one person, i.e: steve_and_irene.drink(water) whereas it works fine in the procedural case (thanks to varargs): drink(water,steve,irene,...).

And you don't need syntactic sugar to do OOP, as you have just demonstrated with your examples. And also, multi methods exist, but you probably want one subject/dispatch variation per sentence anyways for complexity reasons.

Only if your model is terrible. It's perfectly possible to have thirsty_people.drink(water).

I think the more realistic code would be.

people.find('thirsty').drink('water')

Not about plain language reading, but instead writing code the way people think about actions and things.

Procedural is just as valid, but you use the right tool for the right job.

This is correct. OO codifies the pattern of having a struct and a set of functions that operate on it. The syntax does help humans reason about that pattern. But my understanding is that the goal is more about the human limitations of managing large code bases than the human limitations of language.

OO is all about encapsulation. We tend to decompose a program into chunks for different teams and individuals to work on. Software development is a distributed task. Encapsulation means when you code against components written by other people, you only have to understand the public API that they provided. You are supposed to be guaranteed that that API will continue to work even as the code behind it is updated. As component users we can focus on our own task and not worry so much about the details of the component. As the author of a component, we can hide state from the users. That can't be done with structs. we can make updates and switch out implementations without (as much) fear of breaking the code that depends on it.

It's really all about being able to modify code more safely on bigger teams.

In my mind the issues that OO introduces are: * Encapsulation results in more verbosity for the same functionality. * Inheritance takes more thought. * OO as a whole is more complicated and has a bigger learning curve. * OO used incorrectly will magnify the first two points greatly. Given the learning curve I imagine a lot of people don't use it fully correctly.

Which is great until you have to OO-ify `playWith(steve, bob, ball)`. OO dictates that one of steve, bob, or the ball, knows how these three interact, and that it not vary with respect to the other two.

Or `steve' is given to you from a 3rd-party library, and you want to imbue him with the ability also to eat. Well, you can't define `steve.eat(salad)', unless you subclass his class and make a proxy of the object from the library.

To properly solve either of these, you are forced to resort to the second-class citizen of a static class, which is exactly just functions in a namespace.

The one actual "benefit" OO gives you is run-time dispatch; the ability for the program to defer until run-time the decision which implementation of `steve' actually handles `.drink()'. Outside of OO's poster child of GUIs, I have rarely seen a need for this capability in 20+ years of programming. (Mere compile-time dispatch, as captured precisely by OCaml's module functors, is much more common.) Centering a paradigm around this rarity is quite bizarre.

Isn't also limiting the potentially boundless array of (mostly irrelevant) functions to relevant data types also relevant? I'd venture to say it is.

Ooooh... that's a Point object - no way the AddAccount function does anything relevant with it! In OO you don't even actually need to think that since Point has a limited set of methods.

I'd be willing to bet that the Point object in any given language is going to have more methods that take it as an argument than methods the class itself has.

True. But I still go looking for the "Point" class first. Then I start looking for things which accept "Point" parameters. Big difference from procedural programming languages.

In C, I look in "point.h" first, then start looking for other things. Not really different.

A natural way to separate those two types of methods is:

  * methods that do something *to* a Point object

  * methods that do something *with* a Point object

The former are better to be declared inside the Point object so that they have access to internal state.

The latter shouldn't typically access internal state of the Point object.

This separation can help immensely while analyzing a code base.

This applies to any language with static types. Or that allows code to be separated in multiple files, for that matter.

In Haskell, I can literally ask the editor to list me all functions that operate on type X. Even in C written with a modicum of coding discipline, 90% of the functions relevant to type X will be defined in X.h, wherein 100% of the functions in X.h are relevant to type X. (And the 10% of functions relevant to type X that aren't in X.h? Well, in Java, they also wouldn't be part of class X anyway.)

IMO apart from namespaces, the other biggest convenience provided by OO is inheritance. In some problem domains, there are naturally emerging inheritance hierarchies. And when you need it, manually coding virtual dispatch in non-OO languages is going to be hairy.

> I think Java-style OO was successful because it made code organization obvious

I can't agree with this opinion. I often find it an annoying restriction that I must put all my functions in a class. Let's look at a trivial example of multiplying a matrix by a vector. You can write

    matrix.multiplyBy(vector);
    // OR
    vector.multiplyBy(matrix);

It is possible to multiply from the left or from the right (as long as the matrix and vector dimensions match). This makes it even more annoying. What I'd really like to do is:

    multiply(matrix, vector); // vector is a column
    // OR
    multiply(vector, matrix); // vector is a row

Perhaps it's the kind of problems I work with (and the non-OO languages I am used to), but I am regularly faced with this problem if I have to use a language like Java where you have to put all your functions inside classes.

To further elaborate why I don't really like OOP (except in a minority of cases where inheritance, etc makes intuitive sense), I think the biggest issue is that classes/objects are the method to do almost everything.

Namespaces, visibility, inheritance, dynamic dispatch, etc are all somewhat orthogonal features. Having a "class" to be the unit that uses all of these features is, in my opinion, a restriction.

Lists (or arrays), tuples (or structs) and Maps (or dicts) are what I want 99% of the time. When programming with Java or similar languages, I feel like the primary means of abstraction and composition in the language is catering to a 1% problem.

I learned programming in the late 90s, early 2000s, during the height of the craziest OOP craze (when "object oriented" was synonymous with "good"), so it took me a while to un-learn all of the OOP methods but I feel like I did turn into a better programmer when I stopped thinking in terms of objects.

OOP is a neat paradigm for some cases, but I find those cases very rare.

Good points, I think it's not really the right tool for what you are doing. It's more for large teams and big code bases.

Honestly, I think something like Ocaml's module system would be better for large teams than objects, and I think it's also just a better way to organize code.

At least in Java, no one's stopping you:

    import static com.whatever.LinearAlgebra.multiply;

    ...

    multiply(matrix, vector);

I think it's a worthwhile tradeoff to make source files serve as the unit of namespacing and encapsulation. You lose some flexibility, but large programs become easier to read, and new programmers have fewer random conventions to learn.

Reply on news.ycombinator.com