What is different with Python ?

[Andrea Griffini]

On Tue, 14 Jun 2005 16:40:42 -0500, Mike Meyer <mwm at mired.org> wrote:

>Um, you didn't do the translation right.

Whoops.

So you know assembler, no other possibility as it's such
a complex language that unless someone already knows it
(and in the specific architecture) what i wrote is pure
line noise.

You studied it after python, I suppose.

>> 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 assembler details are simply more explicit. Unfortunately
with computers you just cannot avoid details, otherwise your
programs will suck bad. When I wrote in an high level language
or even a very high level one the details are understood even
if I'm not writing down them. After a while a programmer will
even be able to put them at a subconscius level and e.g. by
just looking at O(N^2) code that could be easily rewritten as
O(N) or O(1) a little bell will ring in you brain telling you
"this is ugly". But you cannot know if something is O(1) or
O(N) or O(N^2) unless you know some detail. If you don't like
details then programming is just not the correct field.

In math when I write down the derivative of a complex function
it doesn't mean I don't know what is the definition of
derivative in terms of limits, or what are the conditions
that must be met to be able to write down it. Yet I'm not
writing them every time (some times I'll write them when they're
not obvious, but when they're obvious it doesn't mean I'm not
considering them or, worse, I don't know or understand them).
If you don't really understand what a derivative is and when
it makes sense and when it doesn't, your equations risk
to be good just for after dinner pub jokes.

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

Just more explicit. So explicit that it can become boring.
After a while certain operations are so clearly understood
that you are able to write a program to do them to save us
some time (and to preventing us to get bored).
That's what HLL are for... to save you from doing, not to
save you from understanding. What the HLL is doing for you
is something that you don't do in the details, but that you
better not taking without any critic or even comphrension,
because, and this is anoter very important point, *YOU*
will be responsible of the final result, and the final
result will depend a lot (almost totally, actually) on
what you call details.
Just to make another example programming without the faintes
idea of what's happening is not really different from using
those "wizards" to generate a plethora of code you do not
understand. When the wizard will also take the *responsability*
for that code we may discuss it again, but until then if
you don't understand what the wizard does and you just
accept its code then you're not going to go very far.
Just resaying it if you don't understand why it works
there is just no possibility at all you'll understand
why it doesn't work.

Think that "a = b + c" in computes the sum of two real
numbers and your program will fail (expecting, how fool,
that adding ten times 0.1 you get 1.0) and you'll spend
some time wondering why the plane crashed... your code
was "correct" after all.

>For instance, whitesmith had a z80 assembler that let you write:
>
>          a = b + c
>
>and it would generate the proper instructions via direct
>translation.

To use that I've to understand what registers will be
affected and how ugly (i.e. inefficient) the code could
get. Programmin in assembler using such an high level
feature without knowing those little details woul be
just suicidal.

>Also, you can only claim that being closer to the chip is "simpler"
>because you haven't dealt with a sufficiently complicated chip yet.

True that one should start with something reasonable.
I started with 6502 and just love its semplicity. Now
at work we've boards based on DSP TMSC320 and, believe
me, that assembler gives new meanings to the word ugly.

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

Yeah. And you must know which is which. Otherwise you'll
write programs that just do not give the expected result
(because the user killed them earlier).

>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 think that a *decent* programmer must understand if the
code being written is roughly O(n) or O(n^2). Without
at least that the possibility of writing useful code,
excluding may be toy projects, is a flat zero.
Looking that information later may be just "too" late,
because the wrong data structure has already been used
and nothing can be done (except rewriting everything).

>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 is that unless you really internalized what
that means you'll forget about it. Don't ask me why,
but it happens. Our mind works that way. You just cannot
live with a jillion of unrelated details you cannot place
in a scheme. It doesn't work. One would do thousand times
the effort that would be done using instead a model able
to justify those details.

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

Except that the marketing will continuosly shift what
you application is supposed to do. And this is good, and
essential. This is "building". Sometimes marketing will
change specifications *before* you complete the very
first prototype. For complex enough projects this is more
the rule than the exception. In the nice "the pragmatic
programmer" book (IIRC) is told that there's no known
complex project in which specification was changed less
than four times before the first release... and the only
time they were changed just three times it was when the
guy running with the fourth variations was hit by a
lightning on the street.

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

What you will obtain is that people that will build
wrong models. Omitting details, if they can really
affect the result, is not a good idea.
This is completely different from omitting details
that no one without a 3km particle accellerator
could detect to kids in 4th grade school.

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

That's exactly because they don't know the details of
any of the languages you used. Someone knowing the
details would be curious to know *how* "del v[0]"
is implemented in python. Actually it could be changed
easily in an O(1) operation with just a little slowdown
in element access (still O(1) but with a bigger constant).
This is a compromise that has not been accepted and
this very fact is important to know if you plan to
use python seriously.

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

Sorry, but I really don't agree that big O is a "detail"
that could be ignored. Only bubble-and-arrow powerpoint
gurus could think that; I'm not in that crew.
Ignore those little details and your program will be
just as good as ones that don't even compile.

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

Sorting is abstract ?

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

I'll blame my bad english for understanding that you
said that abelian groups should be taught before
relative numbers (somehow I crazily thought the point
of discussion was what's the correct order of learning
how to program), that TAOCP is too abstract (a book
where every single code listing is in assembler!)
and that big-o when programming is a detail that can
be safely ignored (good luck, IMO you'll need hell a
lot of it).

Andrea