🚀 go-pugleaf

Eric W. Nikitin (enikitin@junior.wariat.org) wrote:
>I hope people don't get defensive about this question... but
>I seriously would like an answer to this:

>Why should someone learn Modula-2 rather than one of its 
>'sucessors' Oberon(-2) or Modula-3?

This gets down to a matter of personal preference.  I can
give you my reasons, but you'd get a completely different
answer if you posted to comp.lang.oberon or comp.lang.modula3.

1. Compiler availability: Modula-2 is available for most
   machines, but Oberon and Modula-3 have much more restricted
   support so far.  There's now an ISO standard for Modula-2,
   although admittedly it will be a while before the
   compiler-writers start sticking to the standard.  Modula-3
   has some good ideas but because of the way it was developed
   it's almost a proprietary product which might or might not
   be ported to other platforms.  I believe that the Oberon
   people are looking at developing a standard, but I also
   believe that it's going to take them a long time.

2. Garbage collection.  This is an issue for me, might not be
   an issue for others.  I work in real-time applications where
   it's not all that safe to have garbage collection going on
   behind the scenes.  I know there are ways to turn it off,
   but if you do that then you throw away some of the better
   features of Modula-3 and might as well stick to Modula-2.

3. Oberon was designed in such a way that it's not just a
   language, it's a language plus something like an operating
   system.  There are things in the design that make it
   difficult to separate these two things.  If you don't like
   the interface, then Oberon is a bit of a pain to use.
   In addition, it means that Oberon is firmly committed to
   "workstation" type applications; it's not clear that it
   would be a viable choice for things like embedded systems.

4. Finally, I happen to think that in many of its properties
   Oberon is a step backwards rather than an advance.  The
   extensible records of Oberon are very nice (much better than
   the usual OO approaches), but there are some features of
   Modula-2 which IMO are worth having and which have been
   deleted from Oberon.

One thing that really bugs me about Oberon is the lack of
separate definition modules.  The Oberon people claim this as
an advance, but I'm not convinced.  If you use the Oberon
feature of looking at a module interface (it's a bit like
automatic generation of a definition module) then what you
get is really cryptic: no comments, unclear workarounds to
compensate for the missing enumerated types, etc.  It feels
a bit like using the C/grep approach.  I accept that there are
some genuine important advances in Oberon, but it has a long
way to go before becoming programmer-friendly.  At the
moment it's a bit like the Unix design: nice to use if you
happen to be a guru who understands all the internals, but
too obscure for the average programmer.

Modula-3 is something different.  I could accept Modula-3 as
a genuine upgrade of Modula-2, but it's not going to go
anywhere unless it gets ported to lots of platforms.

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           ftp://ee.newcastle.edu.au/pub/www/Moylan.html

Peter Moylan wrote:
> 
> Eric W. Nikitin (enikitin@junior.wariat.org) wrote:
> >I seriously would like an answer to this:
> 
> >Why should someone learn Modula-2 rather than one of its
> >'sucessors' Oberon(-2) or Modula-3?
> 
> This gets down to a matter of personal preference. 
> 
> Modula-3 is something different.  I could accept Modula-3 as
> a genuine upgrade of Modula-2, but it's not going to go
> anywhere unless it gets ported to lots of platforms.
> 
> --
> Peter Moylan                       peter@ee.newcastle.edu.au
>                            

A look at the Modula-3 FAQ might be in order here --- Modula-3 is
now available for various flavours of Unix, Windows-NT, OS/2, and 
DOS.  Not sure about W95 yet, though I believe its being worked on.
In fact the Mac is about all that is missed out.

-- 
Simon	IP	: simonh@liv.ac.uk
	WWW 	: http://www.liv.ac.uk/~simonh/home.html
	Physical: Oceanography Labs, University of Liverpool, L69 3BX, U.K.

                    \|/
                   (o o)
===============oOO==(_)==OOo================

               WOT NO BEER?!

Just some clarifications on Peter's points...

>    Modula-3 has some good ideas but because of the way it was
>    developed it's almost a proprietary product which might or might
>    not be ported to other platforms.  

Sources for the full SRC Modula-3 compiler have been available since
the begining of Modula-3's life (I think 6 years or so now.) I am not
sure what you mean by "might or might not be ported to other
platforms". Last time I checked Modula-3 ran on 25 or so platforms
including almost every major platform out there.

> 2. Garbage collection.  This is an issue for me, might not be
>    an issue for others.  I work in real-time applications where
>    it's not all that safe to have garbage collection going on
>    behind the scenes.  I know there are ways to turn it off,
>    but if you do that then you throw away some of the better
>    features of Modula-3 and might as well stick to Modula-2.

For most tasks SRC Modula-3's garbage collector does fine. Real-time
is a very fuzzy word. It is easier if you explain what sort of thing
you are trying to do. If you'd like to know about people's experiences
with doing "real-time" tasks like serving video or Columbia
University's Augmented Reality prototype, both written in Modula-3, we
can talk about them. Modula-3 was also good enough to be the basis for
an University of Washington SPIN extensible OS microkernel that
outperforms OSF/1 and Mach.

I think all these tasks are considered "real-time" in some circles.

See the Modula-3 Home Page for more information on the above topics.

> 3. Oberon was designed in such a way that it's not just a
>    language, it's a language plus something like an operating
>    system. 

Modula-3 is designed so that it can be built either as a standalone
compiler or an integrated system. SRC Modula-3 compiler is a "systems"
compiler; you can link in C code, etc. Someone can easily build a
Modula-3 environment like Oberon's, but that's another story. Modula-3
is powerful enough so that you don't have to touch your C compiler
again even for bit-twiddling (unless your boss makes you ;-). Same is
not usually true of most of its competitors.

> Modula-3 is something different.  I could accept Modula-3 as a
> genuine upgrade of Modula-2, but it's not going to go anywhere
> unless it gets ported to lots of platforms.

What platforms are you specifically interested? Most commercial
Unixes, Linux, many BSDs, Win/NT/95, and now OS/2 are covered by
Modula-3.  The sources are there and the door is wide open for others
to port Modula-3 to other platforms. You should have a relatively easy
time porting Modula-3 to any OS that supports gcc and has some notion
of threads or virtual timers.

-- Farshad
-- 
Farshad Nayeri
nayeri@gte.com

In article <31176F2E.7918@liv.ac.uk> "Dr S. Hood" <simonh@liv.ac.uk> writes:
> 
> A look at the Modula-3 FAQ might be in order here --- Modula-3 is
> now available for various flavours of Unix, Windows-NT, OS/2, and
> DOS.  Not sure about W95 yet, though I believe its being worked on.

Yes, I know of people who have successfully built the Win32 port of
Modula-3 running on Win95 machines.

Modula-3 FAQ is in http://www.vlsi.polymtl.ca/m3/faq.html. 

-- Farshad
-- 
Farshad Nayeri
nayeri@gte.com

Farshad Nayeri (nayeri@gte.com) wrote:

: Just some clarifications on Peter's points...

<stuff deleted>

> >    Modula-3 has some good ideas but because of the way it was
> >    developed it's almost a proprietary product which might or might
> >    not be ported to other platforms.  

> Sources for the full SRC Modula-3 compiler have been available since
> the begining of Modula-3's life (I think 6 years or so now.) I am not
> sure what you mean by "might or might not be ported to other
> platforms". Last time I checked Modula-3 ran on 25 or so platforms
> including almost every major platform out there.

Actually, I compare the SRC Modula-3 to AT&T's 'PCC' in the early days
of C.  It's less of a proprietary system than one with a reference
implementation.  When the ISO decides to standardize Modula-3, they will
start with the way that SRC works so most of the post-standardization
code will have a fighting chance at working without modification.  
Contrast this to Modula-2, where there wasn't a "reference implementation"
so the standard doesn't really resemble ANY pre-ISO implementation and
so code that was written for a pre-ISO compiler doesn't have a prayer of
escaping unmodified.

The moral of the story (for language designers) is:  You need a reference
implementation to illustrate the "right way" of building a translator for
the language, and you need a "standard library" so that programs have some
sort of standard way of interacting with the rest of the universe.

<More stuff deleted>

> > 3. Oberon was designed in such a way that it's not just a
> >    language, it's a language plus something like an operating
> >    system. 

> Modula-3 is designed so that it can be built either as a standalone
> compiler or an integrated system. SRC Modula-3 compiler is a "systems"
> compiler; you can link in C code, etc. Someone can easily build a
> Modula-3 environment like Oberon's, but that's another story.

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 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

Simon Egli wrote:
> 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.

Lisp is simpler than oberon then Oberon is a complicated language.  Then, from your
logic, Oberon has superfluous concepts. QED.

> 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)

Surely, you must be a master at creating false information out of thin air.  If you
had actually took a look at SRC M3 instead of talking about things you obviously do
not know, you wouldn't be putting your foot in your own mouth right now.  Here's the
content of m3core/src/unix:

COPYRIGHT            m3makefile           ultrix-3-1.DS3100/
aix-3-2/             osf-1.ALPHA_OSF/     ultrix-3-1.NEXT/
aix-ps2-1-2/         osf-1.DS3100/        ultrix-3-1.SEQUENT/
freebsd-1/           osf-1.generic/       ultrix-3-1.SUN3/
freebsd-2/           solaris-2-x/         ultrix-3-1.SUN386/
hpux-7-0/            sunos-4-x/           ultrix-3-1.UMAX/
ibm-4-3/             sysv-4.0/            ultrix-3-1.VAX/
irix-5.2/            ultrix-3-1.AP3000/   ultrix-3-1.generic/
linux/               ultrix-3-1.ARM/

about 11 OSes, about dozen of machines for a total of 24 platforms (OS + machine).

This is not counting the ports to Win32 (Win95 + WinNT), DOS and OS/2.

Also, the port form one POSIX platform to another can be done in a matter of hours.
A port to more exotic platforms takes longuer but wouldn't require even one
man-month to a talented programmer (even without previous knowledge of the internals
of M3).

	ldd

-- Louis-Dominique Dubeau == Home page: http://step.polymtl.ca/~ldd/ --

Louis-Dominique Dubeau wrote:
> Also, the port form one POSIX platform to another can be done in a matter of hours.
> A port to more exotic platforms takes longuer but wouldn't require even one
> man-month to a talented programmer (even without previous knowledge of the internals
> of M3).

I'd like to second Louis-Dominique's statement.  We've ported the m3 core/lib libraries 
to a more exotic environment: the SPIN kernel.  We started out with very little experience
with Modula-3 and its runtime.  We spent some time getting rid of code in the libraries that
uses floats, as we did not want to use the FPU in the kernel.  Getting M3's runtime working in
the kernel took little time, though we're constantly refining it as our operating system
evolves and we find performance bottlenecks.

Marc E. Fiuczynski
University of Washington
http://www.cs.washington.edu/homes/mef
http://www-spin.cs.washington.edu/  (http server running as SPIN extension - written in M3.)