Assembly vs. Python

[James Simmons]

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.

James Simmons

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