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

["Tim Behrendsen" <tim@airshields.com>]

Lawrence Kirby <fred@genesis.demon.co.uk> wrote in article
<841797763snz@genesis.demon.co.uk>...
> In article <01bb8f19$9a89d820$32ee6fce@timhome2>
>            tim@airshields.com "Tim Behrendsen" writes:
> 
> >Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
> ><4vcac4$gm6@zeus.orl.mmc.com>...
> 
> ...
> 
> >> A very procedural point of view.  Many of the proponents of object
> >> oriented design might have a problem with this view, and demonstrates
> >> my point about allowing the details of implementation to obscure the
> >> higher level problem solving process.
> >
> >There is no other view than the procedural view.
> 
> Some functional language programmers might take issue with that
> statement. Prologgers may have a thought or two also.

What I mean by that is, for work to get done, the computer
must perform transformations of data over time.  You can call
that an implementation detail if you want, but there simply is
no such thing as "instantaneous" algorithms.  You can look
at a mathematical proof as existing without procedures, in the
sense that it simply "exists", as a statement of truth, but
algorithms are different.  They are, by their nature, a
process, and processes require a time axis.

Now, there are certain rule-based languages, but these describe
a process just like any other language.  The different is, rather
than describe the process as a set of linear paths, it describes
them in a way like a pachinko machine.  You have a set of pins, and
when you drop a marble at a certain angle, it bounces along the
rules defined by the pins, and comes out a certain position.  I
haven't described a linear procedure for every angle, but I have
still defined the process by which data (the marble) flows
through the algorithm (the pins).  In other words, the purpose of
the rules is data flowing through them.

> ...
> 
> >How can someone implement *any* sort in assembly language,
> >and "learn it but not really understand it"?  To implement it,
> >you have to do it in great detail, and you simply can't do the
> >"push and prod until it works" approach to programming, which
> >is what I think a lot of students do.
> 
> Example: once I had an assignment to implement a sort on IBM 360
assembler.
> What I learnt to do was convert a sequence of individual operations into
> assembler instructions. It didn't teach me a thing about the sort
algorithm
> (which was merge sort).

I find it difficult to believe that you implemented a merge sort
in assembly without understanding the merge sort algorithm.

> I can't imagine a worse way of teaching an algorithm than using assembly.
> It is essential to separate the algorithm from the implementation and
> assembly ties you up in knots with implementation specific details
> especially when you are just learning 'computing'. Once you've learnt
> an algorithm it makes a lot of sense to practice that algorithm by
> writing implementations, even in assembly, but you should understand the
> algorithm to a reasonable extent *before* attempting that.

On the contrary, I think it is essential to focus on the
implementation in as much detail as possible.  You can pack as
much algorithm theory into a student as you want, but they don't
really "get it" until they type in a program, and experience it
not working, figuring out why, fixing it, and repeating the
process until they see the expected output.

I think you take how to "think like a programmer" for granted so
much that you don't understand that it doesn't come naturally
to the average person.  The procedural nature of the computer is
something to be learned, just like algorithms.

-- Tim Behrendsen (tim@airshields.com)