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. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel