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

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

Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
<4v1pnf$8du@zeus.orl.mmc.com>...
> In article <01bb89f1$31be4f60$87ee6fce@timpent.airshields.com>, "Tim
Behrendsen" <tim@airshields.com> writes:

> > is truly understood or not.  Solving a problem is not an
> > "abstraction" question, it's a question of breaking it down
> > into fundamental steps of data transformations.
> 
> Guess it depends on your definition of "solving a problem".
> I see it as defining the problem, which usually requires a
> certain amount of abstraction, developing an algorithm which
> provides a solution (more abstraction), and finally implementing
> the algorithm in the machine (coding/programming).  I think you
> are placing too much emphasis on the last step.

Perhaps, but CS has gone so abstraction-happy that I think
it has wandered away from the basic tenet that computers
are supposed to *do* something.

> > So what?  You can always learn languages, but you only have
> > one shot at teaching someone to think like a programmer.
> 
> You're loosing me here..  Why only one shot?

Because I've found that people tend to stick with the first
[dare I use the word] paradigm that they are introduced to.
Everything else they learn will be compared against the first
thing they learn, and if the first thing they learn is the
step-by-step nature of the computer through a simple assembly
language (they don't have to start with the sophisticated RISC
chip on the planet), then they'll always have that safe, simple
place to go back to when trying to understand more sophisticated
concepts.

> > What gets missed in all this is that *computers are simple*!
> 
> Some (perhaps only a few) computers are simple.  While computes are
> designed around some basic (simple) concepts, start adding caches, 
> pipeline architectures, memory paging schemes, multiple register
> sets, any of the various DMA capabilities or co-processor's which
> provide for some parallelism, etc., and things get very complicated
> very quick.  There aren't many computers made these days that don't
> employ most (and many more) of the above features.  To effectively
> program in assembly one must fully understand these architectural
> issues, and to me that is one of the advantages of teaching a HLL
> first as it allows the student to study and understand the development
> and implementation of algorithms without being distracted by all the
> low level architectural details.

But all the caching, etc are all performance optimizations.  That
is irrelevent to the fact that they're still "load and execute"
cycles in the simple case.

You don't *have* to start them out with all this.  They can learn
just as well on a simple processor.

> > Look at ol' Darin; if he didn't have enough brainpower left
> > to focus on the algorithm at hand, what was he being confused
> > by?
> 
> Perhaps an attractive girl in the class :-). 
> 
> > I think it was by all the language and abstraction, 
> 
> I always though abstraction was used to avoid confusion by
> elevating away from all the little low level details.  Let's 
> you see the forest for the trees kind of thing.

That is the theory, and that theory *has failed* based on my
testing of newly graduated students.  What I find interesting
is that nobody is defending that newly graduated students are
well prepared to program real programs.  They just plain aren't.

IMO languages such as C are far, far more difficult than
assembly language.  We've had a few posts during this discussion
from people (including myself) who learned assembly early on as
their primary language.  They all felt that assembly was what
crystallized the concept of computers in their mind.  This
shouldn't be that hard to believe; there aren't that many
fundamental instructions in assembly, and nothing about the
computer's nature is hidden (or abstracted) away.

I'm not sure how this thought that "assembly is hard" came
about.  The only thing I can think of that so few people learn
assembly nowadays that they think it is all black magic, and
anything with mystery is assumed to be hard.

> > which is not what programming is.
> 
> Right, studing algorithms is not programming.  Programming is
> implementing algorithms.

Agreed.  If I had my way, I would give students one very
simple program a day to implement in assembly.  One after
another, just to get them used to implementing an algorithm
and *watching it run*.  That latter is the most important when
learning about the procedural nature of the computer.  The
most important thing they can learn is that there is nothing
"magic" about the computer, it's all take an instruction,
execute it, and move on.

> >  If he had been given a solid
> > foundation of the simple nature of the computer, I think he would
> > always have a "comfort zone" he could return to whenever he
> > didn't understand something, because it's *always* implemented
> > in the fundamental terms.
> 
> Sorry, I just don't follow this reasoning.

Well, look at OOP.  This is another thing that has developed
a mythical high level of difficult.  What is OOP?  It is the
most simple concept on earth:

Non-OOP: Execute operation on area of memory.
OOP:     Execute operation abstractly bound to an area of
         memory (AKA object).

That is *all* of it.  All of the rest of it (inheritence, etc)
are all extensions of the fundamental theory of OOP that we are
assigning a set of operations to an area of memory.  Now
granted, this could be considered an implementation of OOP,
but so what?  The point is that it's simple to understand, and
from there you can on to the "grand generalizations".

Now, how is OOP taught now?  As far as I can see, they shower
a dump-truck full of terms onto the students, and give them
a whirlwind of abstractions.  If they would focus on the
reality of the implementation, we would see far fewer confused
students.

-- Tim Behrendsen (tim@airshields.com)