Re: C is 'better' than Ada because...

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

Michael Feldman wrote:
> 
> Anything you'll get these days will be at least as reliable as the
> typical C compiler. There is absdolutely no reason why they shouldn;t be.
> Sure, there were pretty rotten Ada compilers 10 years ago, but there
> have been rotten C compilers too.

Some reasons why you might still get a rotten Ada (probably 83) compiler:

1. You're the first user from a particular (and particularly challeging) 
application domain. [Been there.]

2. You are the first user of a compiler that just underwent a major port/
rewrite/etc. [Also there.]

3. You're the only remaining user of a compiler that hasn't been updated in
many years. (vendor's out of business, host is now obsolete, etc.) [There, too.]

4. You forgot (or couldn't afford) to buy maintenance! [Not been there, yet!]

Of course, I suspect these also apply to C compilers, so it's not a 
language-unique issue...

> There's also a vicious-circle effect - if system designers avoid the
> tasking implementation and go down to the OS or the bare iron instead,
> what incentive do compiler builders have to improve the tasking?

Money (e.g. a competitive advantage), I would expect.

I never buy this argument, for two reasons: (1) How do vendors know the
proportion of Ada features used by their customer base? Do they do surveys?
Read user code? Look at problem reports (see below)? (2) Good marketing
_creates_ demand; it doesn't just wait for enough users to ask for something.
(he said, fully realizing that he's in a minority of one when it comes to the 
application of this idea to Ada... :)

> The best way to get well-optimized tasking is to _use it_.

What happens if a user tries tasking, finds that it doesn't meet their
needs with respect to capabilities, performance, etc., and writes the
vendor identifying the deficiencies? Would this qualify as using it?

Many vendors have this interesting categorization scheme that, if a
workaround exists for a problem, it's less important to fix the problem.
Unfortunately, there's always a workaround to the tasking model.

> Compiler (and runtime) builders set their priorities according to
> perceived customer need. Wouldn;t you do the same?

Actually, I think most commercial compiler/runtime builders set their
priorities based on the best likelihood of creating profits. Wouldn't you
do the same? :)

-- 
LMTAS - "Our Brand Means Quality"