Re: Any research putting c above ada?

[kaz@vision.crest.nt.com (Kaz Kylheku)]

In article <335F9D0E.41C67EA6@cacd.rockwell.com>,
Suzette Norby  <psnorby@cacd.rockwell.com> wrote:

>To get back to the present, there is a comparison (by David A. 
>Wheeler) of today's versions of "Ada, C, C++, and Java vs. The 
>Steelman" requirements at 
>"http://www.adahome.com/History/Steelman/steeltab.htm".  It includes 
>the following table (see article for caveats and link to Steelman):
>
> Language  "No"	"Partial"  "Mostly"  "Yes"  Percentage of 
> 					    Answers with 
> 					    "Mostly" or
>                                            "Yes" 
>                                             			
>   Ada	    3	   5	    11	      94	93%
>    C	   32	  21	     1	      44	53%
>   C++	   19	  17	    23	      54	68%
>   Java	   20	  12	    22	      59	72%
>   
>     
>C now? Still not close.  C++?  68% might pass, but it won't get you 
>on the Dean's List.

A lot of the Steelman requirements are subjective. Some of them are irrelevant
to some tasks. And in others the answer depends on how the language is used.

For example, one requirement is that the user of the language not be able
to modify the syntax or or introduce new predence rules.   First of all, it's
not clear why this would necessarily be a bad thing; it depends on how it's
done. Secondly, changing the syntax is done using preprocessor abuses in C. Not
every program exhibits such preprocessor abuses.

The requirements call for overloadable functions. It's religious issue
whether these are a good thing. IMHO, they are bad. I avoid overloading
function names even in languages that offer the feature. Overloaded function
names are extremely poor programming practice. To figure out which function
is called, you have to look at all the argument types and apply all kinds
of rules. In Ada, the rules are particularly arcane. Not only do the
actual argument types matter, but also the expected type that is inherited down
the expression tree. You have to be a compiler expert just to understand
what's going on. 

It's interesting that one of the requirements is a Nudds: that is, that the
language support comments that are delimited by a special character (or
character pair) and terminated at the end of the line.  This is utterly a
religious issue.

Another example is that the language have fixed point types, bit strings, and
operations on subarrays. Shrug. I could also form my own arbitrary
and religious requirement here:  A decent language should have regular
expression matching and string substitution. Ada: no, C: no, C++: no, Java: no,
Perl: a resounding yes! 

The requirements call for some sort of tasking or threading. In fact at least
*six* separate requirements are related to tasking, and a language that doesn't
have the concept will fail on all three counts.  You can't have scheduling
facilities if you don't have concurrent processes, nor can you have passing of
data between processes, signalling or waiting! By comparison, the lack
of an exception handling facility only sets your language back three
points, if you are going to tally.

By adding up the scores naively, is Wheeler saying that a tasking model is
twice as important as an exception handling facility?  Furthermore, I would
also have to question some of Wheeler's assignment of yes and no answers,
though I agree with many, if not most of them. The individual assesments
are useful, but the numeric totals are misleading.