What is different with Python ?

[Mike Meyer]

Andrea Griffini <agriff at tin.it> writes:

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

Nope. I don't think I've learned any assemblers since I learned Python.
Of course, I'd been writing code for 20 years before I learned Python.

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

I've never argued otherwise.

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

Especially if b and c aren't floats. I've always used "real" as a
mathematical term, since they had it first. Computers don't deal with
reals.

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

The assembler lets you specify which registers to use. You either name
them in place of variables, or variables that are labels for the
registers.

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

Actually, it isn't always true in Python. What if v is a dictionary (in
which case the description is wrong), or a class that maps an SQL table's
row id's to objects holding the data for that row? In either case, the
statement will be O(1).

You do need to know which is which.

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

I don't think those two statements contradict each other. A decent
programmer will know the O() of the code they write - or where to
find that information. And they'll check it beforehand.

The advantage of using an HLL is that rewriting everything to try
other data structures (after all, the constants that O() notation
ignore matter as well, so that the fastest O() notation may not be
the fastest solution for the problem in hand).

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

Again, you're generalizing from "your mind" to "everyone's mind". My
experience indicates that's not true for me. For instance, I find that
learning a typical assembler involves learning a jillion unrelated
details - because it's not at all uncommon for the opcode mnemonics to
be seemingly random strings of characters. Or random words.
Architectures with irregular register usages seem to have little rhyme
or reason behind those irregularities (though I did avoid those
architectures, so may have missed the reason(s) behind some of them).
Even on architectures with symmetric register usage, register usage
conventions are pretty much arbitrary.

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

Except that those specification changes rarely change the top-level
object/method/whatever. At least, all the ones I dealt with wound
up changing things that were in the middle of the design. The easiest
ones were the ones that were anticipated, and so the changes were all
in data, and not in code.

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

Well, the "result" largely depends on why the project is being built.
If you're doing exploratory programming, the "result" is a better
understanding of the objects in the problem domain. The details that
affect that result are radically different from the details that affect
the result if you're building a production application, which is again
different from the details that affect the result if you're teaching
people how to program.

Again, the critical thing is teaching students what details matter, and
which ones don't.
> >>>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.

Actually, you don't need to know *anything* about the compromise if you
plan on using python seriously. You do need to know that "del v[0]" on
list is O(n).

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

I've never argued that you should treat O() behavior as a detail that
can be ignored. I've argued that it's an implementation detail.  As
such, you worry about it when you do the implmentation. If you need to
delete from both ends of an ordered set of objects, you can't use a
python list and get reasonable performance.

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

Yeah. Remember, I'm talking about m.e., chem.e, etc. engineering students
here. Not software engineers or any other type of cs types.

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

If you wish. But since you posted your list of misconceptions about
what I said, I'm going to correct them.

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

Again, I never said that. I said *I* understood them better than
relative numbers, because *you* asked whether or not I did. That
says *nothing* about how I think they should be taught. I'm not so
egotistical as to think that every body thinks they same way I do.

> that TAOCP is too abstract (a book
> where every single code listing is in assembler!)

I said it was too abstract for a specific group - one that deals
with concrete problems. In FORTRAN, usually.

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

No, I said it was an implementation detail. I've maintained all along
that good programmers need to know those details.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.