Here is a question that is somewhat off-topic, and not totally relevant to
Oberon, but I think it is worth pondering.

Would you argue the statement: MS-DOS has done more to harm programming,
in general, than help it.  For nearly a decade, programmers have become
accustomed to using pointers, regardless if they are NIL, because no
hardware protection prevented them from this.  The Mandate Of Microsoft
has doomed many programmers to blindly following what has been put forth
as the doctrine, without examining the alternatives.  Programming in the
large is a concept that has not yet dawned on many people, as they blindly
struggle to write applications in C and C++ (with no dawning in sight).
The 640K limitation has introduced some clever hacks, but has in no way
rendered programmers into thoughtful algorithm designers; instead they
patch together a hodge-podge of 3rd party libraries without thinking of
the overall product.

If you disagree, why?  Feel free to cross post.

Taylor "Humor" Hutt
Nosir Arafat.  Yasir Arafat's unknown brother.

: Here is a question that is somewhat off-topic, and not totally relevant to
: Oberon, but I think it is worth pondering.
[ much rambling on the woes of DOS, 640K and C/C++ deleted ]

After 10 years of programming in MS-DOS, 640K, C/C++ and
third party libraries it must be a cruel realization that it
all could have been done alot more easily and it would have been
alot more useful if one had implemented ones own Oberon
compiler and operating system from scratch.

.. I highly recommend Project Oberon by Gutknecht and Wirth.

Whitney

And why is DOS-Oberon implementation inferior to the others ?
Bad fate, or what ?

Wojtek

Wojtek Skulski, Lawrence Berkeley Laboratory, 1 Cyclotron Rd, MS 71-259

"Like C, C++ leaves many details 'implementation-dependent.'  This is done
partly to allow an implementation to take maximum advantage of the hardware
(for example, the sign of the result of a % operation with a negative
argument, para 5.6), and partly to allow the programmer to manipulate the
hardware directly directly rather than an implementation independent
abstract machine.  Thre are about thirty implementation-dependent features
in the C++ language (the exact number depends on exactly what one considers
separate features); they can be found by looking up the 'implementation
dependency' in the index."

I believe this is states clearly the major divider between two groups that
for better or worse one can call the "abstracts" and the "specifics".
I am very powerfully drawn to Oberon since it is specified in the abstract.
There are others who prefer knowing about segments and registers and
interrupt vectors.  In fact, I was recently "taken back" by a coworkers
comment that one is not a "professonal" programmer unless he knows the
idiosyncrasies of the compiler.  I few the situation exactly opposite.

I think INTEL's 64k segments is a combination of the need for backward
compatibility and "specifics".  The NS16000 is sooo... much nicer.

Doug Danforth
--
UMECORP, The creator of UME Voice
73 Digital Drive
Novato, CA 94949
pho (415) 883-1500, fax (415) 883-1711

: From page 11 (sec 2.1c) of The Annotated C++ Reference Manual by A. Ellis
: and B Stroustrup:

: "Like C, C++ leaves many details 'implementation-dependent.'  This is done
: partly to allow an implementation to take maximum advantage of the hardware
[ remainder of quote deleted ] "

: I believe this is states clearly the major divider between two groups that
: for better or worse one can call the "abstracts" and the "specifics".
: I am very powerfully drawn to Oberon since it is specified in the abstract.
: There are others who prefer knowing about segments and registers and
: interrupt vectors.  

I share your enthusiasm for Oberon, but even Oberon has room for
gotcha's on machine specific issues.

VAR
        x,y : SHORTINT;
BEGIN
        x := 120; y := x;
        x := x + y; (* does this produce an overflow condition ?
                        or is the result that was handled in full
                        register truncated when stored in x. *)
END

I have seen C/C++ compilers produce dozens of
instructions for simple low-level statement such as
unsigned int x,n; x << n. This is clearly not getting
the most out of the hardware but rather is erring on the
side of caution. BTW, the problem here is to handle the
condition when n is larger than the number of bits in a register.

It is not surprizing that with these kind of troubles with
"simple integer" stuff that high-level languages such as
C/C++ and Oberon do provide support for interupts and
other similar features in a general way but rather in a machine
and compiler specific way. As an example, the Oberon compiler
for the Ceres compiler has support for interupts but this
is not appear in the general language definition.

: In fact, I was recently "taken back" by a coworkers
: comment that one is not a "professonal" programmer unless he knows the
: idiosyncrasies of the compiler.

If they didn't design the compiler, or are working with
an optimizing compiler then I wonder what they meant.

Here is a comment that might intrest you. It is from a dicussion
on the reliability of  C++ compilers on comp.lang.c++,
where Margret Ellis ( the first author of the C++ ARM ) replied :

----------------------------------------------------

At USL, we watch how well we are doing on quality and care a great
deal about quality and the problems our customers may encounter.
We have an extensive test suite consisting of over 7000 test files,
many of which contain multiple test cases.  Standards suites are
included in our testing as well as many practical C++ programs.

Yes, cfront has bugs (C++ is a difficult language to get right),
but our ongoing QA efforts and recent competitive analysis
show that, far from being the 2nd worst implementation, cfront is
one of the *most reliable* C++ implementations there is.

--------------------------------------------------------
*********************************************
* C++ is a difficult language to get right. *
*********************************************

Whitney

The same argument one could have on the topic skiing. Due to modern machinery
the slopes are created for easy skiing. Thus more people can take up skiing
because they can manage the simple slopes. The percentage of good skiers has
dropped, however due to the popularity of the sport the good skiers (the professionals) are
getting better rewarded for their skiing (higher income).

By making the slopes easy a lot of skies overestimate their skills - and
have severe crashes. This is similar to  programming where Microsoft
tries to make programming easier by  relaxing the  NIL-pointer checking.
Eventually those programs crash (severely) - like the bad skiers.

Christoph Kuhn
IWI 4
University of St. Gallen

 >

Taylor "pulling no punches" Hutt
Championing worldwide usage of Oberon-2!

As for other system dependent features, Oberon clearly marks them by using
SYSTEM.  C++ definitely does not.

Taylor "I have a new sig" Hutt
C++ is a difficult langauge to get right.  -- M. Ellis.

..and it'll stay that way until an alternative such as Oberon appears.
Question:  If ETH isn't going to do a really good implementation of DOS-Oberon,
then who is?

Ian Rae

E.W. Dijkstra once said "the teaching of COBOL should be a criminal
offence."  Prediction: C++ will be seen as the COBOL of the 90's.

--

       "All generalizations are worthless, including this one."

Marc-Michael Brandis
Institute for Computer Systems
ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland

Guenter

OM2 is a trademark of the OM2 International Association, XTech, Ltd.,
Russia.
VAX, VMS are trademarks of DEC. DEC is a trademark of ... you know.