[Oberon] Introduce myself

[Frans-Pieter Vonck]

Hi Till,

just an idea..

Do you consider to make the source code available to the public?
I really would enjoy reading the code of a "real" program in Oberon.
If you put it the public domain possibly programmers pick it up and it 
comes to alive again.
Also discussions about the source code, on github or gitlab repository, 
can be very informative.

Greets,
F.P.


Till Oliver Knoll schreef op 2019-02-22 08:25:
> 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