From: lithgow@usl.com (Malcolm Lithgow)
Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
Date: 2 Oct 92 05:52:44 GMT

The berkeley gateway seems slow, so this may appear out of context a
little.

[In message "Re: Oh no ! More .....", TMOTA writes:]
>Gosh. Another flame war involving JK. Surprise surprise.

So let's jump in!! ;-)

[Talking about re-compilation for a new architecture or implementation
of the same architecture...]
>And the C programmer doesn't have to debug the code he produces- that part
>of the development cycle has been done; while the assembler programmer has
>to test and debug every part of his code again to make sure that all the
>new things added are correct, and that all the old things left in are still
>working properly.

Urk. Well, remind me to avoid any programs of yours on new
architectures!

C is not particularly portable, and writing fully portable C is
bordering on the impossible! Anyone fool enough to neglect testing on a
recompile of a C program when *anything* has changed (program, OS, or
hardware) obviously has no idea of Quality Assurance techniques.

Since I've been here I've fixed numerous bugs due directly to C
programs not being tested after porting. C is not a particularly
portable language, believe me.

When you recompile your C app on new hardware, you *must* re-test *all
of it*. This should not be too bad, though, because you should have a
test suite that you can simply run through. Of course, the same is true
for an assembly language program.

>>These CC apps were part of the original argument. They prove that ARM code
>>reigns supreme over any C code, given the extra development time.
>
>...until they decide to port Impression onto, say, a PC?

Another portability point that people have severely distorted in their
minds! If Impression were written in C, at least 50% of it would have
to rewritten in it's entirety (because it's interface stuff), and the
other 50% would have to be substantially changed, or at least gone over
with a fine tooth comb. The final result would not be that impressive,
either.

It would probably be cheaper, faster, and produce a better result to
rewrite the whole app from scratch.

If you don't believe me, have a read of the case study on Framemaker in
"Tog on Interface". This is a real-world example, from a real company,
using C, and writing for real machines.

Of course, if the app is designed to be as modular as possible, then
perhaps this may not be the best approach. However, it is just as easy
to make assembler modular as it is to make C modular -- most of the
effort is in the design, not the coding. In fact, if I was writing
assembler, I would tend to make it even *more* modular than C, just so
that I could understand and maintain it. ;-)

>The two languages should be used TOGETHER so that they AUGMENT each other.
>Get the best of BOTH worlds, rather than arguing about them!

But we shouldn't limit things to just two languages. BBC BASIC is very
good for certain applications, too. And it's always fun to write your
own language. ;-)

>Well, my only comments here are:
>  * Most people involved in software development in the world today do not
>    use assembler as their main language. They usually use a compiled
>    language. Code size and a few percent more performance are not
>    very big problems with the size of memories and the speed of modern
>    chips.

Most people involved in software development in the world today do not
really know what they are doing! Look at the size of, say Word for
Windows 2.0 (12MB on disk), and what it gives you -- is it really 750
times better than Wordwise+? I think not! And is it cheaper? Nope. Is
it faster? Only if I buy hardware about 4 times the price of that used
by WW+, and then only marginally. Is it easier to use? Nope (not for my
Mum, anyway, who could grasp WW+'s simplicity, but is thrown by the
modern monsters). Are there any advantages? Yes, of course there are!
But not 750 times as many!

Not only that, but I was aware of NO bugs in WW+, yet most modern
applications have hundreds.

I would not use the modern software industry as a good example in any
argument I made. As a bad example, perhaps...

>  * I have never seen a copy of Impression where the redraw hasn't been
>    affected - Something is *always* broken.
>    Now I know that in C I could make a separate redraw module with a
>    defined interface and let the compiler do the work of ensuring that
>    the interface is consistent across my whole (very large) application.
>    I wrote the redraw code in DSEdit about 7 months ago, and it hasn;t
>    been touched since. I *know* that it works. I *know* that if I don't
>    change the "redraw.c" file, my redraw will not break.

This is even easier to do in assembler. Seperate source, seperate
data-spaces, and a defined interface between modules is what makes
modular source code. It's a breeze to do this in assembler, even BASIC
assembler. If I were writing an assembler program I would make an
effort to be strictly modular for maintenance purposes.

>    If this were possible with Assembler, then why has the redraw code in
>    Impression been *broken* in a multitude of different ways since version 1?
>    (I'm up to 2.17, and the old redraw bugs are gone: Now there are new ones)
>    Sure, Impression's redraw is more complex than DSEdit's, but I can't
>    help feeling that the better module-separation provided by C helps
>    to insulate my redraw code from my other code.

Perhaps because the Impression redraw code alone is far more complex
than the entirety of DSEdit? As to your claim that there are new redraw
bugs, could you tell me what they are? I'm not aware of any... (And if
there are, perhaps it is because the redraw module has been updated
quite a bit for the new RISC OS 3 features, causing bugs that could
just as easily come about in C code.)

Module seperation is not an artifact so much of the language used
(except in, say, orginal Pascal which disallows it) than the design
used.

I could quite easily write a monolithic program in Modula-2 (place it
all in one module). I could equally easily write an assembly language
program that was divided into small, carefully defined modules. In
fact, I would think that the very difficulty of coding and maintaining
assembler pushes you towards more exhaustive and careful modular
design.

[John says CC is successful...]
>I don't wonder: They write damn good software. However, I fail to see why
>you hold this up as proof that assembler is better than C: Has it not
>occurred to you that CC's programmers are *good*, and that it's not purely
>the choice of language which has made the products good?

Too true. But the typical argument that you read every second month in
comp.arch is that it is *impossible* to write real applications
software in assembler because assembler is too difficult to code in,
portability is nil, maintenance is next-to-impossible, and the time to
market would kill you for the small benefits it gives. I think John's
reacting to this constant assumption that most people share.

CC demonstrates graphically that (a) assembler is not too difficult to
code in, (b) portability doesn't have to be an issue, (c) maintenance
is quite possible (CC produce more updates than almost any SW house I'm
aware of, and faster too), (d) the benefits, accompanied by some
*design* (something that Microsoft seems never to have heard of), can
yield you a good share of the market.

>Further examples:
>Personally, I think that MacApp on the Macintosh is horrendous: It makes
>applications large and ungainly, and more than a little slow, but I also
>think that programs like Adobe Photoshop which are written using MacApp
>are very very good. MacApp is not responsible for the quality.

Ho, ho. Yes, Photoshop has lots of really nice features. But it's so
slow it's almost unusable! If Adobe hired some decent assembler hackers
they could probably speed up most of those lovely effects by a factor
of ten or more, and then Photoshop might be faster than doing it by
airbrush. ;-)

>DSEdit uses RISC OS Lib, but a lot of effort has been applied to nullify
>all the awful things RISC OS Lib does (or doesn't). It's actually quite
>nice to use (IMHO), despite the fact that it was based on the utterly
>awful RISC OS Library.

I assume DSEdit is nice, I know that early versions of it were quite
nice, and I presume later version are even better. On the other hand,
Translator, Creator, Packdir, etc. were all written in assembler and
are all very nice.

So these two examples cancel each other out. C is no better a language
for writing quality applications than assembler is. The difference for
large apps is: C encourages experimentation, quick time to market,
creeping featurism, porting, and abuse of resources, and discourages
before-hand design, extensive comments, and exploitation of the
platform's features; assembler encourages careful design, exploitation
of the platform's features, careful code documentation, conservation of
resources, and minimal me-too features, and discourages
experimentation, quick time to market, and porting.

Note: I am only saying 'encourages' and 'discourages'. It is up to the
programmer how they write their programs. But, it is interesting to
note that, as applications written in C become the norm, so does poor
design, creeping featurism, a fixation on portability at the price of
platform exploitation, and very poor use of resources.

Anyway, people have already heard my complaints about the current poor
state of the software industry. So I'll stop now.

-Malcolm.  lithgow@usl.com  These are merely my opinions.