[Oberon] Introduce myself

[Jörg Straube]

CASE does now what WITH used to do...

Jörg

> Am 22.02.2019 um 08:25 schrieb Till Oliver Knoll <till.oliver.knoll at gmail.com>:
> 
> 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 :)
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon