Can Novices Jump Directly in C? (Books)

[uunet!bria!mike]

In an article, cs.arizona.edu!dave (Dave P. Schaumann) writes:
>In article <431 at bria> uunet!bria!mike writes:
>>[...]  The
>>reason why is because so many other langauges go through great contortions
>>to "insulate" you from the reality of memory and addresses.  Feel free
>>to flame on, but IMHO programmers program _machines_.  Anything that
>>goes to great lengths to insulate you from the machine is deprivation.
>>It's just a matter of how much deprivation is useful, and how much is not.
>
>The whole purpose of programming languages is to abstract the details of
>implementation as much as possible.  In any new programming language, three
>interlocked issues have to be addressed: safety, speed, and expressability.

This is true enough.

>Thus, we can see that the abstraction mechanism provided by modern programming
>languages is a trade off of safety for expressability and safety.  The notion
>that we program machines, IMHO, is wrong.  We program algorithms.  At it's
>highest level, no algorithm deals with memory, or addresses, or anything so
>concrete.  At this level, programming is utterly abstract.

I would think of it terms of "conceptualizing" algorithms, not "programming"
them.  When I write a program, I am "communicating" with a machine (or more
than machine), asking it to do some activity on my behalf.  The algorithm is
the _way_ that I ask, not the specifically the act of asking in of itself.

My point, however, had more of a religious tinge.  I fear that we have been
training programmers to think _only_ in the lofty, abstract concepts of
"lists", "structures", "objects", etc.  IMHO, this is half a progammer.  Yes,
you need to be able to conceptualize and implement these algorithms, but
you should also know _how_ the machine is doing it.

Steve Jobs has made comments that computers should be like telephones; everyone
has one, and it's treated like a magical black box by most.  This is fine for
the public at large, but not for programmers.  Ultra-specialization is simply
an excuse for ignorance.  Obviously not everyone can know everything about
everything, but at least a vague idea is a start in the right direction.

Encountering students who only think in terms of variables and functions
is somewhat disquieting.  Especially when that have no idea what the
difference is between stack, bss, and data space.  A while ago, I was talking
to a person who was completely confused over this:

	int	(*some_func)();

		some_func = some_extern_func;
		some_func(arg);

Since 'some_func' was not the name given to any function in the program,
he was completely lost on how it could be used.  Having your head so deeply
entrenched in the lofty clouds of algorithms, not knowing _how_ what
you are doing works, is like being able to do differential equations but
needing a calculator to help to add a column of numbers.

>Now for the average programmer, language choice is merely a matter of "what do
>I know/what is available?".  For a serious programmer/computer scientist,
>language choice is a matter of "what fits the problem".

Acutally, I would think that language choice depends on what your _employer_
uses for a language (unless you're self-employed, that is).

You made some excellent points, and I agree with them.  However, lets not
become _too_ abstract and disasociate ourselves from the machine in favor
of some purely conceptual utopia.

>Dave Schaumann      | DANGER: Access holes may tear easily.  Use of the access
>                    | holes for lifting or carrying may result in damage to the
>dave at cs.arizona.edu | carton and subsequent injury to the user.
-- 
Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own.
Title of the week: Systems Engineer    | UUCP: ...!uunet!bria!mike
-------------------------------------------------------------------------------
Remember folks: If you can't flame MS-DOS, then what _can_ you flame?