Re: C/C++ knocks the crap out of Ada

[pitre@n5160d.nrl.navy.mil (Richard Pitre)]

In article <DoDq5n.40@world.std.com> bobduff@world.std.com (Robert A Duff)  
writes:
> In article <4icqe6$9v@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> 
> Your posting completely confuses me.  I'm mystified as to how you can
> conclude some of these things from what I wrote.  Sorry, I'll try once
> more to be clearer.
> 
> >In article <DoBr15.D23@world.std.com> bobduff@world.std.com (Robert A Duff)  
> >writes:
> >> In article <4ic8dk$amh@ra.nrl.navy.mil>,
> >> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >> >Do you have personal experience of this rough equivalence or is this  
> >something  
> >> >whose practical reality should be self evident?
> >> 
> >> Yes, I have practical experience working on large C programs, and
> >> successfully keeping things consistent using an automatic build tool.
> >> (I hope I correctly understood what you're asking.)  I've also written
> >> such a tool for C, Pascal, Modula-2, and Ada.  The Ada support was
> >> harder then the other three put together.
> >
> >What did the tool that you wrote for Ada do, and what did the tool that you  
> >wrote for C do? From the perspective that the standard compilers do  
different  
> >things automatically,  what is it that you wrote?
> 
> I'm not sure what you're getting at, but here goes: It was one tool,
> with support for multiple languages.  It gathered information about
> inter-file dependencies from the source code, and recompiled what needed
> to be recompiled.  For efficiency, information-gathering was
> incremental.  It is true that there were differences between Ada
> compilers that needed to be handled specially -- e.g. different handling
> of pragma Inline and generic instantiations.

What is it that you were trying to do that the Ada compiler did not or does not  
already do?







  
> That problem was worse for
> Pascal, since each Pascal compiler had it's own notion of separate
> compilation -- essentially, each Pascal compiler had to be considered a
> different language, with it's own language-specific module.  For C, this
> wasn't a problem at all, as I recall.  This was 5 or 10 years ago, so
> for Ada, I'm talking about Ada 83.
> 
> >> I admit I have also worked on projects where people weren't so careful
> >> to use the tool, or used a NON-automatic build tool, like Unix 'make'
> >> and hand-written make files.  And that does indeed cause trouble: once
> >> in a while, there's a missing dependency in the make file, and it
> >> causes a run-time bug.  And there are *always* extra dependencies,
> >> which don't cause bugs, but needlessly increase compile time.  (I've
> >> also seen cases where a company ships custom-modified software to a
> >> customer, and fails to remember or save the version that was sent!)
> >> 
> >> Look, I'm not being anti-Ada.  I wouldn't have spent 3.5 years of my
> >> life helping to design Ada 9X, if I thought C was just as good a tool.
> >> I have *not* experienced C programs that effectively used type
> >> checking, or run-time range checking, or information hiding, etc etc,
> >> to prevent bugs -- lint notwithstanding.  ;-) I just think that this
> >> particular advantage of Ada over C that we're arguing about has been
> >> somewhat exaggerated.  (I didn't deny that it's an advantage, either.)
> >
> >So, can I assume that you feel that your level of productivity and
> >confidence in your results was about equal when you using C as it was
> >when you used Ada?
> 
> Umm, no, you should not assume that.  I said ONE PARTICULAR advantage of
> Ada had been exaggerated.  From that, how do you conclude that I think
> *ALL* advantages of Ada have been exaggerated?  On the contrary, I think
> there are MANY advantages of Ada over C, for many types of applications,
> and I think they are important.
> 
> >Regarding exageration of the significance of all the the extra cross  
checking  
> >etc,
> 
> ARGHH.  I did *NOT* say anything about "all the extra cross checking
> etc".  I said something about one *particular* instance of cross
> checking.
> 
> >... I don't think that the simple facts with clear implications needs any  
> >exageration at all. It should be self evident.  So again its not clear to me  
> >what you are saying here.
> 
> The feeling is mutual.  :-)
> 
> >... It sounds to me like you are saying that its no big  
> >deal when you say "somewhat exagerated".
> 
> Yes, but please understand that I was only talking about one particular
> issue, NOT about the Ada language as a whole vs. the C language as a
> whole.  Somebody claimed that Ada is superior to C because (1) you have
> to use hand-written make files in C, and (2) hand-written make files are
> awful.  I was simply trying to refute part (1) of that claim.  That's
> all.  (I happen to agree with part (2) of the claim.)
> 
> >...The only thing that I see exagerated  
>         ^^^^
> >in this thread is people's confidence in their ability to check their code  
as  
> >consistently and  perfectly as compiler would and/or promises to use  
> >prosthetics religiously. It gives me the same type of comforting feeling  
that I  
> >get from watching ads urging people to wear prophylactics. 
> 
> I understand and agree with that.  There are lots of folks going around
> denying that they themselves put bugs in their code, so where does all
> this buggy software I use every day come from !?  But that's not the
> *only* thing I see in this thread.  I also see some bogus claims about
> how Ada will walk on water and raise the dead.
> 
> >> Somebody (I've lost track of whether it was you or someone else) made
> >> the claim that C programming inherently involves using hand-written
> >> make files.  That's simply not true, and saying it won't convince
> >> anyone that they should use Ada.  At best, you can convince them to
> >> quit using hand-written make files, and use a more automated tool
> >> instead.
> >> 
> >> - Bob
> >
> >I like C and C++. They are good tools. If what you say is true then there is  
> >some hope that with the right reliable portable prosthetics I don't need to  
> >seriously consider something like Ada.
> 
> No, I disagree.  You *should* consider something like Ada.  You cannot
> add a whole bunch of tools to C (like lint), and produce an environment
> that has equal protections to something like Ada.  This is because C has
> no syntax for expressing certain kinds of constraints, which means that
> lint or any other tool is unable to know anything about those
> constraints -- they're written down as comments, if at all.
> 
> IMHO, in general Ada doesn't go FAR ENOUGH in that direction.  On the
> other hand, there are some cases in which Ada goes too far -- requiring
> the programmer to obey rules that merely get in the way, but don't
> actually help prevent bugs.  Ada isn't perfect (surprise, surprise).
> 
> >... I am obviously skeptical. This is a big deal to me and many other
> >programmers. Whether I stick with C/C++ or not, I don't care to see
> >professional programmers posturing and denying their limitations in
> >order to defend archaic tools at the cost of real solutions. How are we
> >ever going to get past square one if we let this kind of bullshitting
> >substitute for actual performance when it comes time to commit
> >resources. Here we sit with massive software projects falling in on
> >themselves and we want to defend things that suffer greviously and
> >explicitly from backward compatibility with tools that were a workable
> >compromise in 64k of memory and a 1MHz cpu.
> 
> I'm not sure what you're getting at here, either.  I don't think the
> problems of 'make' can be attributed to 64k of memory.  Besides, isn't
> it OK to defend one aspect of some archaic tool, without being accused
> of posturing and all those other evil things you mention?  I'm not even
> sure if you're accusing me or somebody else.
> 
> - Bob