Re: why learn C?

[Georg Bauhaus <bauhaus@futureapps.de>]

Peter C. Chapin wrote:
> Georg Bauhaus <bauhaus@futureapps.de> wrote in 
> news:1175246243.5771.67.camel@localhost.localdomain:
> 
>> If you allow me to be pedantic, SPARK is not distinguished from
>> Ada by external rules for programmers. Rather, it has its own
>> language definition, and translators that know about nothing
>> but the SPARK language. This approach is very different from
>> establishing coding rules.
> 
> How is it different than using coding guidelines together with a tool 
> that checks them automatically?


Maybe I was incorrectly assuming that coding rules are not
enforced in the same way that language rules are enforced, because
using a special language parser with rule checks built in requires
additional efforts and tedious discipline (in the short run).
But I'm not too confident that the efficacy of coding rules
without such a tool is de facto the same as that of existing language
rules. Coding rules require programmers who will apply the rules
by their own free will and who know quite a bit about programming.


> As you can probably guess, I'm a big 
> believer in extending a programming language with tools.

I would even hope that a systematic survey of how tools for translation,
checking, "architecture" etc. are used  can help establish some knowledge
of what a future very high level language should provide.

But here's a case demonstrating that now we are (still) in sore need of 
good language rather than good rules. (A difficulty of arguing in favor of
a "strict" Ada-like language will be the "works for me razor" applied by
those who seem to be using less strict languages with seemingly good success.
The argument is similar to that of very good Lisp programmers who build
well working macros reflecting their own sophistication with all pros and
cons of that. As you have mentioned, it may be fine for small teams.)
The case is that of conditionals where a condition is written
after the statement that it controls, but the programming language is not
really using postfix notation. Postfix conditionals aren't in either
C++ or Ada, but they serve well as an example of where the human element
matters in adopting rules or not.

The postfix conditional has been in Perl for some time, and postfix
forms of conditionals and loops are being added to Python. Perl::Critic,
a rule checking tool, will warn about postfix conditionals, a negative 
rule being based on the recommendations of a well received book
(Perl Best Practices (PBP)).
But why is the postfix form of "if" nevertheless popular in new Perl code,
even added to Python, although it has been identified as a problem?
My guess is that a human can say, "do this unless there is X", a postfix
conditional. By doing so he or she uses a common mode of expression that
is well understood by a human, hence seems acceptable, even natural.[1]
Another reason of continuing popularity of postfix if, opposing the PBP rules,
might be that a popular Perl book doesn't talk about the dangers of postfix if.

Like C++ and Ada, Perl is a given language. Corresponding tools are just not
used frequently, so we will continue to see code that recreates fancy pitfalls.
Therefore, the best way for years of rule checking experience to manifest
itself in software is adding the most important results to the language
proper. Or, where possible, use a language that enforces these rules by
definition.


[1] "The *if* and *unless* modifiers work pretty much as you'd expect
if you speak English." (Wall, L.; Christiansen, T.; and Schwartz, R.L.:
Programming Perl)