Andrea Griffini said:
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.
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.
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.
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).
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.
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.
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.
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).
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.
Yeah. Remember, I'm talking about m.e., chem.e, etc. engineering students
here. Not software engineers or any other type of cs types.
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
