Assembly vs. Python
jim.simmons at walgreens.com
Wed Feb 4 18:16:17 EST 2009
I've been amused reading these comments about Knuth and Assembler vs.
Python. Back in 1978 at Western Illinois University I encountered
Knuth's books in the school library. He not only used Assembly in his
examples, he used a made up version of Assembly language for a machine
that did not exist. He said that most programmers end up learning more
than one kind of assembly language, so learning one more was no big
deal. Even in 1978 that sounded questionable! I did study BAL at WIU.
The first class I took I barely passed with a D. The teacher had no
clue how to teach BAL, but fortunately the textbook was good enough to
learn from without him. I decided that D or no D I did understand BAL,
so I went on to learn COBOL and I took another BAL course after that
where I got a B. I've written a fair amount of BAL professionally.
I've also done Turbo C, COBOL, Java, and other languages.
I only learned Python for OLPC, although I was exposed to it when I
configured Freevo. I like the language well enough and performance
hasn't been much of an issue for me. It's comparable to Java, probably
better for most things. It is certainly more understandable for complex
apps than COBOL or BAL ever were, and I think its a decent language for
a new programmer, especially one who is not interested in programming as
a career but just has a problem he needs to solve. Maybe he's studying
trigonometry or linear programming or statistics and he needs to crunch
some numbers to understand things better. Why not write a Python program?
If blinding speed on the XO was all that mattered we'd still be using
Turbo C on top of MS-DOS. We'd be bypassing the BIOS and moving data
directly to video memory. We'd write TSR programs to get some of the
benefits of multitasking without the overhead of a multitasking OS.
We'd have to know the difference between expanded and extended memory.
I have done all of those things, but I wouldn't wish them on anyone else.
At Walgreens many years ago we had a batch program in BAL that took 4
hours to run because it used its own swap file. I modified this program
using a COBOL subprogram to replace the swap file with arrays in
memory. The finished program took 10 minutes to run after that. Would
it have run faster still if I used BAL for the subprogram? Not much,
but it would have been *much* harder to write. The program was slow
because it spent so much time waiting for disk reads and writes, not
because it was running unnecessary machine instructions. All programs
wait at the same speed.
I would agree that whatever performance issues there are on the XO, we
probably can't blame too many of them on Python.
>>> For teaching, remember that Knuth uses assembly. C is an awful
>>> lot closer to that than Python, and isn't the XO about teaching?
>> Ha, ahat age group is Knuth teaching assembly to?? What level of math and
>> science skills are they expected to have?
> Assuming we start with no programming skills...
> Assembly has a reputation for being "hard", but this is
> far from the truth. It is large assembly projects that are
> hard to understand. For tiny things, assembly is even
> easier than C. What you see is what you get, exactly.
> Python has lots of magic. With assembly, everything
> is there for you to see.
More information about the Devel