What is different with Python ?

[Andrea Griffini]

But this same logic applies to why you want to teach abstract things
before concrete things. Since you like concrete examples, let's look
at a simple one:

a = b + c
....
In a very
few languages (BCPL being one), this means exactly one thing. But
until you know the underlying architecture, you still can't say how
many operations it is.

That's exactly why

mov eax, a
add eax, b
mov c, eax

or, even more concrete and like what I learned first

lda $300
clc
adc $301
sta $302

is simpler to understand. Yes... for some time I even
worked with the computer in machine language without
using a symbolic assembler; I unfortunately paid a
price to it and now I've a few neurons burnt for
memorizing irrelevant details like that the above
code is (IIRC) AD 00 03 18 6D 01 03 8D 02 03... but
I think it wasn't a complete waste of energy.

Writing programs in assembler takes longer exactly beacuse
the language is *simpler*. Assembler has less implicit
semantic because it's closer to the limited brain of our
stupid silicon friend.
Programming in assembler also really teaches (deeply
to your soul) who is the terrible "undefined behaviour"
monster you'll meet when programming in C.

Anything beyond the abstract statement "a gets the result
of adding b to c" is wasted on them.

But saying for example that

del v[0]

just "removes the first element from v" you will end up
with programs that do that in a stupid way, actually you
can easily get unusable programs, and programmers that
go around saying "python is slow" for that reason.

It's true that in some cases, it's easier to remember the
implementation details and work out the cost than to
remember the cost directly.

I'm saying something different i.e. that unless you
understand (you have a least a rough picture, you
don't really need all the details... but there must
be no "magic" in it) how the standard C++ library is
implemented there is no way at all you have any
chance to remember all the quite important implications
for your program. It's just IMO impossible to memorize
such a big quantity of unrelated quirks.
Things like for example big O, but also undefined
behaviours risks like having iterators invalidated
when you add an element to a vector.

Yup. Then again, my formal training is as a mathematician. I *like*
working in the problem space - with the abstact. I tend to design
top-down.

The problem with designing top down is that when
building (for example applications) there is no top.
I found this very simple and very powerful rationalization
about my gut feeling on building complex systems in
Meyer's "Object Oriented Software Construction" and
it's one to which I completely agree. Top down is a
nice way for *explaining* what you already know, or
for *RE*-writing, not for creating or for learning.

IMO no one can really think that teaching abelian
groups to kids first and only later introducing
them to relative numbers is the correct path.
Human brain simply doesn't work like that.

You are saying this, but I think here it's more your
love for discussion than really what you think.

The same is true of programmers who started with concrete details on a
different platform - unless they relearn those details for that
platform.

No. This is another very important key point.
Humans are quite smart at finding general rules
from details, you don't have to burn your hand on
every possible fire. Unfortunately sometimes there
is the OPPOSITE problem... we infer general rules
that do not apply from just too few observations.

The critical things a good programmer knows about those
concrete details is which ones are platform specific and which aren't,
and how to go about learning those details when they go to a new
platform.

I never observed this problem. You really did ?

That is such not a problem that Knuth for example
decided to use an assembler language for a processor
that doesn't even exist (!).

If you confuse the issue by teaching the concrete details at the same
time as you're teaching programming, you get people who can't make
that distinction. Such people regularly show up with horrid Python
code because they were used to the details for C, or Java, or
whatever.

Writing C code with python is indeed a problem that
is present. But I think this is a minor price to pay.
Also it's something that with time and experience
it will be fixed.

Those taught the concrete method would never have been exposed to
anything so abstract.

Hmmm; TACOP is The Art Of Computer Programming, what
is the abstract part of it ? The code presented is
only MIX assembler. There are math prerequisites for
a few parts, but I think no one could call it "abstract"
material (no one that actually spent some time reading
it, that is).

Actually, it's a natural place to teach the details of that kind of
thing. An OS has to deal with allocating a number of different kinds
of memory, with radically different behaviors and constraints.

hehehe... and a program like TeX instead doesn't even
need to allocate memory. Pairing this with that teaching
abelian groups first to kids (why not fiber spaces then ?)
and that TAOCP is too "abstract" tells me that apparently
you're someone that likes to talk just for talking, or
that your religion doesn't allow you to type in smileys.

Andrea

 

[Andrea Griffini]

The best race driver doesn't necessarily know the most about their car's
engine. The best baseball pitcher isn't the one who should be teaching
a class in physics and aerodynamics. Yes, both can improve their
abilities by learning about the fundamentals of engines, aerodynamics,
etc., but they aren't "bad" at what they do if they do not know the
underlying principles operating.

And when you've a problem writing your software who is
your mechanic ? Who are you calling on the phone for help ?

Andrea

 

[Andrea Griffini]

In programming you're often given a result ("an inventory
management system") and you're looking for a solution which
combines models of how people, computers, and the given domain work.

Yes, at this higher level I agree. But not on how
a computer works. One thing is applied math, another
thing is math itself. When you're trying to find a solution
of a problem it's often the fine art of compromise.

Science also has its purely observational domains.

I agree that "applied CS" is one of them (I mean the
art of helping people by using computers). But not
about the language or explaining how computers work.
I know that looking at the art of installing (or
uninstalling!) windows applications seems that
this is a completely irrational world where no rule
indeed exists... but this is just an illusion; there
are clear rules behind it and, believe it or not, we
know *all* of them.

Andrea

 

[Michele Simionato]

This is investigating. Programming is more similar to building
instead (with a very few exceptions). CS is not like physics or
chemistry or biology where you're given a result (the world)
and you're looking for the unknown laws. In programming *we*
are building the world. This is a huge fundamental difference!

It looks like you do not have a background in Physics research.
We *do* build the world!

Michele Simionato

 

[Andreas Kostyrka]

However I do not think that going this low (that's is still
IMO just a bit below assembler and still quite higher than
HW design) is very common for programmers.

Well, at least one University (Technical University Vienna) does it
this way. Or did it at least when I passed the courses

Caching is indeed very important, and sometimes the difference
is huge. I think anyway that it's probably something confined
in a few cases (processing big quantity of data with simple
algorithms, e.g. pixel processing).
It's also a field where if you care about the details the
specific architecture plays an important role, and anything
you learned about say the Pentium III could be completely
pointless on the Pentium 4.

Nope. While it's certainly true that it's different from architecture
to architecture, you need to learn the different types of caches,
etc. so that one can quickly crasp the architecture currently in use.

Except by general locality rules I would say that everything
else should be checked only if necessary and on a case-by-case
approach. I'm way a too timid investor to throw in neurons
on such a volatile knowledge.

It's not volatile knowledge. Knowledge what CPU uses what cache
organisation is volatile and wasted knowledge. Knowledge what kinds
of caches are common is quite useful

Easy Question:
You've got 2 programs that are running in parallel.
Without basic knowledge about caches, the naive answer would be that
the programs will probably run double time. The reality is different.

Current trend is that you don't even need to do a
clear design. Just draw some bubbles and arrows on
a white board with a marker, throw in some buzzword
and presto! you basically completed the new killing app.

Well, somehow I'm happy that it is this way. That ensures enough work
for me, because with this approach somebody will call in the fire
department when it doesn't work anymore
Or the startup goes belly up.

Real design and implementation are minutiae for bozos.

Even the mighty python is incredibly less productive
than powerpoint ;-)


This is a key issue. If you've the basis firmly placed
most of what follows will be obvious. If someone tells
you that inserting an element at the beginning of an array
is O(n) in the number of elements then you think "uh... ok,
sounds reasonable", if they say that it's amortized O(1)
instead then you say "wow..." and after some thinking
"ok, i think i understand how it could be done" and in
both cases you'll remember it. It's a clear *concrete* fact
that I think just cannot be forgot.

Believe it can
But that's the idea why certain courses forced us to implement at
least the most important data structures by ourselves.

Because looking at it in a book is so much less intensive than doing
it

Andreas

 

[Andrew Dalke]

...
Easy Question:
You've got 2 programs that are running in parallel.
Without basic knowledge about caches, the naive answer would be that
the programs will probably run double time. The reality is different.

Okay, I admit I'm making a comment almost solely to have
Andrea, Andreas and Andrew in the same thread.

I've seen superlinear and sublinear performance for this.
Superlinear when the problem fits into 2x cache size but not
1x cache size and is nicely decomposable, and sublinear when
the data doesn't have good processor affinity.

Do I get an A for Andre.*?

Andrew
(e-mail address removed)

 

[Peter Maas]

> On Mon, 13 Jun 2005 13:35:00 +0200, Peter Maas <[email protected]>
> wrote:
>
>
>
>
> Depends if you wanna build or investigate.

Learning is investigating. By top-down I mean high level (cat,
dog, table sun, sky) to low level (molecules, atoms, fields ...).
And to know the lowest levels is not strictly necessary for
programming. I have seen good programmers who didn't know about
logic gates.

Hehehe... a large python string is a nice idea for modelling
memory. This shows clearly what I mean with that without firm
understanding of the basis you can do pretty huge and stupid
mistakes (hint: strings are immutable in python... ever
wondered what does that fancy word mean ?)

Don't nail me down on that stupid string, I know it's immutable but
didn't think about it when answering your post. Take <some mutable
replacement> instead.

 

[Roy Smith]

High and low tides aren't caused by the moon.

They're not???

 

[Magnus Lycka]

Philosophically I disagree. Biology and physics depends on
models of how the world works. The success of a model depends
on how well it describes and predicts what's observed.

Programming too has its model of how things work; you've mentioned
algorithmic complexity and there are models of how humans
interact with computers. The success depends in part on how
well it fits with those models.

And this is different from building? I don't disagree with the
other things you say, but I think Andrea is right here, although
I might have said construction or engineering rather than building.

To program is to build. While scientists do build and create things,
the ultimate goal of science is understanding. Scientists build
so that they can learn. Programmers and engineers learn so that
they can build.

There is a big overlap between science and engineering. I hope we
can embrace each other's perspectives and see common goals, but
I also think the distinction is useful.

It seems to me that a lot of so called science is really more
focused on achieving a certain goal than to understand the
world. I think Richard Feynman said something like "disciplines
with the word 'science' in their names aren't", and I feel that
he had a point.

I find the idea of computer science a bit odd. Fields like civil
engineering or electronics rely solidly on science and the laws
of nature. We must, or else our gadgets fail. We work closely
with field such as physics and chemistry, but we're not scientists,
because we learn to build, not vice versa. Our goal is problem
solving and solutions, not knowledge and understanding.

As you said:
"The success of a model depends on how well it describes and
predicts what's observed."
It's quite obvious that this is as true when we build houses,
airplanes or bridges, and when we build programs. Right?

It seems to me that *real* computer scientists are very rare. I
suspect that the label computer scientist comes from a lack of
a better word. Erh, computer engineering without engineering?
What do we call this? I don't mean to offend anyone. I have all
respect for both the education and the students of the discipline
called computer science, and I think it's vital that there is a
foundation of science and mathematics in this field, but most
practitioners aren't scientists any more than engineers are
scientists. Ok, my degree is "Master of Science" in English,
but my academic discipline is electronic engineering, not
electronic science--because the goal with the education is to
be able to use scientific knowledge to solve practical problems,
which is, by definition, what engineers do.

Oh well, I guess it's a bit late to try to rename the Computer
Science discipline now.

 

[Peter Hansen]

They're not???

Probably he's referring to something like this, from Wikipedia, which
emphasizes that while tides are caused primarily by the moon, the height
of the high and low tides involves the sun as well:

"The height of the high and low tides (relative to mean sea level) also
varies. Around new and full Moon, the tidal forces due to the Sun
reinforce those of the Moon, due to the syzygy found at those times -
both the Sun and the Moon are 'pulling the water in the same direction.'"

(If I'm right about this, then the statement is still wrong, since even
without the sun there would be high and low tides, just not of the
magnitude we have now.)

-Peter

 

[Peter Maas]

Why in the world is that way "natural"? I could see how biology
could start from molecular biology - how hereditary and self-regulating
systems work at the simplest level - and using that as the scaffolding
to describe how cells and multi-cellular systems work.

Yes, but what did you notice first when you were a child - plants
or molecules? I imagine little Andrew in the kindergarten fascinated
by molecules and suddenly shouting "Hey, we can make plants out of
these little thingies!"

 

[Bill Mill]

And this is different from building? I don't disagree with the
other things you say, but I think Andrea is right here, although
I might have said construction or engineering rather than building.

To program is to build. While scientists do build and create things,
the ultimate goal of science is understanding. Scientists build
so that they can learn. Programmers and engineers learn so that
they can build.

It seems to me that *real* computer scientists are very rare.

I'd like to say that I think that they do, in fact, exist, and that
it's a group which should grow and begin to do things more like their
biological counterparts. Why? Because, as systems get more complex,
they must be studied like biological systems.

I spent a while in college studying latent semantic indexing (LSI)
[1], which is an algorithm that can be used to group things for
clustering, searching, and other uses. It is known *to* be effective
in some circumstances, but nobody (at least when I was studying it ~2
years ago) knows *why* it is effective.

With the help of my professor, I was helping to try and determine that
*why*. We had a hypothesis [2], and my job was basically to build
experiments to test our hypothesis. First, I built a framework to
perform LSI on arbitrary documents (in python of course, let's keep it
on topic , then I started to do experiments on different bodies of
text and different variations of our hypothesis. I kept a lab journal
detailing what I had changed between experiments, some of which took
days to run.

I believe that there are at least a fair number of computer scientists
working like this, and I believe that they need to recognize
themselves as a separate discipline with separate rules. I'd like to
see them open source their code when they publish papers as a matter
of standard procedure. I'd like to see them publish reports much more
like biologists than like mathematicians. In this way, I think that
the scientific computer scientists could begin to become more like
real scientists than like engineers.

Just my 2 cents.

Peace
Bill Mill

[1] http://javelina.cet.middlebury.edu/lsa/out/lsa_definition.htm
[2] http://llimllib.f2o.org/files/lsi_paper.pdf

 

[Michele Simionato]

Magnus Lycka:

While scientists do build and create things,
the ultimate goal of science is understanding. Scientists build
so that they can learn. Programmers and engineers learn so that
they can build.

Well put! I am going to add this to my list of citations

Michele Simionato

 

[Scott David Daniels]

It seems to me that *real* computer scientists are very rare.

I suspect the analysis of algorithms people are among that group.
It is intriguing to me when you can determine a lower and upper
bound on the time for the best solution to a problem relatively
independent of the particular solution.

Oh well, I guess it's a bit late to try to rename the Computer
Science discipline now.

The best I've heard is "Informatics" -- I have a vague impression
that this is a more European name for the field.

--Scott David Daniels
(e-mail address removed)

 

[Claudio Grondi]

High and low tides aren't caused by the moon.

They're not???

I suppose, that the trick here is to state,
that not the moon, but the earth rotation relative
to the moon causes it, so putting the moon at
cause is considered wrong, because its existance
alone were not the cause for high and low tides
in case both rotations were at synch. It is probably
a much more complicated thingy where also the
sun and maybe even the planets must be
considered if going into the details, but this is
another chapter.

I experienced once a girl who pointing me to the
visible straight beams from earth to sky one can see
as result of sunlight coming through the clouds
said: "look, along this visible beams the water from
the lake wents upwards and builds the clouds".
She was very convinced it's true, because she
learned it at school, so I had no chance to go the
details explaining, that there is no need for the
visible straight light beams coming through the
holes in the clouds for it.

I can imagine, that many believe that the
moon is orbiting each day around the earth
even if they know, that earth rotates around
its own axle and around the sun. Its not that
important for them to ask for details, so that
is the mechanism how the "lies" are born -
caused by lack of the necessity or the laziness
to achieve deeper understanding.

Claudio

 

[Magnus Lycka]

I suspect the analysis of algorithms people are among that group.
It is intriguing to me when you can determine a lower and upper
bound on the time for the best solution to a problem relatively
independent of the particular solution.

On the other hand, you could argue that algorithms and mathematics
are branches of philosophy rather than science. Very useful for
science, just as many other parts of philosophy, but algorithms
are really abstract concepts that stand on their own, regardless
of the physical world. But perhaps that distinction is fuzzy. After
all, all philosophical theories rest on observations of the world,
just as scientific theories. Hm...we're really far off topic now.

 

[Magnus Lycka]

Learning is investigating. By top-down I mean high level (cat,
dog, table sun, sky) to low level (molecules, atoms, fields ...).

Aha. So you must learn cosmology first then. I don't think so.

I don't know if you really think that you learn things top
down, but I doubt that you do. I know I don't. It's very
rare that I have a good understanding of the overall workings
of a system before I start to learn details. As I learn little
details here and there, my understanding of the entire system
is gradually growing and changing. Sometimes, a minor detail
might completely change my overall picture of a system.

In my experience, software designs developed by people who
lack a good hands-on understanding of the details in a software
system rarely work. We can't know the "top" properly unless
we know a lot about the "bottom".

Do you think children learn to speak by arriving at some
kind of general understanding of grammer before they learn
individual words? People typically don't learn things top
down, and I think there are good reasons for that.

Regarding software development, Bertrand Meyer said something
like this: "Top-down design doesn't work, because real software
systems have no top." His view of Object-Oriented development
is that it's a process where we go from that which is known
to us, to that which is (still) unknown. It might go up or
down, but we start with what we know, and gradually expand our
understanding into new territories armed with what we have
learnt so far.

Analysis or decomposition is only half of logical thinking.
Synthesis or composing parts into entire systems are just
as important, and we can't just do one part first, the other
after, and then be done with it.

We are all different intellectually, both genetically and by
training and education. Some people find it easier to grasp
theories, and others need more tangible examples. For each
person, the useful approach will probably depend on the previous
experience in that particular field, or in related areas.

And to know the lowest levels is not strictly necessary for
programming. I have seen good programmers who didn't know about
logic gates.

People might be "good programmers" in some sense, but they will
make mistakes if they don't understand the underlying mechanisms.
This doesn't mean that you need to understand all details down
to the quantum mechanics level, but if you see programing as a
purely "logical" activity, without regards for the technical
implementation, you will run into plenty of problems.

One classical trap is to fail to understand how floating point
numbers are represented in computers. Other common problems among
people who lack a technical understanding for computers is that
they fail to see how and why their solutions use up different
amounts of resources, be it memory, CPU time or whatever. I've
also often seen confusion because people fail to understand the
distinction between other logical and an internal representations,
such as cunfusion over the fact that a date which looks like
eight digits don't use eight bytes in the database, and
frustration over the fact that the database doesn't allow you
to store 0000-00-00 in a date field.

It's just the same as with cars. You can be a fair driver without
knowing anything about mechanics, but the more you know about how
the car works from a mechanical and physical point of view, the
easier it will be to understand why it behaves the way it does,
and the less likely you are to make mistakes when unusual things
happen.

Just as you can learn how cars behave from experience, or from
advice from others with experience, without understanding the
underlying mechanisms, you can learn programming this way. We
have learned things that way for thousands of years. I don't
think it's optimal though.

Robert Pirsig's "Zen and the Art of Motorcycle Maintenance"
covers this subject.

But we all have to start somewhere, and it's never to late to
learn something new. Curiosity and an open mind often means
more than formal education. Some people with a very "good"
education seem to believe that the thing they've learnt is
all that matters, and they will fall into other traps. There
is always another perspective that might give us a new insight.

 

[Andrew Dalke]

Yes, but what did you notice first when you were a child - plants
or molecules? I imagine little Andrew in the kindergarten fascinated
by molecules and suddenly shouting "Hey, we can make plants out of
these little thingies!"

One of the first science books that really intrigued me
was a book on stars I read in 1st or 2nd grade.

As I mentioned, I didn't understand the science of biology
until I was in college.

Teaching kids is different than teaching adults. The
latter can often take bigger steps and start from a
sound understanding of logical and intuitive thought.
"Simple" for an adult is different than for a child.

Andrew
(e-mail address removed)

 

[Andrea Griffini]

It looks like you do not have a background in Physics research.
We *do* build the world!

Michele Simionato

Wow... I always get surprises from physics. For example I
thought that no one could drop confutability requirement
for a theory in an experimental science... I mean that I
always agreed with the logic principle that unless you
tell me an experiment whose result could be a confutation
of your theory or otherwise you're not saying anything
really interesting.
In other words if there is no means by which the theory
could be proved wrong by an experiment then that theory
is just babbling without any added content.
A friend of mine however told me that this principle that
I thought was fundamental for talking about science has
indeed been sacrified to get unification. I was told that
in physics there are current theories for which there
is no hypotetical experiment that could prove them wrong...
(superstrings may be ? it was a name like that but I
don't really remember).
To me looks like e.g. saying that objects are moved around
by invisible beings with long beards and tennis shoes
and that those spirits like to move them under apparent
laws we know because they're having a lot of fun fooling
us. However every now and then they move things a bit
differently just to watch at our surprised faces while we
try to see where is the problem in our measuring instrument.

My temptation is to react for this dropping of such a logical
requirement with a good laugh... what could be the result
of a theory that refuses basic logic ? On a second thought
however laughing at strange physics theories is not a good
idea. Especially if you live in Hiroshima.

Andrea

 

[Mike Meyer]

... n>>In a very

That's exactly why

mov eax, a
add eax, b
mov c, eax

Um, you didn't do the translation right.

or, even more concrete and like what I learned first

lda $300
clc
adc $301
sta $302

is simpler to understand.

No, it isn't - because you have to worry about more details. In
particular, when programming in an HLL the compiler will take care of
allocating storage for the variables. In assembler, the programmer has
to deal with it. These extra details make the code more complicated.

Writing programs in assembler takes longer exactly beacuse
the language is *simpler*. Assembler has less implicit
semantic because it's closer to the limited brain of our
stupid silicon friend.

You're right, but you have the wrong reasons. There were studies done
during the 70s/80s that showed that debugged LOC from programmers is
independent of the language being written. Assembler takes longer to
write not because it's simpler, but because it takes more LOC to do
the same operations.

You can avoid that problem - to a degree - if you use an assembler
that eschews the standard assembler syntax for something more
abstract. For instance, whitesmith had a z80 assembler that let you write:

a = b + c

and it would generate the proper instructions via direct
translation. This didn't reduce the LOC to the level of C, but it
makes a significant dent in it.

Also, you can only claim that being closer to the chip is "simpler"
because you haven't dealt with a sufficiently complicated chip
yet. Try writing code where you have to worry about gate settling
times or pipeline stalls, and then tell me whether you think it's
"simpler" than dealing with an HLL.

Programming in assembler also really teaches (deeply
to your soul) who is the terrible "undefined behaviour"
monster you'll meet when programming in C.

Anything beyond the abstract statement "a gets the result
of adding b to c" is wasted on them.

But saying for example that

del v[0]

just "removes the first element from v" you will end up
with programs that do that in a stupid way, actually you
can easily get unusable programs, and programmers that
go around saying "python is slow" for that reason.

That's an implementation detail. It's true in Python, but isn't
necessarily true in other languages. Yes, good programmers need to
know that information - or, as I said before, they need to know that
they need to know that information, and where to get it.

I'm saying something different i.e. that unless you
understand (you have a least a rough picture, you
don't really need all the details... but there must
be no "magic" in it) how the standard C++ library is
implemented there is no way at all you have any
chance to remember all the quite important implications
for your program. It's just IMO impossible to memorize
such a big quantity of unrelated quirks.
Things like for example big O, but also undefined
behaviours risks like having iterators invalidated
when you add an element to a vector.

That may well be true of the standard C++ library - I don't write
it. But it certainly doesn't appear to be true of, for instance,
Python internals. I've never seen someone explain why, for instance,
string addition is O(n^2) beyond the very abstract "it creates a new
string with each addition". No concrete details at all.

The problem with designing top down is that when
building (for example applications) there is no top.

This is simply false. The top of an application is the
application-level object

I found this very simple and very powerful rationalization
about my gut feeling on building complex systems in
Meyer's "Object Oriented Software Construction" and
it's one to which I completely agree. Top down is a
nice way for *explaining* what you already know, or
for *RE*-writing, not for creating or for learning.

I also like OOSC - because it makes the abstract type system a part of
the language. The approach Meyer takes emphasis the abstract.

You haven't stated how you think complex systems should be built, and
I think we took different lessons away from Meyer, so you'll have to
state it explicitly.

I agree - you don't generally build systems top-down. But building is
not designing. The common alternative to top-down design - bottom-up
design - makes the possibility of a semantic disconnect when you reach
the top to likely.

IMO no one can really think that teaching abelian
groups to kids first and only later introducing
them to relative numbers is the correct path.
Human brain simply doesn't work like that.

You didn't ask how it should be taught - you asked which I found more
natural. Numbers are an abstract concept, and can be taught as such.

You are saying this, but I think here it's more your
love for discussion than really what you think.

Actually, I think it's a terminology problem. Or maybe a problem
defining the levels.

No. This is another very important key point.
Humans are quite smart at finding general rules
from details, you don't have to burn your hand on
every possible fire. Unfortunately sometimes there
is the OPPOSITE problem... we infer general rules
that do not apply from just too few observations.

Your opposite problem is avoided by not teaching the details until
they are needed, and making sure you teach that those are
implementation details, so they student knows not to draw such
conclusions from them.

I never observed this problem. You really did ?

As mentioned, you see it all the time in c.l.python. People come from
other languages, and try to write Python as if the rules for that
other language apply.

Writing C code with python is indeed a problem that
is present. But I think this is a minor price to pay.
Also it's something that with time and experience
it will be fixed.

It can be fixed from the start by teaching the student the difference
between abstract programming concepts and implementation details.

Hmmm; TACOP is The Art Of Computer Programming, what
is the abstract part of it ? The code presented is
only MIX assembler. There are math prerequisites for
a few parts, but I think no one could call it "abstract"
material (no one that actually spent some time reading
it, that is).

It tackled abstract problems like "sorting". The students I'm talking
about never dealt with anything that abstract.

hehehe... and a program like TeX instead doesn't even
need to allocate memory.

You're confusing "using a facility" with "building a facility". Yes,
TeX needs to allocate memory. You don't need to know anything about
the insides of a memory allocator to allocate memory. You can write an
application like TeX without having to write a memory allocator. You
can't write an OS without having to write *several* memory allocators.
Are you going to claim that the right way to learn about memory
allocators is by looking at uses of them, or by looking at
implementations of them?

Pairing this with that teaching
abelian groups first to kids (why not fiber spaces then ?)
and that TAOCP is too "abstract" tells me that apparently
you're someone that likes to talk just for talking, or
that your religion doesn't allow you to type in smileys.

Now you're resorting to straw men and name-calling. That's an
indication that you no longer have any real points.

<mike