Andrea Griffini <[EMAIL PROTECTED]> writes:
> On Mon, 13 Jun 2005 01:54:53 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote:
>>Andrea Griffini <[EMAIL PROTECTED]> writes:
>>I disagree. If you're going to make competent programmers of them,
>>they need to know the *cost* of those details, but not necessarily the
>>actual details themselves. It's enough to know that malloc may lead to
>>a context switch; you don't need to know how malloc actually works.
>
> Unless those words have a real meaning for you then
> you'll forget them... I've seen this a jillion times
> with C++. Unless you really understand how an
> std::vector is implemented you'll end up doing stupid
> things like looping erasing the first element.
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
Now, in a modern OO language (like Python) this can invoke arbitrary
bits of code. In a 70s-era structured language (like C), this will
mean one of a fixed set of things, but you still don't know enough to
say how many abstract operations this statement involves. 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.
All of which is so much noise to someone who's just starting
programming. Anything beyond the abstract statement "a gets the result
of adding b to c" is wasted on them. Learning about programming at
that level is complicated enough. After they've mastered that, you can
teach them the concrete details that determine what actually happens,
and how much it costs: things like method lookup (Python), namespace
lookups (Python), operator overloading (C), implicit type conversions
(C and Python), integer overflow (BCPL and C), and floating point
behavior in general (C and Python), register vs. stack architectures,
RISC vs. CISC, caching, and other such things.
> Actually I cannot blame someone for forgetting that
> insert at the beginning is O(n) and at the end is
> amortized O(1) if s/he never understood how a vector
> is implemented and was told to just learn those two
> little facts. Those little facts are obvious and
> can easily be remembered only if you've a conceptual
> model where they fit. If they're just random notions
> then the very day after the C++ exam you'll forget
> everything.
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. That's also true for abstract things as well.
>>That's the way *your* brain works. I'd not agree that mine works that
>>way. Then again, proving either statement is an interesting
>>proposition.
>
> 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 explanation has been stated a number of times: because you're
>>letting them worry about learning how to program, before they worry
>>about learning how to evaluate the cost of a particular
>>construct. Especially since the latter depends on implementation
>>details, which are liable to have to be relearned for every different
>>platform.
>
> You'll get programmers that do not understand how
> their programs work. This unavoidably will be a show
> stopper when their programs will not work (and it's
> when, not if...).
The same is true of programmers who started with concrete details on a
different platform - unless they relearn those details for that
platform. 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.
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.
>>I don't normally ask how people learned to program, but I will observe
>>that most of the CS courses I've been involved with put aside concrete
>>issues - like memory management - until later in the course, when it
>>was taught as part of an OS internals course. The exception would be
>>those who were learning programming as part of an engineering (but not
>>software engineering) curriculum. The least readable code examples
>>almost uniformly came from the latter group.
>
> 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.
> Placing memory allocation in the "OS internals" course
> is very funny. Let's hope you're just joking.
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. As
such, it provides reasons to examine a number of different memory
allocation strategies and their behaviors, and to evaluate them in
light of those varying behaviors and constraints.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
