🚀 go-pugleaf

 > I believe that the "Oberon system" is a gigantic millstone around the
> (admittedly virtual) neck of the Oberon language.  When you tie a
> language closely to an operating system, you require not only that the 
> programmer adopt adopt both simultaneously, but also that the end user
> adopt the operating system to run the applications.  Such things are
> highly unlikely.  When you get a system that is as unpopular as the
> Oberon system, it is even more unlikely that the language will ever go
> anywhere even if it is the world's niftiest language.
 
> Of course, they've come up with a standalone version of Oberon, but when
> you leave the Oberon system, Oberon the language becomes pretty much just
> another Pascal descendant.

I agree that the Oberon system prevents many people from taking a closer
look at the language. But this is really no issue, because this system has
nothing to do with the language. There are abouth 15 standalone compilers
that come to my mind without too much thinking. Among them is Ofront,
an Oberon-2 to C translator.

In my personal oppinion, Oberon is superior to Modula-2 because:

1. GC
2. simplicity & safety (no dangling pointers & variant records, pointers
  initialised to NIL)
3. finer control over export of identifiers (hidden record fields)
4. OOP (extendend types, type bound procedures)
5. type hierarchy of numeric types
   x := 3.4 * FLOAT(LONG(i)) where i is of type INTEGER becomes
   x := 3.4 * i
6. no definition module. ( You may see this as a disadvantage,
  but anyway, you may still create definition modules with the aid of the
  browser and comment them as you like. )
7. simpler to learn than Modula-2

The major weak points are the lack of enumeration types and a too weak
standard for libraries.

Apart from this there are several practical reasons why to favour Oberon:

-The compiler is very simple.

The native Compiler can be ported by one person in less than about a month
( I think the whole Sparc Oberon System 4 was ported by Josef Templ in thwo
months ).

Because it is simple it is also fast eventhough it is written with portability
in mind (the frontend creates a complete syntax tree).

Becuase it is so simple and fast, such interesting things like OMI are possible:

OMI stands for Oberon Module Interchange. It is essentially a module format,
where simply the syntax tree is encoded machine independent in a File.

Code generation is so fast, that it can be done at loading time.

There is an implementation of MacOberon, of wich most of the code is in OMI
format, so that this implementation runs native on a PowerMac and on old
Mac's but requires about a quarter of the size of a corresponding Fat binary.

ETH currently works on ports of OMI to their other Systems, so that modules
will become interchangeable a la Java, but will run native.

Apart from the ETH effort there is a very nice development system for Mac
and Windows called Oberon/F wich fits smothly into OLE and Open Doc.

Unfortunately I don't know really Modula-3, so I can't compare it to Oberon.
But what I know for shure about Modula-3 is, that it is not as simple as Oberon.
To me it seems Modula-3 is for people who like Ada. (In the Modula-3 newsgroup
there are many Ada threads).
I think a complicated language is a shure sign of superfluous concepts, or
of concepts wich fill better into a library than into the language.

Also the Modula-3 compiler is much more complicated, so that it is a pain to
port it. There are not many ports around and there never will be, and a one
manmonth port of the Oberon compiler can beat them in code quality & execution
times. (there was some paper about this, it's dated around 1992, of course this
 may have changed)

Simi