On Mon, 13 Jun 2005 21:33:50 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote:
>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.
>> Are you genuinely saying that abelian groups are
>> easier to understand than relative integers ?
>
>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.
>> I suppose that over there who is caught reading
>> TAOCP is slammed in jail ...
>
>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
--
http://mail.python.org/mailman/listinfo/python-list
