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

[huang@mnsinc.com (Szu-Wen Huang)]

Tim Behrendsen (tim@airshields.com) wrote:

: 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?

Because I know the range of performance I can expect from a
class of algorithms, expressed in time complexities.  In fact,
I also know what problems have polynomial-time solutions, and
what *don't*.  None of the above comes from my expert knowledge
of assembly.  Are you saying if I don't know assembly I can't
pick an algorithm?

: When doing large projects, it's not just a matter of reaching
: into the bag o' algorithms and pulling it out.

Really?  When you want a sorting algorithm, I suppose you spend
a few weeks thinking about it first?  When you want compression,
surely you meditate in the mountains?  The industry has many
many solved problems, some free, some not free.  It *is*, as
a matter of fact, just a matter of knowing where to look - and
when to stop looking.  Again, none of these have to do with
assembly language.

: 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.

Data movement, sir, is not restricted to assembly language.
Assembly language, in fact, impedes the understanding of data
movement because of all the extraneous things that have to be
done to make the program work.

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

Because some students graduate without understanding algorithm
complexity, not because they graduate without learning assembly
language.

: > 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.

I never said anything about a student that forgot everything after
an exam.  I said, it is better to have *general* knowledge than
specific knowledge in intermediate levels.  My student would've
remembered that he was taught Huffman, which compressed better
than RLE.  Now, how Huffman works he may not immediately remember,
but he would know where to look it up, and that's all he needs.
This student with general knowledge can use books to his advantage,
while your RLE expert sits in a cubicle and tries to reinvent the
wheel.

: > 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.

Of course, but we're not talking about the best programmers.  We're
talking about beginners and intermediates.  The best programmers are
probably experts in several related fields - the language, the
platform, the algorithms, and the tools.  Now, without comprehensive
knowledge, it is better to be general than specific.

: 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.

How long did it take you to come up with Quicksort armed with
the knowledge from implementing bubblesort in assembly?

: 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 don't disagree.  In fact, I'll give you an example.  My students
in introductory Pascal courses started programming with Turbo
Pascal.  If you learned programming earlier, you'll probably be
the kind that thinks hard about a problem, goes "eureka" one day
in the shower, and then sits down to type.  This generation, on
the other hand, sits right down and types away and turns in some
truly embarrassing solutions to simple problems.

I tend to blame the TV.  Point, however, is on my side.  The
students were given tools they could not use properly.  The
debugger that was so convenient for an expert actually destroyed
their will to think about a problem ahead of implementation.  Now
they just hack together some code and trace through it until they
get it right.  Assembly will have the same ills.  Firstly, they
distract the students and force them to implementation details
specific to the platform, and secondly is simply too powerful for
beginners to use properly.

: 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.

I gave the Vernier encoding as a hands-on exam.  You are of course
familiar with the:

   A B C D E F G ... Z
 A A B C D E F G ... Z
 B B C D E F G H ... A
 C C D E F G H I ... B
 .
 Z Z A B C D E F ... Y

table, wherein you ask for a plaintext string and a cipher key, then
index the row with plaintext and the column with the key to get the
ciphertext.

Trivial?  None of the ten or so students considered the fact that
the table can be expressed as a formula.  *All* of them stored this
table somewhere.  One particularly creative one even read the table
from a textfile.

I don't think this phenomenon was due to the fact that they didn't
know assembly.

: > 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.

Even if what you say is true (it's difficult, at best), I still don't
see how this student can be a more effective engineer than one who
has vague knowledge of both, but distinctly know that something *is*
better than RLE.

: > : > 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.

Then why not use C instead?  Realize that you are the one trying to
prove that assembly is better for teaching algorithms.  If you're
going to use library functions extensively, what's wrong with C
then?

: > 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."

Where the commas go is important, because it is a prerequisite to a
correct solution.  If we one day can build computer languages that
can understand humans better, perhaps we will not care where we
put commas.  Assembly is not complex per se, but is more complex
than HLLs to learn and read, and as such is counterproductive when
used as a tool to teach algorithms.

You still haven't proven why assembly is necessary, or at least
better.