Re: Should I learn C or Pascal?

[dewar@cs.nyu.edu (Robert Dewar)]

Peter says

"This doesn't mean it can't be used well; although C doesn't always help you
write good code, it certainly doesn't prevent you from doing so."

Although I agree that it does not *prevent* you, it certainly makes it
hard, and what we see in practice is that few programmers persevere
through the road blocks.

For example, headers can almost be used like package specs. They very 
seldom are (it is common for example to find uncommented headers).
But if you use headers as package specs, you find you have a nasty
problem if these headers define data, since the notion of macro copying
is not quite right. Yes, you can get around this, but most people don't
bother to do it systematically.

As anoher example, the lack of named types that are well separated means
that you gain much less from

   typedef int Inches;

than from (in Ada)

   type Inches is new Integer;

since in C you can assign Inches to int (or anything else) anyway. The
result, alhough it would still be useful for documentation and specification
purposes to introduce a typedef like the above, most C code does not bother.

In general both data abstraction and separation of interfaces and 
implementation do not come very naturally in a C environment. Now if
you have learned these principles in the context of another language
like Ada 95, then you will find that you can indeed apply them in C,
but people who learn C as their only, or first language, if not taught
*really* well are likely to establish their understanding of what
programming is about with a complete lack of understanding of these
fundamental issues.

Languages are more than just a set of syntax and semantic rules, they also
come with a "typical style" of writing code. This style is partly a matter
of tradition, but is strongly influenced by the design of the syntax and
semantics.

In language comparisons and discussions, people often trot out arguments
that boil down to the following:

   Anyone can write bad code in style x in language y for all x,y
   Anyone can use good technique x in language y for all x,y

These statements are generally true for any language other than a very
trivial one, or for techniques that are very specifically geared to 
language features.

However, they do not address the real issue, which is what is he typical
style of writing code in a given language and why? For the majority of 
programs, these are the real issues, and what we look for are languages
where the typical style of writing in the language embodies the principles
and techniques that we would like to encourage.

One clue of the importance of these typical style issues is the difficulty
of writing effective automatic translation programs from one language to
another. It is not too hard to write a translator that translates one
computer language to another, but to write one that takes a program written
in the typical style of language X and produces an idiomatic program written
in the typical style of langauge Y is extremely difficult. 

In fact I would venture to guess that at this stage translation of natural
languages from one to another is more successful than translation of
computer programming languages. That's because the entire strucure of
a program can be altered as a result of the shift of styles.

Note that this applies to a human too. Someone who knows French and 
English really well can take a novel written in one language, and produce
an acceptable idiomatic translation by translating sentence by sentence.

But even if you know C and Ada well, you will typically find that translating
a C program into Ada will involve major restructuring, and cannot be done
on a statement by statement basis.