[KayEss]

Part of the problem here is that OO sits nicely with references, but C++ (like C) is a value based language. This can be seen clearly in most of the design of the standard library -- it's all value semantics, and as such relatively simple and obvious to use (so long as you're not trying to cram OO into it).

A line like

    if ( a == b )

In C++ is pretty obvious what it does. It'll always be a value comparison, and if a and b are pointers to objects you are comparing the object identities and not their values. The meaning is exactly the same in Java of course, but the fact you're dealing with pointers is hidden so you generate a lot of confusion about the correct use of `==` and `.equals`.

The author certainly isn't wrong about a culture of complexity in certain elements, but, to be hones, I see that everywhere else too and it needs to be fought wherever it occurs.

[pjmlp]

Object Pascal, Eiffel, Ada, Mesa/Cedar, Oberon, Modula-2, Modula-3, Oberon, Oberon-2, Oberon07, Active Oberon, Component Pascal, Sather, Swift, D, Go, Rust are OO languages[1] and value based as well.

[1] - As usual, there are many ways of doing OO, not just C++/Java style.

[KayEss]

There are, but they all have at their core an idea of an object which has identity, which values don't have. You can easily model objects in value languages, but sometimes it isn't so easy to do the other way around (like Java's strings -- Smalltalk had similar problems).

[pjmlp]

> There are, but they all have at their core an idea of an object which has identity, which values don't have.

Not at all, objects need to be explicitly allocated on heap, otherwise they are value based.

I took care not to list any language that only allows objects as references.

[KayEss]

Argh, I misread what you wrote. It's very late here now :)

[gpderetta]

Interestingly half of those are Wirth or Wirth derived languages. He seems to like value based programming.

[gpderetta]

I just remembered the quip about "a PASCAL programmer knowing the value of everything and the Wirth of nothing".

[quietbritishjim]

Object Pascal is definitely reference based, not value-based, at least not when I used it back in Delphi 7.

[pjmlp]

You used Delphi, not Object Pascal.

Object Pascal was created by Apple for Lisa and Mac OS, with collaboration from Niklaus Wirth.

Borland then adopted it to Turbo Pascal 5.5 for MS-DOS.

Turbo Pascal 6.0 and 7.0 for MS-DOS, followed by Turbo Pascal 1.0 and 1.5 for Windows 3.x took up ideas from C++.

Borland then rebooted Turbo Pascal with Delphi, but to avoid creating too much confusion among Pascal developers, they kept calling their dialect Object Pascal, even though they completly rebooted the object model.

This is how you declare objects in Object Pascal.

    type
        PTPoint = ^TPoint;
        TPoint = object
           x: Integer;
           y: Integer;
        end;
        
    var
      valuePointOnGlobalMemory: TPoint;
      valuePointOnTheHeap: PTPoint;

    begin
      {Can use it right away}
      valuePointOnGlobalMemory.x := 10;
      valuePointOnGlobalMemory.y := 20;
      
      {Need to heap allocate first}
      New(valuePointOnTheHeap);
      valuePointOnTheHeap^.x := 10;
      valuePointOnTheHeap^.y := 20;
      Dispose(valuePointOnTheHeap);
      
      {....}
    end.

Easy to test with Free Pascal using Turbo Pascal compatibility mode.

[badsectoracula]

Nitpick: Borland didn't reboot the object model, they extended it to add the 'class' types, but the 'object' types remained unchanged. The code you wrote works in both Delphi and Free Pascal :-). Object types are used often when you want to allocate objects on the stack or when you want to "embed" objects in other objects/classes (i don't know about Delphi but Free Pascal also extends object types to support newer stuff like properties).

[pjmlp]

Thanks for the correction, always welcome.

Delphi 1.0 was about the time I started focusing on C++, so I am not that knowledgeable about its features. Just remembered that was one of the key changes.

[IshKebab]

I don't really know about the others but Rust isn't really OO. Neither is Go.

[pjmlp]

Sure they are, just not on the classical C++/Java style hence the footnote, as I was already expecting that kind of comments.

There isn't "The ONE true OOP way", just like there isn't "The ONE true FP way" or "The ONE true LP way".

Each paradigm has a set of concepts of what they might mean, and many languages cherry pick from there.

Rust and Go implement polymorphism via traits and interfaces respectively.

Rust and Go implement encapsulation via struct methods and modules.

Rust and Go implement containment.

Rust and Go allow for delegation.

Rust allows for type extensions via a mix of generics and traits.

Go allows for struct embedding as a kind of type extension.

Class based inheritance is not a requirement for a language to be OO.

CS literature is full of languages that explored other kinds of OO.

[lou1306]

On that topic, Joe Armstrong famously said that Erlang (Erlang!) might be the only "real" OOP language out there: after all, you can have encapsulation, polymorphism, delegation, and so on, by just designing appropriate exchanges of messages between processes.

[KayEss]

I suggested many many years ago that Erlang was an OO language and of course the community ripped me to pieces for it :) I was very pleased to see him eventually come out on my side.

[luk32]

Are you sure? I can make

(a==1 && a==1 && a==3)

Evaluate to true.

It is reasonable to assume what you say, but don't say "always", when it's not.

[pjmlp]

Me too, but not only in C++.

I can start with Python as first one.