What is different with Python ?

[Andrea Griffini]

On Sun, 12 Jun 2005 19:53:29 -0500, Mike Meyer <mwm at mired.org> wrote:

>Andrea Griffini <agriff at tin.it> writes:
>> On Sat, 11 Jun 2005 21:52:57 -0400, Peter Hansen <peter at engcorp.com>
>> wrote:
>> Also concrete->abstract shows a clear path; starting
>> in the middle and looking both up (to higher
>> abstractions) and down (to the implementation
>> details) is IMO much more confusing.
>
>So you're arguing that a CS major should start by learning electronics
>fundamentals, how gates work, and how to design hardware(*)? Because
>that's what the concrete level *really* is. Start anywhere above that,
>and you wind up needing to look both ways.

Not really. Long ago I've drawn a line that starts at
software. I think you can be a reasonable programmer
even without the knowledge about how to design hardware.
I do not think you can be a reasonable programmer if
you never saw assembler.

>Admittedly, at some level the details simply stop mattering. But where
>that level is depends on what level you're working on. Writing Python,
>I really don't need to understand the behavior of hardware
>gates. Writing horizontal microcode, I'm totally f*cked if I don't
>understand the behavior of hardware gates.

But you better understand how, more or less, your
computer or language works, otherwise your code will
be needless thousand times slower and will require
thousand times more memory than is necessary.
Look a recent thread where someone was asking why
python was so slow (and the code contained stuff
like "if x in range(low, high):" in an inner loop
that was itself pointless).

>In short, you're going to start in the middle.

I've got "bad" news for you. You're always in the
middle :-D. Apparently it looks like this is a
constant in our universe. Even counting (i.e.
1, 2, 3, ...) is not the "start" of math (you
can go at "lower" levels).
Actually I think this is a "nice" property of our
universe, but discussing this would bring the
discussion a bit OT.

>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).

But if you need to introduce them, then IMO is
way better doing it *first*, because that is the
way that our brain works.

You cannot build on loosely placed bricks.

>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.

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 ...).

Andrea