[Oberon] objects and jewels

[Les May]

On 19/02/2013 13:53, Jörg wrote:
> Frans-Pieter
>
>> I remember reading an argument of Wirth against object orientation.
> However
>> the object way, "myservo.atttach(9)" seems more elegant than the modular
>> way. Did I overlook something?
> You might consider this syntax as more elegant, but basically
> object-oriented programming (OOP) does not add one single new concept to
> traditional procedural programming (PP). Read Wirth's argumentation below.
>
> Whether you write in OOP "myservo.attach(9)" or write in PP
> "SERVO.Attach(myservo, 9)" is the same.
>
> br
> Jörg
>
> Wirth:
>      "Many people tend to look at programming styles and languages like
> religions: if you belong to one, you cannot belong to others. But this
> analogy is another fallacy. It is maintained for commercial reasons only.
> Object-oriented programming (OOP) solidly rests on the principles and
> concepts of traditional procedural programming (PP). OOP has not added a
> single novel concept, but it emphasizes two concepts much more strongly that
> was done with procedural programming. The fist such concept is that of the
> procedure bound to a composite variable called object. (The binding of the
> procedure is the justification for it being called a method). The means for
> this binding is the procedure variable (or record field), available in
> languages since the mid 1970s. The second concept is that of constructing a
> new data type (called subclass) by extending a given type (the superclass).
>
>      It is worthwhile to note that along with the OOP paradigm came an
> entirely new terminology with the purpose of mystifying the roots of OOP.
> Thus, whereas you used to be able to activate a procedure by calling it, one
> now sends a message to the method. A new type is no longer built by
> extending a given type, but by defining a subclass which inherits its
> superclass. An interesting phenomenon is that many people learned for the
> first time about the important notions of data type, of encapsulation, and
> (perhaps) of information hiding when introduced to OOP. This alone would
> have made the introduction to OOP worthwhile, even if one didn't actually
> make use of its essence later on.
>
>      Nevertheless, I consider OOP as an aspect of programming in the large;
> that is, as an aspect that logically follows programming in the small and
> requires sound knowledge of procedural programming. Static modularization is
> the first step towards OOP. It is much easier to understand and master than
> full OOP, it's sufficient in most cases for writing good software, and is
> sadly neglected in most common languages (with the exception of Ada).
>
>      In a way, OOP falls short of its promises. Our ultimate goal is
> extensible programming (EP). By this, we mean the construction of
> hierarchies of modules, each module adding new functionality to the system.
> EP implies that the addition of a module is possible without any change in
> the existing modules. They need not even be recompiled. New modules not only
> add new procedures, but -- more importantly -- also new (extended) data types.
> We have demonstrated the practicality and economy of this approach with the
> design of the Oberon System."
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
I hope everyone reads and takes note of Wirth's first two sentences.

Les May

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20130219/12a76c52/attachment.html