From: Gavin.Flower@comp.vuw.ac.nz (Gavin Flower)
Subject: Re: Oh no ! More .....
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
Date: Fri, 2 Oct 1992 20:59:16 GMT

In article <1992Oct2.125127.17369@cs.utwente.nl> kortink@cs.utwente.nl (John Kortink) writes:
>Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) writes :
>
>>???   I always thought that "generally", meant "most, but not all" -
>>      am I mistaken   ???
>
>It was all a big mistake on your side then. So you do agree that it
>doesn't always have to be C ? Finally we all agree on something then.
>Which must be a first on c.s.a.. (Where's the cake ?)

[My initial reaction to this, I've deleted, hopefully the following is
more constructive, and puts things in a better perspective!]


I'm aware of the weaknesses of "C", also of it's strengths.  The
larger the scale of the software project, the more significant the
advantages of "C", and the less relevant the weaknesses.

For small applications BASIC/assembler is fine, often recommended.

For large applications "C" is often better.

For very large applications "C" is best, with bits in ARM code where
appropiate.

For super large projects, consider ADA, but the Archimedes range,
currently isn't bigger enough to get into this territory.  Also there
isn't even a hint of an ADA compiler for the Arc.  Strictly speaking,
the Arc could be involved, but in minor roles - in terms of the
software development effort.


 At the low end of the scale, the languages your existing programmers
are familiar with tends to be more important.  Towards the top end,
the availability of good programmers in the market and management
issues dominate.

Throughout, software quality control is important, but the emphasis
changes markedly, because of the scale.

I get the impression that John is very familiar with the low end, his
reaction seems to bear this out.

CC are very good at the next level up.

A very good and clear post has already demonstrated the practicality
of porting applications between different platforms.  The importance
of portability varies with the product.

I know from my own experience, that there is a world of difference
between developing software by myself, leading a small team of 6
people (at one stage there were over 12, but that included trainees,
and their supervisor), and being part of a project involving hundreds
of people.  A team of 5 people seems to be the optimum upper size for
a software development team, larger projects a best broken down into a
number of small teams, but still suffer from scale issues.

For the very large projects, management issues are so much more
important, its not funny.  Most very large projects fail, and/or cost
too much.

==========

John, at the bottom end of the scale, for Arc specific stuff,
especially the kind of stuff *you* write, ARM code *is* best.

However, as the scale increases, other issues tend to be more
important.  I'd hate to try and find 50 first class ARM programmers
who would be willing, and capable, of working effectively on a large
project, I'd have a much better chance findind that number of "C"
programmers, and training them up on the Arc.  Obviously, a small core
of Arc specialists would be involved, and almost certainly some ARM
programmers.  No, I'm not about to launch such a project, just trying
to point out some of the other issues. 
[I'd love the salary attached to leading such a project!  :-)  :-)]


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!  *******
Newsgroups: comp.sys.acorn