Re: why learn C?

[Brian May <bam@snoopy.apana.org.au>]

>>>>> "adaworks" == adaworks  <adaworks@sbcglobal.net> writes:

    adaworks> Unlike the C family of languages, which are generally no
    adaworks> help at all, an Ada compiler frequently eliminates the
    adaworks> need for extensive debugging of silly errors; e.g., the
    adaworks> kind that originate from case-sensitivity, wrong order
    adaworks> of arguments to parameters, improper spacing, missing
    adaworks> curly-braces, and the plethora of language "features"
    adaworks> that plague those who have chosen to use any member of
    adaworks> the C family of languages.

    adaworks> It has always seemed rather odd to me that people who
    adaworks> are as intelligent as programmers, rarely question the
    adaworks> silliness of using tools such as C and C++ for serious
    adaworks> work.  They simply take for granted that the kind of
    adaworks> errors that are so common in those languages are somehow
    adaworks> akin to the laws of nature.  Java inherits many of those
    adaworks> same properties and is not much better.  It is taken as
    adaworks> an article of faith that programming involves heavy use
    adaworks> of debuggers.  Instead of asking why this is so, they
    adaworks> simply believe it is a fundamental law of programming --
    adaworks> mainly because the languages they have chosen make it
    adaworks> so.

I thought the following links were interesting.

http://www.mega-nerd.com/erikd/Blog/CodeHacking/autoconf_ifdef.html

http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html

"Rusty says the key criteria for an interface is how easy it is to use
correctly or (by Murphy's Law) how hard it is to misuse. He delineates
a spectrum from best to worst, which is so good I am going to
shamelessly reproduce it here:

    1. Compiler/linker won't let you get it wrong.

    2. Compiler will warn if you get it wrong.

    3. The simplest use is the correct one.

    4. The name tells you how to use it.

    5. Do it right or it will break at runtime.

    6. Follow common convention and you'll get it right.

    7. Read the documentation and you'll get it right.

    8. Read the implementation and you'll get it right.

    9. Read the correct mailing list thread and you'll get it right.

    10. Read the documentation and you'll get it wrong.

    11. Follow common convention and you'll get it wrong.

    12. Do it right and it will break at runtime.

    13. The name tells you how not to use it.

    14. The obvious use is wrong.

    15. Compiler will warn if you get it right.

    16. Compiler won't let you get it right.

    17. It's impossible to get right. "
-- 
Brian May <bam@snoopy.apana.org.au>