Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
From: Gavin.Flower@comp.vuw.ac.nz (Gavin Flower)
Date: Fri, 2 Oct 1992 11:08:50 GMT
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.

In article <1992Oct1.191854.29057@cs.utwente.nl> kortink@cs.utwente.nl (John Kortink) writes:
>Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) writes :
>
>>In article <1992Oct1.103327.26336@cs.utwente.nl> kortink@cs.utwente.nl
>>(John Kortink) writes:
>>[...]
>The new ARMs are backward compatible. There can hardly be any argument
>about how much time it would take to alter existing ARM source code to
>run on a new ARM. Virtually nothing. It might even be a case of search
>and replace, say a day or so. That's, again, because the source speaks
>the same language.

The point I was making, was to use *new* features.  I think your
counter points would be more effective, if you read what people wrote
more stringently, and thought more about what they were trying to say.

Having said that, could you please explain your last sentence, I do
not understand what you mean.


>
>>>For a C source, an entirely new C compiler would have to be written.
>>
>>The compiler would need modification, rather than an entirely new one
>>produced.
>
>What bollocks. What developer can go about making 'modifications' to an
>entire compiler of which he doesn't even have the source ? 

Normally the vendor of the compiler organises the modifications - this
is for John's benefit, I assume everybody else knows this.

>>I thought this would have been obvious!  Do you *really*
>>need a lesson in elementary compiler design?
>
>No, I don't. I guess you are looking at things rather strangely.

From other posts, I see someone else decided that you could do with an
explanation of how compilers work, and the ease of modifying them.

[...]
>
>>>In the meantime, Gavin, Impression and ArtWorks are/will be probably
>>>the best and most widely used applications on the Archimedes.

This is *not* relevant to the discussion, except that they may have
been availble to the market sooner, if they had been written in "C",
also they may get left behind as the ARM improves.  No doubt these
companies have balanced the commercial returns against these factors?


>>
>>It was never stated that "C", should, or would, always be used for
>>major applications!
>
>Yes it was. The original quotes were these. From the mag :
>
>>>"It is generally accepted that C is the language to use if you intend to
>>>write a serious application of any complexity"
>
>And you :

John, read the original quote *carefully*, note the word "generally"!

John, John, why don't you stick to writing quality applications, and
get someone else to handle your PR?

[...]
>Developers just chicken out of ARM code because of the extra time taken and
>end up with bulky and slower code. CC, which must be an intelligent bunch,
>recognized that in the end they will have the last laugh and have a few,
>but massively supreme applications which are much faster and smaller, of
>which we all know the multiple advantages, direct or indirect.

CC is an exceptional company, but it was late in getting to market,
and will be difficult to be kept uptodate with respect to new ARM
chips as they come on stream.  Also, the presence of bugs in
Impression has already been commented on.



>
>I think it's a sad state of affairs that the low quality of a lot software
>is so much the result of short-term economics.

This has little to do with the argument.  Assembler coding is more
expensive in labour costs and generally has more errors, in general.


>
>And still people wonder why CC is so enormously succesful ?

Quality of management and reasonably good quality control, though I
suspect they will, if they havn't already, reviewed there attitude
towards "C".


Gavin


-- 
Tomorrow's Society                              | flower_g@kosmos.wcc.govt.nz
    Depends on                                   ----------------------------
Today's Children  - help us raise them properly! 
*******  These comments have no known correlation with dept. policy!  *******