Oberon implementations for production use

[w***@yahoo.com]

Consider a working C/C++ programmer who decides to look into the Wirth languages for something that could provide similar capabilities with a saner design. Looking at the Oberon family, there are several dialects and many implementations, nearly all of which are alpha quality and/or long abandoned. I surveyed all I could find to identify Oberon* implementations that are:

1. production quality
2. compatible with modern operating systems
3. well documented
4. supported by developers and user community

I felt there were only three worth mentioning.

BlackBox Component Pascal
This is by far the most active and has the most resources.
http://www.oberon.ch/blackbox.html
http://blackboxframework.org
http://www.zinnamturm.eu
http://oberoncore.ru
http://www.software-templ.com/shareware/ofronthelp.html

Astrobe
This implementation of Oberon-07 is the only Oberon* that is actively developed as a commercial product. Only for the 32-bit ARM Cortex.
http://www.astrobe.com

Excelsior XDS
This commercial Modula-2/Oberon-2 compiler is no longer developed and is 32-bit only, but it is the most polished implementation of Oberon-2 and popular enough that you have a reasonable chance of getting technical questions answered.
http://www.excelsior-usa.com/xds.html

It may be that I misjudged in some cases. If you are using some other implementation of Oberon* for commercial development, I would really like to hear about your experiences.

As for finding answers to technical questions, comp.lang.oberon and stackoverflow are pretty barren. The most activity is on these lists/forums.
http://www.ocp.inf.ethz.ch/forum
https://lists.inf.ethz.ch/mailman/listinfo/oberon
http://forum.oberoncore.ru

Most users of Oberon* seem to be Russian or German-speaking, so expect to look through discussion in those languages.

If you are looking for a tutorial on Oberon-2, Nikitin's _Into the Realm of Oberon_ is concise and readable. The other texts usually recommended are primarily introductions to programming with Oberon-2 as the language, e.g. Mossenbock & Bach, Muhlbacher & Leich, and Warford.

[c***@gmail.com]

Post by w***@yahoo.com
It may be that I misjudged in some cases. If you are using some other implementation of Oberon* for commercial development, I would really like to hear about your experiences.

We use the Gardens Point Component Pascal compiler for virtually all of our Oberon commercial development (i.e. Astrobe, CPIde and LP Burner):

https://gpcp.codeplex.com/

It is very stable, reliable and robust. It was one of the original seven programming languages selected by Microsoft for implementation on .NET. Consequently it allows access to the extensive library of software modules that make up the .NET framework. It also allows interoperatibility with C# and the other .NET languages that conform to the Common Language Runtime (CLR)

Regards,
Chris Burrows
CFB Software
http://www.cfbsoftware.com

[w***@yahoo.com]

Post by c***@gmail.com
https://gpcp.codeplex.com/
It is very stable, reliable and robust.

Thanks. I found the GPCP Yahoo Group, but lack of activity gave me the impression that GPCP is unused.

https://groups.yahoo.com/neo/groups/GPCP/info

Is there another venue for support?

As I understand the Astrobe project, you have implemented Oberon-07 in Component Pascal. When Wirth designed the Oberon language, one of his stated aims was to get away from "over use" of low-level features in Modula-2. I thought, though, that you would want to keep those features in a language for bare-metal development. Could you say a bit about your decision to use Oberon instead of Modula-2 and also to implement Oberon-07 instead of keeping with Oberon-2/Component Pascal?

[c***@gmail.com]

Post by w***@yahoo.com
As I understand the Astrobe project, you have implemented Oberon-07 in Component Pascal.

Correct.

Post by w***@yahoo.com
When Wirth designed the Oberon language, one of his stated aims was to get away from "over use" of low-level features in Modula-2. I thought, though, that you would want to keep those features in a language for bare-metal development.

Yes indeed. However, low-level features were not eradicated in Oberon, they were neatly isolated. The difference is that they are not part of the language itself, but are contained "in a pseudomodule whose name would appear in the prominently visible import list of every module making use of such low-level facilities." For full details refer to:

"Modula-2 and Oberon"

http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf

e.g. SYSTEM.PUT and SYSTEM.GET can be used to store and retrieve data from absolute memory addresses and device registers, SYSTEM.ADR returns the absolute address of a variable, SYSTEM.VAL performs type transfer operations etc. etc. Most SYSTEM operations result in the direct generation of one or two native instructions rather than procedure calls so they are very efficient.

Post by w***@yahoo.com
Could you say a bit about your decision to use Oberon instead of Modula-2 and also to implement Oberon-07 instead of keeping with Oberon-2/Component Pascal?

1. Personal preference. After about ten years of Modula-2 development I switched my attention to Oberon back in the early 1990's and haven't looked back since. Apart from nostalgia that is - one of my interests is collecting antique Modula-2 compilers, primarily for MC68000 systems (Sage IV, Amiga, Atari and Mac).

2. The aim was to provide an alternative language to C for microcontroller development not an alternative language to C++.

3. Wirth had already developed and documented an Oberon-07 compiler that generated ARM code.

Regards,
Chris Burrows

CFB Software
http://www.astrobe.com

[y***@z505.com]

Post by w***@yahoo.com
Consider a working C/C++ programmer who decides to look into the Wirth
languages

... ... ...

Post by w***@yahoo.com
I felt there were only three worth mentioning.
BlackBox Component Pascal
This is by far the most active and has the most resources.
http://www.oberon.ch/blackbox.html

But component pascal, has been sitting idle for ages now... it's last release was 1.6, but back in 2009, 1.6 was available...

https://web.archive.org/web/20090312024412/http://oberon.ch/blackbox.html

So that's 6 years that 1.6 has been available... and it's still at 1.6

Now this could be considered a good thing: if they designed it right, it shouldn't constantly require patching. Dijkstra claimed that software isn't something you maintain like a car, it's a mathematical construct that is permanent (in the real world though, and I know he hated that term, errors in the program need to be fixed and new features need to be added, and yes he's rolling in his grave when I say this)

I found component pascal very interesting, but I didn't enjoy working with strings with their dollar sign hack/extension (if my memory serves me right). I also didn't like how you had to run the programs in the IDE, like a smalltalk enviornment - whereas in the real world (yes), delphi allows you to just ship an exe easily, and fpc allows you to produce console apps, cgi apps, gui apps, not just smalltalk environment style programs.

Also, Torry.net is full of useful delphi components, but for component pascal you just have a bunch of static html websites with no torry.net style repository. The "email me and we'll put it on our website" component repository systems don't work as well as automated databases like torry where you submit contributions via a computer system (once again, we aren't living in caves... manually emailing people was something people did in 1980's over their modems)

Interestingly enough, Plan 9 and Go Language have taken some ideas from oberon .. I always found it funny how similar pascal and C were, almost like rip offs of each other... even though the debates and flamewars between C and pascal programmers were furious - ironically the languages are very similar, and GO/plan 9 is once again ripping off/plagarizing oberon (and also inferno, sawzall, and other things). Delphi/fpc steal from C too, it's not a one way plagiarizing event - it goes both ways.

It would be interesting if Niklaus Wirth looked into TutorialD (Darwen and Date) and implemented the relational model into oberon somehow. Everyone reinvents the database by storing things in stringlists (delphi), linked lists, INI files, xml files (treed systems are inferior to relational databases), arrays.. yes arrays are just reinventing the database with a roll your own access the array procedures, and of course using text files to store data is again reinventing the database.. Pascal/R tried to be a relational pascal and failed. Was Pascal/R the first version of TutorialD before TutorialD even existed... Finding information about Pascal/R is near impossible, as it faded away into obscurity quickly, and all data about it has evaporated off earth..

Regards,
Z505 Software
Programming Language Skeptic and Critic
p.s. is Wirth listening.. I think I emailed him about TutorialD long ago and got no reply, and also asked him about Pascal/R, but I don't know if I even had the right email address.. Dijkstra had some comments on the relational model, I'll try find the link: he was very in favor of it.

[c***@gmail.com]

Post by y***@z505.com
But component pascal, has been sitting idle for ages now...

Not at all! It just has a new home:

http://blackboxframework.org

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com