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
<4ue5l3$frr@news1.mnsinc.com>...
> 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?

It's not a question of "knowing assembly" or not, it's a
question of understanding algorithms.  There's more to writing
programs than just knowing an algorithm is O(log n).  It
has to implemented efficiently.

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

Maybe you're paid to sit and write sorting algorithms all day,
but where I sit, the world is not that simple.  Algorithms
have to fit into a cohesive whole, and it's often the case
that some algorithms are more appropriate in certain cases
than others.  Otherwise, everyone would always use Quicksort.

But, you're right that this has nothing to do with assembly.
The question is how to have students get a feel for how
algorithms actually work in the real world, and there is no
substitute for working with the real computer.

> : 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 extraneous things?  I don't understand why you think it's
so enormously complicated to use assembly.  Programmers used
to do it all the time, and they somehow managed to write
programs without suffering mental breakdowns.

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

I agree with the first, but the reason they are not "getting"
algorithm complexity is because we're shrouding it in all
this abstract mystery.

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

You're making the assumption that we teach them RLE, and then
hide all the books from him.  My point is that packing
algorithms into their heads is not necessarily going to
teach them how to invent algorithms when they need them.

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

But we can learn from the best programmers about how their
thought processes work.  Again, the most important thing is
to get the students "thinking like programmers".

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

I was introduced to Quicksort before I had the chance to
invent it myself. :)

> : 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.
> 
> [snip]
> 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.

Don't get me started about debuggers... I think in certain
ways debuggers have lowered productivity rather than
raised it.

>[snip]
> 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.

Look, it's not so much that I love assembly so much, but I
think a much more basic step-by-step approach works better
than the overly-abstracted approach that's currently in vogue.
Assembly just seems to be most straightforward method at
getting to the fundamentals of going on.  I wouldn't be completely
opposed to an "idealized" assembly that was interpreted or
something.

I just want students to get a better feel for what the computer
really does.

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

Because the student is thinking about compression, rather than
being spoon-fed the information from a book or the teacher.
When the get into the real world, this thought process will
stay with them when they begin to need to break down much
more complex problems into algorithms.

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

Using library routines to do simple I/O tasks does not take
away from the learning experience of the algorithm.  Somehow
input and output have to happen, and I see no reason to burden
the student with problems that are not relevent to what they
are trying to learn.

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

Again, I go back to the fact that what we're doing now is
not working, based on my experience (and you admitted to
above).  What are we doing now?  We are teaching students at
an extremely high level of abstraction.

Since this does not seem to be giving the students the
critical thinking capabilities, what would?  I think that
more emphasis on the "fetch-and-execute" fundamentals would
force the students to think more procedurally and less
abstractly.

Not to be repetitious with this example, but I look at how EEs
are taught.  They begin by learning the fundamental components;
resisters, capacitors, ohm's law, etc.  They seem to me to be
much better prepared to do real work than CS graduates, and I
think it's because of the early emphasis on the fundamentals.

-- Tim Behrendsen (tim@airshields.com)