Hacker News Reader

Comment by alkonaut | Hacker News Reader

OO solves some problems and creates others.

One must remember that the competing paradigm isn't functional programming but imperative procedural programming. Very large code bases in C, Fortran, Cobol aren't all that nice either.

It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix.

Many of OO's flaws are being addressed and are even missing from new languages. Rust "feels" OO but isn't. If you write C#7 or Swift and avoid inheritance and prefer immutable types as long as possible - how OO is your code then?

The problem that OO solved is that it allows mediocre coders to iterate on large scale code bases until a problem is solved. This is no small benefit in industry. The drawback that the code is hard to maintain and prone to bugs is an acceptable one.

Modern multi paradigm languages such as F# or Rust are really the way forward I think. The Java/C++ way of OO was a good but expensive lesson.

View on HN

> Rust "feels" OO but isn't. If you write C#7 or Swift and avoid inheritance and prefer immutable types as long as possible - how OO is your code then?

Both are 100% object-orientated (and in the case of Rust, also 100% FP is reachable I'd say. Not knowledgeable enough in C# to say). Do they have in-memory data structures with attached functions that do useful work with this object's state (not necessarily mutating it) ? Yes. Then OO.

Rust is neither OO nor FP, it's procedural (like C and Fortran) but borrows concepts from OO and FP. OO requires data structures to support dynamic dispatch, and although you can have dynamic dispatch in Rust via trait objects your code is heavily gimped - no generics, you can only pass by reference, lifetimes have to be explicitly annotated, etc. It feels like OOP-emulating C code from back in the day. Likewise, if you try to do pure functional programming in Rust you're going to have a bad time. Closures don't share types, and doing dynamic dispatch on them creates the same problems as trying to emulate OOP. In reality it's its own beast, much closer to C with templates than a crossbreed of C++ and Haskell.

Contrary to mainstream knowledge there isn't one single truth of what OOP or FP actually are, rather multiple approaches of applying a set of abstract concepts.

This, a million times. Any (meta) discussion on OOP without giving a precise definition of it is futile, for the devil lies precisely in those details that are omitted from the discussion.

> it's procedural (like C and Fortran)

Wait... do you actually believe that? Tons of C software is OO through and through, has been since C existed.

I'm not sure where this meme on HN that Rust isn't OO comes from but it's based on a definition of OO that is almost never applied by day to day programmers and it's disagreed with by a fair number of language theory people.

Rust has encapsulation, message passing in the smalltalk/OO sense, and polymorphism. It does this through objects with attached methods, and traits. In every way that actually matters to a working programmer Rust is OO.

There's more to the everyday definition object oriented than having functions operating on in-memory data structures. Two other features that are commonly included are subtyping through inheritance and encapsulation.

If we stick to your definition C functions operating on structs qualify as OO, and I don't think many would agree with that.

My first exposure to OOP was in C using structures to hold function pointers as a pattern. You can do OO in C without C being OO. There is a huge semantic difference between doing OO and a language at supports OO, the article is referring to the former rather than the latter.

> Do they have in-memory data structures with attached functions

What do you mean by "attached function"?

I meant that a semantic value in the code (a variable for instance) "carries" functions with it, as methods.

e.g. in a C API:

    struct foo {
      // dispatch
      void (*do_stuff)(int);
      int (*get_stuff)(const char*, void* context);
    };

    // attached functions
    void foo_do_operation1(foo*);
    int foo_do_operation2(foo*, int);

or C++ which allow to conflate both forms but restricts the first with inheritance

    struct foo {
        virtual void do_stuff() = 0;
        virtual int get_stuff(std::string, a_better_type_than_void_ptr&) = 0;
        void do_operation1();
        int do_operation2(int);
    };

or JS where everything can change whether you want it or not

    var v = new Object;
    v.do_stuff = function() { ... }
    v.get_stuff = function(str, something) { ... }
    v.do_operation1 = function() { /* v is available in the closure */ } 
    etc...

or OCaml modules:

    module foo = 
      struct
        let do_operation1 = ...
        let do_operation2 x = ...
    end

in every case, some state is mentioned first, and then some code is bound to this state; then, the language (except in C where it is only a convention... even though some people can get fairly "creative" with macros) provides a way to call the code with a given variable of type `foo`.

The article is about how C & Fortran ("traditional languages" by 1997 standards) compare to C++. This is not about functional- but procedural languages vs. OO. (!)

> It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix.

Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps. Also, the learning curve...

Wait, learning curve? Relative to C++ or Java?

You can write something that passes acceptance tests in C++ without a lot of effort. It's things like removing all the bugs, memory leaks, and undefined behaviors that requires enormous expertise. There is certainly a lot of ground to cover before C++ mastery can be had, but simple OOP and procedural programs aren't that bad.

> You can write something that passes acceptance tests in C++ without a lot of effort.

True for freshman-year

    std::cout << "Hello, world!" << std::endl

programs maybe. People's heads asplode when they get into C++ with any sophistication because they need to grasp several things at once: classes, inheritance and polymorphism, pointers (smart or not), value vs. reference types, etc. Java, JavaScript, and even Lisp go a long way toward hiding those details from the programmer.

Java is perhaps cumbersome to use at times (and especially in older versions), but it's not a complicated language, in fact it is a lot simpler than most.

It's not, however, simpler than ML or Lisp. Just more familiar.

The performance claim doesn't really matter in a world where we use languages like Python, Ruby, PHP and Javascript for major applications. Also, compared to these languages, Common Lisp seems to generally be faster (and, on most implementation/architecture combinations, supports real parallelism).

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

> The performance claim doesn't really matter in a world where we use languages like Python, Ruby, PHP and Javascript for major applications.

Yes, it does. And those languages are all providing negative user/developer experience.

>Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps.

Lisp under SBCL is as fast as Java under the latest Oracle JVM and for numeric computation is sometimes as fast as Fortran.

This means at least 10-20x faster than CPython, Ruby's MRI and others.

I routinely read third-party Lisp libraries and they are very readable, no problems with that.

> Lisp under SBCL is as fast as Java under the latest Oracle JVM and for numeric computation is sometimes as fast as Fortran.

Back it up.

> I routinely read third-party Lisp libraries and they are very readable, no problems with that.

Me too and they're all junk.

Reply on news.ycombinator.com