Andrea Griffini <[EMAIL PROTECTED]> writes:
>>In short, you're going to start in the middle.
>
> I've got "bad" news for you. You're always in the
> middle :-D.
That's what I just said.
>>Is it really justified to confuse them all
>>by introducing what are really extraneous details early on?
>
> I simply say that you will not able to avoid
> introducing them. If they're going to write software
> those are not "details" that you'll be able to hide
> behind a nice and perfect virtual world (this is much
> less true about bus cycles... at least for many
> programmers).
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.
> But if you need to introduce them, then IMO is
> way better doing it *first*, because that is the
> way that our brain works.
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.
>>You've stated your opinion. Personally, I agree with Abelson, Sussman
>>and Sussman, whose text "The Structure and Interpretation of Computer
>>Programs" was the standard text at one of the premiere engineering
>>schools in the world, and is widely regarded as a classic in the
>>field: they decided to start with the abstract, and deal with concrete
>>issues - like assignment(!) later.
>
> Sure. I know that many think that starting from
> higher levels is better. However no explanation is
> given about *why* this should work better, and I
> didn't even see objective studies about how this
> approach pays off. This is of course not a field
> that I've investigated a lot.
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.
> What I know is that every single competent programmer
> I know (not many... just *EVERY SINGLE ONE*) started
> by placing firmly concrete concepts first, and then
> moved on higher abstractions (for example like
> structured programming, OOP, functional languages ...).
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.
<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
