[Oberon] Message Objects in Oberon

[eas lab]

Despite near zero experience of object/message, I see the big advantage:
it's greater automation. The computer does the work, instead of the programmer
supervising every detail, and still making mistakes.

I believe this is the secret behind Haskell and similar.
You don't tell the computer *what to do*.
You just tell it what *IS*.
"It's a thing; it's got wings; it can fly...."

Haskell et-al claim very strong/strict typing  [but optionally partly
<automatic>
not like Oberon] which ensures minimal errors *IF/when it compiles*.

Also some Prolog like tricks seem to be used.
Unlike Oberon, where we know exactly how it works [if we want to],
the Haskell boys don't seem to know. They just <imply> "it feels good".

messages for OOP are like using a efficient postal-delivery-service,
[with all it's automatic checking (for bombs)] which is much more efficient
than individual/personal delivery.

Being more automated [leaving less to human decision] means less labour
and errors. The Algol/Oberon virtual-machine, with its stack-frames for each
nested block is nice and simple and intuitive, and shows that the correct way
to list files is by recentcy instead of alphabetically. Apparently,
extending it to
handle OOP would completely destroy the simplicity?

== Chris Glur.

BTW the *.pdf book on Oberon for OOP that Chris Burrows cited is
excellent.

-----------
] Is a C language variadic function, where you can send any parameters you
] want into the function, similar to not knowing much about anything? You
] can send any message into the function, of any type, and then it is
] checked later at run time, not at compile time, as to what you are sending
] in to the function or procedure.

Apparently with ML and Haskell the type checking/inference is so strong
that if it checks OK, it inevitably does what the writer wanted.
But yes, it's uncomfortable to not know what's happening inside the box.
Or?  ....We do accept floating-point results without knowing the details...