Re: Programming language vote - results

[fred@genesis.demon.co.uk (Lawrence Kirby)]

In article <3470EF6E.F74@lysator.liu.se>
           ingemar@lysator.liu.se "Ingemar Ragnemalm" writes:

...

>> Efficient is good.  Tight can be good.  Impenetrable is generally not
>> good.
>
>When "efficient" and "tight" means as few keystrokes as possible, it
>isn't good.

Agreed but that don't mean that in C any more than the do in any other
language. 

>Efficient C code usually means that you take
>responsabilities
>that the optimizer should really do for you, and do that through

No, it means you work in partnership with the optimiser. You deal with the
higher level issues such as algorithms and general approach and the
optimiser deals with the lower level details.

>questionable backdoors in the language. Case switches jumping into
>while loops is one example.

Perhaps you could give an example of something that is used more than once
in a blue moon? C supports goto. It is rarely used in practice but there
are some situations where it is simply the best approach. The vast majority
of cases of coding efficnently in C don't depend on these sort of tricks
but they are there when you need them and occasionally you do.

>> I disagree with at least the implications of your conclusion.  Writing,
>> on purpose, impenetrable, bad, inefficient, and ugly code is one of the
>> best ways to comprehend good code better.  It's all well and good to say
>> "look, here's a good way to do this".  It's just as good to say "and look,
>> here's a bad way".
>
>> You can't understand fully what makes good code good without understanding
>> just as fully what makes bad code bad.
>
>When you show the bad way to those kids, they think it is WAAAY cool!
>They will use any stinking obscure construction just because "it is
>valid C code".

Are you talking about people who are going to develop serious code or not?

>Simple example from real life:
>
>if (call_this() || call_that());
>
>Valid, yes. Better than
>
>if (!call_this()) call_that();

The latter is certainly better C style and isn't going to be less efficient
than the former.

>or more clear forms in other languages?

That is a matter of opinion. I doubt whether you will find a demonstrably
clearer form in another language.

>Some people actually think so.

I'm sure some do. It is possible to program using a bad style in any language.
You're arguing more about the culture that has grown up around C than about
the language itself. For better or for worse C became the mass-market
language of the 80's and the result of that is a lot of people out there
using it who have never really learnt the principles of good programming.
This isn't helped by the plethora of awful books that have been published
purporting to teach C. This is why the emphasis in comp.lang.c is on
programming in standard C in an efficient but more importantly clear way.
Desire to write "cool" code is an insignificant problem compared with
simple lack of knowledge and misinformation.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------