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

[Alan Brain <aebrain@dynamite.com.au>]

kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) wrote:

>I started working with computers 38 years ago.  The first ones were analog,
>then mechanical-digital, and finally electronic-digital.  Not counting what
>you do to the first two of those as programming languages, I have been
>proficient in over 50 assemblers and 30 high-level languages.  My horizons are
>sufficiently wide to evaluate other languages. 

Excellent! Just the type of bloke that my argument will appeal to. I might add I 
wrote my first Fortran II in 1968... so am a relative newbie. (My Dad taught me - 
he'd been working using the Ferranti Pegasus, Ace and Deuce, while my Uncle was in 
the game since COLOSSUS.. but I digress...)

>> Once you start thinking in Ada terms, 
>
>You shouldn't have to think in terms of the language.  If you do, it's getting
>in your way and you should dump it.

Remember when you had to think in 11010001 and 11110011 ? Then came along such 
snappy things as ADD A1,A2? Later on, JMP 07715226 could be replaced by JMP IOHANDLE 
? Later still, you could use loops, then case statements, and so on.

You can still do everything you want by flipping the switches on the front panel. 
But a high-order-language that encourages reliability and maintainability will have 
features so you can get the compiler to check you haven't stuffed up in one of a 
million ways. It should also allow the run-time executive to easily check your code 
during execution, to make sure you haven't screwed up in a million others.

IMHO the language DOES affect your thinking, so you're not troubled by wondering 
exactly what bytes contain a particular variable; you should only be concerned with 
what things you really have to know about it. And if some idjit down the corridor 
changes the representation of the data-type from taking 11 bits instead of 13, so 
what's it to you? But what you do spend your time thinking about is exception 
handling, error-correction, designing so as to minimise impact on other development 
teams, designing so other teams can change internal structures without you having to 
change anything you've written, etc.

Forex, a project I was on switched from having 5 intercommunicating processes 
running in sequence to running them in parallel a week before first delivery. I'd 
designed them so either way would work.
 
>I don't need Ada to find things I don't like about C; I can guarantee you I
>know more of its problems than you do.  What I found from looking at Ada is
>that it has more and bigger problems, and is generally a less convenient tool.
>That's what I mean by getting in my way.

Question: How many kLOCs have you written in Ada? How many in C?

Until you've written at least 2K in Ada, 2K in C, on a real live project, IMHO any 
comparison is iffy. The learning curve for Ada IF SELF TAUGHT can be very rocky. 
With a good teacher - eg the on-line Lovelace Tutorial - heaps easier. I encourage 
you to have a look at it.

My own total is about 17 KLOCs in C (K&R mostly), 50+ in Ada-83, but none in C++ or 
Ada-95, so I don't comment on them. Yes, a few K in each on my PC, but none on a 
genuine project.