[Oberon] Class Methods Vs. Procedure variables in Records

[Srinivas Nayak]

Dear Andreas,


>From your post...

"Look, an entire operating system (the Oberon system) could be
advantageously written in the conventional programming style. So this
fact alone impressively proves that OOP is not all that essential,
even when writing an entire OS. The only exception is the viewer
system - which however is done now."


If I understood correctly,

do you mean,

"Look, an entire operating system (the Oberon system) could be
advantageously written in the conventional programming style *(with
only one extra thing, "type extension"; i.e extending a record)* . So
this fact alone impressively proves that OOP is not all that
essential, even when writing an entire OS. The only exception is the
viewer system - which however is done now. *(which uses "type
extension"; i.e extending a record)* "


And in case of compilers, they said, "type extension" is also not a
need, since one needs bootstrapping anyway... and that is why, Oberon
even doesn't use type extension feature when it is bootstrapped using
a subset of Oberon, i.e. Oberon-0.


Is my understanding correct?



On Wed, Mar 1, 2017 at 12:36 PM, Andreas Pirklbauer <
andreas_pirklbauer at yahoo.com> wrote:

> Richard Hable Tue Feb 28 20:23:00 CET 2017
>
> > > Wirth remains: these languages are still too complex. Why again are
> > > there separate concepts for structs (=records), classes (=pointers to
> > > records), modules, and protocols, and extensions, and and .. in Swift,
> > > when exactly two would do (records for data structuring and modules for
> > > information hiding)?
> >
> > On the other hand, if you use Oberon or Oberon-2, you need at least
> > three definitions in order to define a simple class: the module
> > containing the class, a record type containing its member variables, and
> > a pointer type referring to the record.
> >
> > Richard,
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>
> . . . which this is why I wrote in my original post of January 3rd, 2017:
>
> > Personally, I believe Oberon7 is enough for many purposes, and that
> > certainly includes system design. And that is why I decided to stick
> > to the original Oberon language in Experimental Oberon. But that is
> > entirely my personal bias. From an educational point of view, I would
> > consider using Oberon-2 instead, as it very nicely and cleanly demonstrated
> > the various OOP concepts. But in any case, more important than the choice
> > of the language is, I believe, to teach the debate.
>
> You are right, one does indeed need module, record and pointer declarations to implement the OOP style exemplified in the Draw editor that is part of the Original Oberon distribution.
>
> On the other hand: Apart from the viewer system and a handful of document editors like Draw, one *could* make the argument that there is not much need for using OOP in many other places. One may of course agree or disagree with that statement -personally, I have no predisposition one way or the other. But as I stated in my original note from Jan 3, 2017, this was (more or less) the essence of the main argument brought forward by the "instance-centered" group at ETH around Prof. Wirth (the "Original Oberon” camp so to speak) in the early 1990 - I was just reporting what has been said back then during the debate. They basically argued: "Look, an entire operating system (the Oberon system) could be advantageously written in the conventional programming style. So this fact alone impressively proves that OOP is not all that essential, even when writing an entire OS. The only exception is the viewer system - which however is done now." This argument, when it is thrown at you, is hard to argue agains, given that the authors of the Oberon system have gone to great lengths of actually implementing it :-) So their argument felt a little bit like this: "Guys, we already did it (once) in the Oberon viewer system, so no need to do it again there. Of course, 'you app developers' out there can use OOP it in a things like document editors where you can use Draw as a template. Just copy it and you’ll see, you’ll fine. It’s all you need. But: this is it! Document editors and, perhaps, a few other scenarios. Where else would you 'really' need OOP?". Indeed, there is only a handful of document editors, not thousands, that have been developed over the years.
>
>
> But of course, despite this rather purist few, people at ETH back then have written other software using the OOP style using either Object Oberon or Oberon-2 — after all, one has to master it, right?. I have used both Object Oberon and Oberon-2 extensively. At one point, even the Oberon-2 compiler itself was reexpressed in Oberon-2, using type extensions and type-bound procedures to distinguish between the different kind of entries in the compiler's list of the declared symbols (the so-called symbol table) for example. Of course [..note: when you were at ETH in those days, one develops a kind of Pavlov effect, in the sense that one already knows what the answer is going to be before it is even given..], the "counter argument" against THAT decision was to state the following: (i) look, a compiler is typically bootstrapped, i.e. it *must* first be written in another language that does not support type extension, such as Modula-2. So in any case, you have to start with a compiler that (almost by definition) cannot possibly use type extension (because it's the feature you are actually implementing for the first time), (ii) not using type extensions makes it easier to translate the compiler into *other* languages, a step that may be necessary in yet another bootstrapping exercise on yet another platform where Oberon-2 is not yet available, and (iii) why again would you use type extensions in a program such as a compiler in the first place when *all* extensions are already known at the time the compiler is written, i.e. the compiler will - by definition - not ever be extended in any substantial way in the future (unless the language itself is changed of course in a substantial way, which however has not happened in the last 25+ years last time I checked). In this particular example, my personal view is that using Oberon-2 does indeed increase the readability of the compiler somewhat - mainly because one no longer has to remember what  all those multi-purpose fields for class-specific attributes actually mean. But that is not a particularly strong argument, considering that the entire compiler is now down to only about 2500 lines. You either master THAT or you don't. If you don't, no amount of rewriting it in a a slightly more convenient notation will make you understand it better..
>
>
> But there are other examples of programs that have been built using Oberon-2. But again, that Pavlov reflex..
>
>
> Of course, from an educational point of view, it is perhaps indeed asked too much from eg a 16-year old to reconstruct a Draw-like system from scratch. They just won't. And this is why I added my *personal* remark (re-inserted above) which states that the additional elements (class keyword, type-bound procedures, etc) *may* make some sense from a practical point of view - even though the purist may claim they are not really needed.
>
>
> But we don't live in a purely academic world of course!. Imagine an Android or iOS development environment (IDE) with only Oberon or Oberon-2, but no class concept as provided by Java (on Android) or Objective-C/Swift (on iOS). It would not be as easy for many programmers. Many would be lost indeed. I don't see how the platform providers could have achieved the degree of uniformity that they have without certain "templates" pre-canned (and pre-built into) the IDE. All Android and iOS apps look alike (from a principal point of view only of course). The same can certainly *not* be said of Oberon-(1,2).
>
>
> Andreas
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>


-- 
With thanks and best regards,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170303/26598135/attachment-0001.html>