On Mon, 25 Aug 2014 16:51:23 +0300
Paulo Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Since when does C++ does support message passing?
since people started to think that "OOP was invented in C++".

On Monday, 25 August 2014 at 14:05:35 UTC, ketmar via Digitalmars-d wrote:
> On Mon, 25 Aug 2014 16:51:23 +0300
> Paulo Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Since when does C++ does support message passing?
> since people started to think that "OOP was invented in C++".

The terminology "message" for "method" comes from Smalltalk. It is used liberally.

C++ is using the OOP model of SIMULA, which did invent OOP! So I'd say the way C++ does OOP is how it was invented.

SIMULA was created by Kristen Nygaard and Ole-Johan Dahl. Nygaard was very much interested in object-oriented modelling and as a mode of thinking about problems. Not only in programming. Dahl went on to work on formal program verification. I had them as lecturers at the university. Very interesting people.

On Mon, 25 Aug 2014 14:15:09 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> C++ is using the OOP model of SIMULA, which did invent OOP! So I'd say the way C++ does OOP is how it was invented.
and Smalltalk does OOP the way it should be done. ;-)

On Monday, 25 August 2014 at 14:27:55 UTC, ketmar via Digitalmars-d wrote:
> On Mon, 25 Aug 2014 14:15:09 +0000
> via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> C++ is using the OOP model of SIMULA, which did invent OOP! So I'd say the way C++ does OOP is how it was invented.
> and Smalltalk does OOP the way it should be done. ;-)

I haven't used Smalltalk, but can't say it looks pretty… But I probably shouldn't judge by looks, it is the personality that counts!

The SIMULA model was later refined in Beta which was minimalistic in the same vein as Self. In Beta everything is an object, even functions and blocks (which could be specialized). And virtual functions are evaluated from superclasses down to subclasses so that the superclass is encapsulating the subclass in a similar way to how the "with" statement works.

Beta had virtual class definitions and type variables so that you could let a subclass specialize the types that was instantiated in the superclass in a subclass.

D does seem to lack type variables? So it is quite static in comparison.

On Mon, 25 Aug 2014 14:41:46 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> D does seem to lack type variables? So it is quite static in comparison.
the problem with "overly dynamic" languages like Smalltalk (and especially Self) is that it's insanely hard to write an efficient compiler which generates fast machine code. JIT compilation, polymorphic inline caching and alot of other techniques allows this languages to work with "acceptable speed", but primitive C compiler with peephole optimizer can beat 'em easily.

D is aimed to generate efficient machine code, so it must be "static". we can emulate dynamic calls with AA and opDispatch, but this will be... not fast. ;-)

On Monday, 25 August 2014 at 14:54:33 UTC, ketmar via Digitalmars-d wrote:
> D is aimed to generate efficient machine code, so it must be "static".
> we can emulate dynamic calls with AA and opDispatch, but this will
> be... not fast. ;-)

Beta was static and compiled directly to asm. That does not preclude dynamism such as type variables, hidden parent pointers (where the object instanced from) and a rich set of virtual bindings and the ability to specialize everwhere.

Examples:

- a type variable is essentially just a pointer to a typeinfo-block with constructors and meta information.

- a virtual type specification is just a type variable that is constrained to a class hierarchy.

- to have specialization everywhere you just add the capability to have unnamed types

Ola

On Mon, 25 Aug 2014 16:08:52 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Beta was static and compiled directly to asm.
it's not hard to compile dynamic language to native code. what is hard is to make this code fast. this requires very sofisticated compiler which can eliminate as much indirect calls as possible. that's why we have the ability to create non-virtual methods in languages like D or C++. "everything is object" is a nice concept, but it has it's price.

On Monday, 25 August 2014 at 16:26:19 UTC, ketmar via Digitalmars-d wrote:
> is to make this code fast. this requires very sofisticated compiler
> which can eliminate as much indirect calls as possible. that's why we
> have the ability to create non-virtual methods in languages like D or
> C++. "everything is object" is a nice concept, but it has it's price.

You need whole program analysis to get the most out of it. Just about everything can be replaced by LUTs or switches.

If you look at real code very little of the kind of dynamic programs you write in languages like Python and Ruby actually are dynamic in nature.

Sure, there are examples of the opposite, but I think that is more in the line of "eclectic programming" than "useful programming".

I think the whole separate compilation idea is going to be old fashioned real soon now. It makes little sense to not have the build system as a service run on a cluster and the program as a database with builtin versioning.

Why recompile the whole file when only a tiny function should be according to the dependencies?

On 8/25/14, 1:26 PM, ketmar via Digitalmars-d wrote:
> On Mon, 25 Aug 2014 16:08:52 +0000
> via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Beta was static and compiled directly to asm.
> it's not hard to compile dynamic language to native code. what is hard
> is to make this code fast. this requires very sofisticated compiler
> which can eliminate as much indirect calls as possible. that's why we
> have the ability to create non-virtual methods in languages like D or
> C++. "everything is object" is a nice concept, but it has it's price.

Not at all. In Crystal everything is an object, it compiles to native code and it's super fast. All methods are virtual (and there's actually no way to make a method non-virtual).

The trick is to not use virtual tables, but do multiple dispatch (or only use virtual tables when needed). If you have:

a = Foo.new
a.some_method

then it's obvious to the compiler that some_method belongs to Foo: no virtual call involved, no virtual table lookup, etc: just a direct call.

If you have:

x = 1.abs

1 is still an object, only it's memory representation is 32 bits, and the method turns out to be just like a function call.

To me, the real problem with OOP is to automatically relate it to virtual tables, interfaces, etc.

On Monday, 25 August 2014 at 14:41:48 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 25 August 2014 at 14:27:55 UTC, ketmar via Digitalmars-d wrote:
>> On Mon, 25 Aug 2014 14:15:09 +0000
>> via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>>> C++ is using the OOP model of SIMULA, which did invent OOP! So I'd say the way C++ does OOP is how it was invented.
>> and Smalltalk does OOP the way it should be done. ;-)
>
> I haven't used Smalltalk, but can't say it looks pretty… But I probably shouldn't judge by looks, it is the personality that counts!
>

Smalltalk is great, specially as operating system.

I used SmalltalkWorks, before Java was concieved.

It was the closest I ever been of the Xerox PARC OS experience.

The UNIX CLI experience is nothing, compared to the possibility to touch the whole system and use any public class/method on your scripts (transcript).

My second experience with such enviroments was with Oberon, Wirth based his work on Mesa/Cedar. Imagine just having dynamic loadable modules as executables. All exported functions could be used in the REPL, applied to OS widgets or user selections, depending on the signature.

--
Paulo