A question 
Author Message
 A question

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.



Mon, 04 Mar 1996 23:28:22 GMT  
 A question

: 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



Tue, 05 Mar 1996 05:16:26 GMT  
 A question

Quote:

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

Why did we have to wait so long, then ?

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



Tue, 05 Mar 1996 01:42:00 GMT  
 A question

Quote:
>Would you argue the statement: MS-DOS has done more to harm programming,
>...

not that I'm going to defend it (in fact I agree)
but before another flame war starts, I think we
should put in one good word for it:  *WITHOUT*
Intel/IBM/MS/DOS many of us would NOT have a computer
at home - and maybe even "Apples", and others :^))
become affordable soon...
nevertheless
===================================                    \|/
watch out for MouseShit on your PC!                   (o o)
==================================================oOO==(_)==OOo================
Uli (still in the process "movin'to Linux")


Tue, 05 Mar 1996 15:20:30 GMT  
 A question

Quote:

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

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



Wed, 06 Mar 1996 09:52:19 GMT  
 A question
Subject: Re: A question
Newsgroups: comp.lang.oberon



: 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



Thu, 07 Mar 1996 00:08:29 GMT  
 A question

Quote:

> 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.  [...]

I do not agree with that opinion.
Since the IBM-PC has brought computing to the masses it has also brought
programming to the masses. Before the IBM-PC, only very few people were
prgrammers and therefore very highly skilled. Today, there are also many very
siklled programmers, but since everyone who has access to a computer can start
to program there are also a lot of bad programmers.

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



Fri, 08 Mar 1996 18:47:49 GMT  
 A question

Quote:


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

Perhaps I should have hibernated for the last 15 years?
Actually, any non-Oberon system work I have ever done is far easier than
getting Oberon to work on MS-DOS.  Three things to contend with: 1) MS-DOS
limitations to fix (i.e. filename limit, open file limit, 64K segments) 2)
DOS extender, 3) 386/387.  These have all been major {*filter*}es -- fun
{*filter*}es, but nonetheless, I have had my share of World's Hairiest Bugs.

 >

Quote:
>.. I highly recommend Project Oberon by Gutknecht and Wirth.

Me too.  OOPiO2 by Moessenboeck -- THE BEST OOP book I have seen.  No good
OOP textbooks exist yet, and any of the bookshelfware that you can find at
your local bookstore by Sams, Wiley, or McGraw Hill are all crapolla.

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



Fri, 08 Mar 1996 19:42:18 GMT  
 A question

Quote:

>Subject: Re: A question
>Newsgroups: comp.lang.oberon



>: From page 11 (sec 2.1c) of The Annotated C++ Reference Manual by A. Ellis
>: and B Stroustrup:
> (snip snip snip)
>: 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

This should give an overflow condition, as you are adding two SHORTINTs.
The type of this expression will not change during the evaluation.  I
would surmise that if you have an implementation that truncates without
error, then it is broken.

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

- Show quoted text -

Quote:
>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. *
>*********************************************

I like this quote.

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



Fri, 08 Mar 1996 19:52:20 GMT  
 A question


Quote:

>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

Unfortunately the goal of programming is not programming.  If one wants to
produce programs that people will use, the PC ranks as the primary platform
to write for.  It's kludgey technology, but it's on desks everywhere.

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



Fri, 08 Mar 1996 20:56:19 GMT  
 A question

Quote:



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

>This should give an overflow condition, as you are adding two SHORTINTs.
>The type of this expression will not change during the evaluation.  I
>would surmise that if you have an implementation that truncates without
>error, then it is broken.

The Oberon report does not require an implementation to detect such overflows,
and most implementations do not. Checking for integer overflow after each
arithmetic operation would cost a lot more on many modern machines than the
actual operation itself. Also, the original Oberon implementation on the
Ceres-1 did not check for such overflows either. This was only introduced
when the NS32532 CPU used in the Ceres-2 allowed to have each operation
automatically checked.

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



Sat, 09 Mar 1996 23:25:55 GMT  
 A question

Quote:

> 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

You are right. Things changed today. Now we have true 32 Bit
compilers for both M2 and O2 on plain DOS ('386/'486).
Even the stack is adjusted automatically like on the VAX/VMS.
(as I figured out recently with OM2).

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.



Sat, 09 Mar 1996 15:54:55 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Questions-Questions-Questions-Answers-Answers

2. Question(Questions, questions...)

3. Newbie Question: Realbasic Question

4. Questions Questions

5. Questions and more questions...

6. Browse Question / Report question

7. ***Data buffering question. Long post, lots of questions

8. questions, questions!

9. Questions, questions!

10. MicroWorlds Pro "QUESTION Set Size" question

11. OS/2 REXX Question (Object REXX Question Inside)

12. Doc question and Mount question

 

 
Powered by phpBB® Forum Software