Re: Fun with C

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 4/23/11 9:23 AM, Dmitry A. Kazakov wrote:
> On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salomão Helou Neto wrote:

>> It is quite different with programming languages, as C is actually
>> harder than Pascal, which is a great tool for teaching programming.
>
> In which sense is C harder?

C is harder to learn from the ground up, as your first formalism,
when measured by the number of non-intuitive and non-essential
fundamental concepts that students must all understand in order
to understand and use fundamental ideas of C.

Notions are formed by distinction. Formally, each distinction D(n)
means another fork in the "tree of rules" that a human mind must
climb when trying to understand what's in the leaves. Humans have
limited capacity when following decision trees in any case, not just
when learning.  More so when topics change along the way, as is the
case with C, as explained below.  Changing topics requires context
switching---which is another distinction, thus f(D(n)) where f >= id.

Some of C's concepts will draw students of C to syntax, others
to operating systems, rather than focusing their attention
on what should be a meaningful part of C program text,  You might
be so familiar with these distinct notions that you have forgotten
that it once was difficult to keep them apart: you just saw
these different pieces of C text but they all looked alike!
Teaching C, then, by force is lacking modularization, in the following
sense.

For example, C offers distinctions that are non-essential
when seen from the viewpoint of teaching programming subjects.
Yet, they must be understood by the novices should they need to
to write programs, which, I think, they usually do.

- The statement and the block (of statements), and why and how
   to write them

Typically, a distraction:

Mostly offered when the subject is C's case distinction with if/else.
When teaching conditionals, the focus should be on conditional
execution.  It will easily be on whether or not you need braces,
and what the braces mean, and about what happens if you do or don't
write "else" and then do or do not write braces,

Blocks/statements confront novices with recursion at the level of
grammars---when they are trying to understand if/else.  But
recursive definition is not an easy concept in itself.  Observe
students (in the general sense of the word "students",
i.e. including pupils, or hobbyists) trying to understand
mathematical induction, which requires recursive thought.  It takes
time and practice to become acquainted, and then induction at school
was usually about natural numbers, not symbols, or about how
you yourself write.  Entire books like "The Little Functionaler"
by Friedman / Felleisen are all about recursive definitions.
They aren't easy.  Intrinsically, recursive definitions are very
close to circular definition, which, as you know, are vicious.


- C's shorthands

Too many things in one piece.

Professional typists learn how to write first.  Shouldn't students
of C (as a first language) do this, too? (Typists need to learn
the rules of written natural language first.  Orthography.  Then,
I imagine, other practical things about writing.)

Only then they, typists, learn how to use shorthands.

C culture, I believe, does not call *x++ a shorthand.  It calls
it an idiom.  It is even possible to argue that there is no
shorthand at all because everything is (mostly) well defined
and not an abbreviation.  But this argument misses modularity of
attention: one thing at a time.  The above expression requires
that the student isolates each single effect, and separates it from
the others.  Then thinks about implicit order and such. Why
should beginners in programming become familiar with shorthands
so very early?

Note how C's shorthands are totally different from the definitions of
"A Programming Language", i.e. APL languages.  There, TTBOMK, every
symbol has one (or two) well defined meaning(s) that do not
"abbreviate". Or that could easily be written in another way, as is
the case with C when, e.g. isolating the constituent parts of *x++.
The sum of 1 .. 100 in APL is

    +/⍳100

which, in Python, reads

   reduce(plus, range(101))

where
   def plus(x, y): return x + y

That is not to say that using "/" as reduction operator and not
division might not be confusing at first.  It is also not to say
that ⍳ and the many other operator symbols won't take time to learn.
But APL's mode of expression does not conflate so many things into
one piece, and fewer of them are about syntax or precedence.


- main and its (int argc, char* argv[]), that C shares with Java.

You will see lengthy discussions of what these mean.
And how they come to be, out of nowhere (known).  Or how
they could be passed to the program and that argv[0] is
of a different quality than argv[n], n > 0.

Similarly, about return 0; the teacher will have to explain why in
a Boolean context 0 means false but in the context of operating
systems, 0 means OK.  And what this has to do with the C program
in the first place.


- file scope.

An important feature of C---and its OS...

You'll need to know operating system concepts including file
system concepts before you can understand program text.
What is it that warrants dragging the file systems into it?
Why can't we understand the text of programs without the
external notion of a file?  K&R have no need to ship their
book split suitably into files.  They don't!


I guess I could go on for some time...  And I haven't mentioned
pointers at all and how they relate to arrays and to the + operator,
...

Is this a sense in which C is harder when you
want to learn the fundamentals of programming?