The Southsider - Programming on Paper

[RSS Bot]

I have always preferred programming on paper for some reason. I think this is because I didn't have a computer at home when I first learned to program. The only computer available to me for a long time was in my school, and its usage was strictly controlled and very limited. As a result, I used to write out my programs by hand in exercise books, and spend my precious computer time typing-in these listings and attempting to debug them. At the end of the session, I would print out what I had done and then spend the time away from the computer working out the bugs. These programs seldom worked, but they were a great learning experience.

 

This is still the way that I prefer to work, though I don't generally write out the initial program listings by hand anymore. Instead, I type up a rough version of the code directly onto the computer, and print out a copy that I then study for optimisations and bugs. I think the main problem that I have with programming directly onto the computer is that you only get to see a small part of the code at once. With paper, you can spread out all of the different parts on your desk and get a real picture of how it all fits together. There are various IDEs and folding editors that attempt to address this problem, but I prefer to use a standard text editor (xemacs) and printer paper.

 

The best kind of paper listings were the old fanfold kind, where each listing was essentially a continuous sheet of paper. You could spead it out on the floor and follow the control flow up and down the paper. When I first started at University, the lab had an old chain printer which printed out listings on 160-column fanfold paper. Actually I think it was a dot-matrix printer, but it was still called a chain printer as this is what it had replaced. This printer was managed by a supervisor who would put each listing into a pidgeon hole for later collection. The advantage of the 160 column format was that you had a huge amount of space next to your listings in which to make notes, draw diagrams, and document your code. Unfortunately this printer and the supervisor were replaced by a laser printer around 10 years ago now. I still think that I would be a better programmer if I had this printer, but these days I make do with 2-up laser printed listings.

 

 

The point of this nostalgic trip is that for the last week or so I have been carrying around a listing of my Juno First kernel. Every time I have had a few spare minutes, usually on the bus or train, I have taken out the latest listing and started tightening the code. Occasionally I will spot a neat trick, or solve a difficult timing problem, which generally causes a big smile to appear on my face, and probably causes those around to question my sanity! At times like this my girlfriend usually makes comments about geeks and the reason they have trouble finding women

 

Anyway, I think that the Juno First Kernel is now nearly complete, though obviously this is just the first step of the game itself. The latest version is attached to this message (the source code is in the ZIP archive). This code fixes many of the bugs in the previous version, and includes a variant of Manuels flickersort routine for displaying multiple sprites within the same horizontal region. The flicker will be much less noticable in the actual game as the sprites will be moving and should only occasionally overlap. Also, it will look better on an actual TV (use the phosphor option in Z26 or Stella to see this). The alien sprites do not move yet, but this is my next task. I still haven't come up with a solution to the HMOVE problem outlined previously, though I might just live with the lines as they are not too distracting. Overall I am very pleased with the way that the game is turning out so far ...

 

Chris

juno4.binjuno4.zip

 

http://www.atariage.com/forums/index.php?a...&showentry=1344