Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?]

[seebs@solutions.solon.com (Peter Seebach)]

In article <01bb9fe6$7299d800$87ee6fce@timpent.a-sis.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>The original progenitor of this thread is my assertion that
>the most important thing a student can learn is the fundamental
>procedural nature of the the computer.

I would probably disagree.  I don't consider the implementation to be
nearly as important as the design.  Students should be learning the
principles of proof and design.

>Time is extremely useful in understanding how something works,
>although you don't normally invoke it's name.  Even in your
>optical computer, you have light-encoded information flowing
>through mirrors, etc.  *This is time*.  If you are explaining
>to a student how it works, your finger will trace a path
>through the machine.

But that explanation is an explanation of *another way to think
about it*, not of how it works.

We frequently use the procedural view because it's the most natural for
languages such as English to describe; we don't have a "simultaneous" tense.

This is frequently a downright *bad* way to model a problem, or to think about
the model.

>My entire point before we went down this road is that I think
>many teachers take it for granted that cause-and-effect and
>procedure are so obvious they don't need to be learned, and
>that's not true.

They are important, but not necessarily the most important.

>> Yes, but fundamental to what everyone in computing except you means by
>> "procedure" is "a discrete sequence of steps".

>No, fundamental to *you*, perhaps, but I have never heard this
>definition before.  Of course, your optical computer fits this
>definition, since it has a discrete sequence of steps (mirrors,
>etc.), and you claim that *it* doesn't.

That's what I'd mean by a procedure; if they aren't separate, they're only one
step.  If there's only one step in the whole process, it's not much of a
procedure.

How to build a house:

Step 1.  Assemble the materials in the form of a house.

This is *not* a procedure.  :)

I would not think of an optical computer in terms of steps happening over
time, unless it was a very *large* optical computer.  In practice, it will act
as though everything happens all at once and continuously.  This is harder to
think about, but much more useful to understanding it, and less prone to
making the wrong kinds of design decisions.

>No, the definition is very clear.  The point is that non-procedural
>*expressions* are an abstract concept.  I have no problem with
>saying that algorithms can be abstractly expressed non-procedurally,
>but they cannot be implemented non-procedurally.

So we should avoid procedural things and implementations until students are
comfortable with the abstractions, since abstraction is much more important to
an understanding of *anything* than any procedure or implementation.

>Now you're arguing worthless semantics.  Obviously that's not what
>I'm saying.  How about "No algorithm implementation is not
>procedural", which is what you know that I meant.

I'd debate that.

>In other words, procedural mechanisms have a start, middle, and
>end.  Non-procedural expressions do not.

In which case, much programming is not procedural.  In which case,
it is very bad to try to convince students that the computer
is "fundementally" procedural, because this will not help them
understand the domain they're working in.

Proceduralness is like 5-volt-ness.  It's basic to the majority of
implementations, but not relevant to a lot of the things people
will need to know to use a computer.

>You prove my point that programmers take the procedural nature
>of the computer as so obvious as to be beneath discussion, but
>it's not.  I cannot stress this enough: THIS MUST BE LEARNED BY
>STUDENTS.  This is the primary, fundamental axiom of computers.

Nonsense.  It's completely irrelevant to a good understanding of many
aspects of computers, and downright misleading for whole families of
programming languages.

It is very important that they learn to use this view of computers;
it is neither desirable nor necessary that they believe it is the only view,
or that it is the most correct view, or any such.

>How many questions do we get in this newsgroup where a student
>simply didn't follow the flow of the program to see what happens?

Quite a lot.  We also get a fair number where the flow of the program is not
relevant to an understanding of the problem.  We even get problems where
an attempt to think of the "flow" of the program will bite the student,
because they're compile-time problems, not run-time problems.

>This is so obvious to you and I that we don't think about it,
>but *they didn't*!  Because they have only a vague feeling of
>flow, and are still looking at the program as a kind of
>weird combination of a solid object and something with a flow
>of time.

It is.

>Take recursion.  How can you not understand recursion if you
>understand in your soul that computers execute a flow of
>instructions?  You can't, and that's the point.  Understanding
>the time axis is the key.

I disagree.  I think I understand recursion, and I don't think of it
in time at all, I think of it in space.  Recursion doesn't move forward
in time, it moves down in space.  I tend to look at the naive recursive
quicksort as a tree of sorts, not as a sequence of sorts.  This makes it
much more obvious how it *works*.

Not how it's implemented, mind you; how it *works*.

The flow in a recursive algorithm is up-down, not forward-back.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.