[Oberon] Introduce myself

[Till Oliver Knoll]

Hello Oberon enthusiasts,

I am Oliver, new to this list and I'd like to give a quick introduction:
I had the honour to attent Professor Wirth's last "Systemprogrammierung"
lectures in the winter semester 98/99.

At the time my student friend Fortunat and I wrote - as an exercise
during the above lectures - the world famous "GigaDraw" for Oberon. Of
course on the proper hardware, a Ceres-3. The draw application was based
on a groundbreaking, object-oriented architecture, with our OliObjects
as basis. The objects - lines! rectangles! a moving Pacman! - were
rendered in crisp black and white in our FortiFrames, which...

Well, moving on :)


I am still in software engineering, currently mostly PL/SQL - which kind
of resembles the Modula / Pascal / Oberon language family. At least the
assignment operator := is the same ;)

When Professor Wirth turned 80 I was at the ETH for his great speech.
And now that he turned 85 I took the occasion and had a look into the
nostalgia bag - and I found "Oberon Core" in the Mac App Store :)

So the first thing that I tried was to compile above "GigaDraw", for
which - yes - I still have the source code. As expected it failed here
and there.

I quickly realised that Professor Wirth was still busy after he
"retired" and simplified the language even more (and while he was at it,
apparently designed a new RISC CPU as a "side quest", or so I understand
- the man is a genius!).

The "Oberon Core" (in the Mac App Store) is apparently based on a RISC
emulator, probably this one: https://github.com/pdewacht/oberon-risc-emu
and so is also close to the Oberon-07 (or Oberon-13). That's my current
understanding, though it seems there are a couple of other Oberon
variants out there, e.g. this one:
https://github.com/andreaspirklbauer/Oberon-experimental

I still have to figure out which one comes closest to the latest
specification (Oberon-13?) of Professor Wirth, but I guess the "Oberon
Core" is pretty close. Even though I am missing the "Browser" module
that we used back in the time to browse the module APIs. Not sure
whether that's just not part of the "core Oberon", or that's because the
above app simply does not ship with it (the company does have a paid
version as well, for "full development of Oberon" - that might be the
reason that the convenient "Browser" module is missing).


As mentioned I quickly stumbled over the differences between Oberon-07
(or Oberon-13 even?) and the Oberon-2 (?) variant that we were using in
our "Systemprogrammierung" lecture.

RETURN statement only at the very end? I LOVE that! I keep preaching
this in my current job, and at best only get puzzled looks (I can kind
of understand the "bail out early" RETURN statement, but I've seen
RETURN statements in the middle of the function, followed by who knows
what kind of statements).

No SHORT and LONG anymore, only INTEGER? Pffft... peanuts.

No ELSE in a CASE statement? Hmmm, okay. I do see the reason to strictly
deal with ALL possible elements (or otherwise use an IF-ELSE IF cascade).

But no WITH anymore? Doh! Bummer. I've read in the archive of this
newsgroups that the intention is not to "water down" the initial
declaration of a variable, and an explicit cast is more obvious. Or so.
However I am not sure if I'd agree, as the given example in that email
conversation was of course a trivial one (with only one cast). But if
(typically) the input message appears N times and you have to cast N
times, too, I am not sure that the code gets more readable, with(type)
all(type) those(type) brackets(type).

Yes, alternatively you define a local variable in the "handler" and cast
only once. But that requires an explicit "copy" operation (and even if
it is just copying a reference to some record, it is still a copy).
Whereas the WITH is merely a *hint* to the compiler, but which does not
require extra operations. So I cannot imagine that this extra assignment
to local variables, just in order to prevent successive casts is in the
spirit of Professor Wirth - or is it? Let alone if you'd have several
WITH statements with different types. Declare a local variable for each
of the former WITH statements? Hmmmm...


But yes, agreed: one can do without a WITH statement. Just like you
could argue that you could do without a FOR loop, because WHILE "for the
win!".

So unless there is a good reason which greatly simplifies the compiler I
cannot really see why WITH is gone - but who am I to tell ;)

Another theory is of course - and I apologise if that theory has been
made up before here - that Professor Wirth was annoyed that people
mis-pronounced his name once more. After all the statement should have
been properly called WIRTH! So he must have simply decided to remove
that misleading WITH-statement, to avoid any further confusion...



Anyway, that's the story so far and I am looking forward to experiment
with Oberon and I do enjoy the simplicity of both the system and of
course the language (and please don't take my rambling about the missing
WITH too serious :)). And I may have an actual question in the future.


Best regards,
  Oliver

P.S: /shameless advertisement of my diploma work: www.pointshop3d.com :)