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

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

Szu-Wen Huang <huang@mnsinc.com> wrote in article
<4ud8m5$ka5@news1.mnsinc.com>...
> Tim Behrendsen (tim@airshields.com) wrote:

> : My point is someone who has "vaguely" learned five algorithms has
> : simply memorized them, and learned nothing about the general
> : principles of how algorithms are created.
> 
> No, your point was writing an algorithm in assembly helps to understand
> it fully.  I'll be my own case in point.  I remember most sorting
> algorithms vaguely, and I probably could not implement all of them
> off the top of my head.  Does that hamper me?  No, because I know
> which book to look them up in, and that's exactly what books are for.
> The important thing, however, is that I remember that O(n^2) is bad
> for a sorting algorithm, and O(n lg n) is pretty good.
> 
> Now, what about your student that knows *one* algorithm?

That's fine, anybody can look something up in a book.  I want
people working for me that can *think*, not just look it
up in the book.  Otherwise, how do you know when a
particular algorithm is appropriate for a particular problem?

When doing large projects, it's not just a matter of reaching
into the bag o' algorithms and pulling it out.  It takes
careful analysis, and the best way a student learns *that*
is to really go through the process of taking a problem and
seeing how the problem translates into data movement, etc.

What we're doing now is *sure* not working.

> : Someone who has "the feel" for two algorithms very strongly are
> : more likely to be able to extend that knowledge to creating new
> : algorithms.
> 
> Uhm, theoretically.  Somebody with only in-depth knowledge of run-
> length encoding is not very likely to come up spontaneously with
> Huffman or arithmetic compression.

Perhaps not "spontaneously", but you have them thinking about
compression issues.  "Thinking" is the key word, not just
memorizing an algorithm that they will forget after the final.

> : Computer Science is one of the few, if not only, sciences where a
> : student can derive all of it just by thinking.
> 
> Assuming the student doesn't have a deadline and all day to think for
> 40 years.  Many algorithms are obvious.  Insertion sort, for example,
> is what a human would do (if somewhat parallelized).  Quicksort, on
> the other hand, is nowhere near intuitive.  Be realistic.

I'm not saying everyone *does* derive all of it, but the
best programmers, even if they can't remember the exact
details of an algorithm, can rederive it by thinking
about the problem.

And I wouldn't say Quicksort is not intuitive, it is a logical
extension of recursive tree algorithms.  Not obvious, but
not unintuitive.  Lempel-Ziv or even the 'diff' algorithm
I might agree.

> Are you asserting that teaching software engineering instead of assembly
> language will somehow make the student unable to think?  Assembly
> language is a powerful tool best used by experts, not beginners.
> Beginners do not have the knowledge to use them properly, and tend
> to get caught in details and miss the big picture.  If you give an
> assignment of "implement quicksort in PC assembly", how much effort
> is spent in:
> 
> 1.  the algorithm
> 2.  I/O
> 3.  OS/platform intricacies
> 4.  debugging
> 
> ?  I would imagine your goal would be to maximize #1, which is why
> a HLL is better for the purpose.

Not only am I asserting, let me say in the strongest possible
terms that students are being graduated with CS degrees
that are unable to think.  I hate to keep harping on my
test, but on one particular hiring cycle, out of 50 applicants
49 were unable to create an algorithm for a problem they had
not seen before.  I hired the one guy, and he has been a great
success.

> : Truly understanding two algorithms is better than memorizing five
> : algorithms, because that is what *gives" the fundamental
> : understanding.
> 
> Fundamental understanding of RLE has little, if not nothing, to do
> with Huffman compression.  Fundamental understanding of quicksort
> has nothing to do with heapsort either.

That is simply not true.  Taking compression; if have done
thorough analysis of RLE, and understand the issues involved
in finding patterns (sequences of common bytes) and replacing
them with another encoded value, that is the basis for
more complex pattern matching/replacement.  If the student
is thinking, they will see that a large majority of the
input data is not being compressed, and this leads to wondering
if there is a general way to find more complex patterns in the
data.
 
> : > Teach a man an algorithm and some I/O routines to enter the input
> : > and display the output, then some routines to set up the stack,
> : > then some routines to initialize data,
> 
> : Yes, and wouldn't they truly understand I/O routines and stacks
> : after that?
> 
> They would, but would they understand the algorithm?

Sure; how much time do you think it takes to make one library
call to output data?  Push the parameters on the stack and
call 'printf'.  Big deal.

> : Yes, if your model is the brain-damaged 8086 model.  I personally
> : would use a 68000 to teach on because it's a nice straight-forward
> : orthogonal instruction set.
> 
> It doesn't matter.  You are burdening beginners with details that
> you could've avoided by using an HLL.  My school was contemplating
> teaching one freshman class Prolog as a first language and another
> Pascal, then switch in their second year to observe which was more
> effective.  It's too bad the experiment has practical problems,
> because it would be interesting to see if it's easier for a "recursive-
> minded" student to study iteration or the reverse.  In any case,
> you want to train students in problem solving, not why the OS requires
> value X in register Y.

I think you exaggerate the complexity of assembly.  This is like
saying "we want to train students in problem solving, not where
the commas go in the syntax."

-- Tim Behrendsen (tim@airshields.com)