Re: why learn C?

[<adaworks@sbcglobal.net>]

"Maciej Sobczak" <no.spam@no.spam.com> wrote in message 
news:etqp42$4g6$1@cernne03.cern.ch...
> adaworks@sbcglobal.net wrote:
>
>> Unlike the C family of languages,
>
> I presume you mean C, C++, D, Java, C#.
>
Actually, D and C# seem a little better than the others
you named.   In fact, there are some features of C#
I quite like, especially when one compares Java.
>
> Tha last time I made case-sensitivity error the compiler helped me.
>
But C/C++/Java compilers are not consistent in this respect, and one
would be foolish to rely on them for that.
>
>> wrong order of arguments to parameters
>
> I can do this error in Ada quite easily.
>
Unless you use named association and avoid the use of
predefined types.
>
> Yes, there are named parameters in Ada. And structures with named components 
> in other languages.
>
This is not even an option in C/C++/Java/ or other of the C family.
>
> Please provide an example of code where improper spacing leads to extensive 
> debugging.
>
Another responder dealt with this.
>
>> missing curly-braces,
>
> The last time I missed the curly brace the compiler told me that.
>
It is not the absence of a single curly-brace, but the occasional absence
of a pair of them that sometimes leads to long and entertaining sessions
of debugging.  This would not happen in Ada.
>
> (for the sake of this discussion let's forget about the fact that in any 
> self-respecting programmer's editor missing curly-brace is plain impossible, 
> because braces are part of text formatting rules)
>
As noted, the problem is not a single missing curly brace.  Further,
misplacement of a curly-brace can also be highly entertaining.  Units
in Ada, including declare blocks (which ought to be used minimally)
have the option of being named.  I use this option consistently.  I don't
have that option in any of the C family of languages.
>
>> and the plethora of language "features" that plague those who have
>> chosen to use any member of the C family of languages.
>
> Any language (from any family) older than one version has "features".
>
And some have more "features" than others.
>
>> It has always seemed rather odd to me that people who are as intelligent
>> as programmers, rarely question the silliness of using tools such as C
>> and C++ for serious work.
>
> Maybe because they are intelligent and can reasonably balance pros and cons of 
> various technology choices.
>
I rather think not.   With all the advantages of Ada over the C family of
languages, it simply makes no sense to choose one of those languages
for any reason other than their availability.  It is somewhat like going to
a fast-food restaurant instead of a restaurant where one would get better
quality food.   The fast food restaurants are quite popular, but they are
not especially beneficial froma dietary perspective.
>
>> They simply take for granted that the kind
>> of errors that are so common in those languages are somehow akin to
>> the laws of nature.
>
> That's a good point and indeed a significant fraction of the community takes 
> errors as part of the game. But I wouldn't attribute it only to the language 
> choice (although that's an important factor indeed), also to the massive 
> approach to education ("learn programming in 24 hours now!").
> Teach millions to program in Ada and you get tons of crappy code.
>
I take your point.   No language by itself can eliminate stupidity.   However,
choosing good tools can make a difference.   Ada is not the right tool for
everything.  I like some of the languages such as Python and Ruby that have
recently come on the scene.  However, those languages are not suitable for
every kind of problem.   We always want to choose the right tool for the
right job.

This discussion centers around the idea of debugging.   Even crappy Ada
is less likely to lead to the onerous level of debugging found in C or C++.

>> Java inherits many of those same properties and  is not much better.
>
> True.
>
>> It is taken as an article of faith that programming
>> involves heavy use of debuggers.
>
> Not necessarily. The advocates of test-driven development (TDD for short) 
> openly say good bye to debuggers, at least in blogs.
>
I am quite aware of TDD.  I am not a fan.   While many of the claims of
the TDD advocates have some virtue, it is a fact that not all errors in a
program can be detected through testing.   Further, as Dijkstra notes, "We
can test for the presence of errors, but not for their absence."   TDD can
be a good technique for augmenting the correctness of a design and its
implementation, but it is no substitute for other methods.  Reliance on
TDD exclusively seems a bit foolhardy, just as reliance on type-safety
alone, inspection alone, exception handling alone, or any of the other
popular approaches to software dependability.
>
Too many TDD advocates seem to reject the importance of developing
rigorous software requirements prior to beginning the programming process.
The notion that the tests are the requirements is naive, at best.  This might
work for smaller software projects where the domain is well-understood,
but it is not appropriate for large-scale software systems where dependability
is life or mission critical.
>
>> Ada is a programming language that makes it easier to focus on the design
>> before dealing with the details of that design.
>
> Yes, but Ada is not unique here. In C++ or Java you can do a lot of design 
> before actual implementation starts.
>
The design of Java fails to encourage good design.   This is, in part, due
to the tight relationship between all of its parts within a single library and
compilation unit.   C++, while supporting a model of separate compilation,
does not support it well.  The relationship between the specification and
the implementation in C++ is sloppy, at best.
>
>> Then, Ada  makes it easier to ensure that the details conform to the design.
>
> Yes, but Ada is not unique here. There are differences in what is the scope 
> and precision of design expression, of course, and this is where Ada shines. 
> But conformance between the details and the design (specs) is ensured in every 
> static language.
>
Well, this is not the case unless one jumps through a lot of hoops to
make sure it is.   It is certainly not the case in C++.   Consider the
requirement for #IFNDEF and other bits of fluff that a C++ programmer
must provide to ensure that all the pieces are where they ought to be.

Ada provides the developer with options that make it much more likely
that everything will snap together as expected.   It gives more of an
engineering flavor of the design and development process.  While it
is true that an Ada developer need not use the options that provide
this capability, those options are not even available in C, C++, Java,
D, or C#.

If I have a torque wrench available and fail to use it, the twisting of
the head from the bolt is my fault.  If, however, I use the torque
wrench correctly, I have a greater chance of doing the job right.
Ada is like a torque wrench in software.  I can measure the level
of torque more easily than I can simply using any old long handled
wrench.  C and C++ are like a long-handled wrench. I can do the
job, but I have little hope of getting it right, and I don't know I've
gotten it wrong until it breaks.

That is one of things I find so fascinating about modern programming:
that programmers take for granted that they cannnot know how good
their program is until something breaks.  With Ada (and also with Eiffel),
one can know much more about what might break, can prevent such
breakage before it happens, and can set the limits for breakages so
they are less probable at testing time and deployment time.
>
>> I wonder why that is such a difficult concept for so many.
>
> It isn't. Only the tradeoffs change.
>
>>      It always amazes me that someone would choose an error-prone
>>      programming language such as C++ and expect error-free programs.
>
> It always amazes me that someone would choose a language that has no 
> measurable user base such as Ada and expect to build a successful team.
>
Again.  I would rather eat at a good restaurant than at a popular fast-food
restaurant, even though such restaurants are not as abudant.
>
> The missing user base is one of two major problems that prevent me from 
> starting an Ada project, whether at work or in my free time.
> The other is the lack of *free* Ada compiler on one of my target platforms 
> (LynxOS).
>
One must live with the limitations imposed.  If there is no compiler for the
platform, the choices are not as happy.  Also, as I noted earlier, Ada is
not the only good tool and is not the right tool in every case.   However,
from my perspective, C++ ought to be the tool of last resort.
>
> "There are just two kinds of languages: the ones everybody complains about and 
> the ones nobody uses." - Bjarne Stroustrup.
>
Dr. Stroustrup did a remarkable design within a boundary that imposed a
lot of restrictions that, even he admits, were not ideal.  Given the constraints
at the time C++ was designed, no one can fault him or criticize him for his
work.   It was brilliant.   However, I am reminded of a TV show called
McGiver where the hero, also highly intelligent and innovative, was able to
invent solutions with a minimum of resources at hand.   Even the most
brilliant of minds, when constrained by an context that limits the options
for a design, will produce a solution that is less than ideal.

The Pythagoreans fell short of their goal of making "number" the universal
foundation for an enduring religion.   They simply did not have everything
they needed to make that happen.   Renes Descartre could not quite bring
himself to recognize negative coordinates.  Many brilliant people over the
millennia have made significant contributions within the constraints of their
environment and context.

C++ was a brilliant piece of design.  It is just not good enough when one
considers the other options currently available.

Richard Riehle