After Scott confessed to still programming in BASIC, I had a good time recalling how I first learned to program. My first interaction with a computer and “programming” was through LOGO, that cute little program for programming a little turtle to draw graphics. Drawing cool and crazy pictures was fun! But I don’t really remember learning that as “programming” so much as it was learning geometry (I was in the second grade at the time) and I certainly recall sharing the computer (probably not very sharefully.) But the real way I learned to program was not through LOGO but through debuging!
In the (g)olden days of my halycon youth you could buy computer magazines which had in the back of the magazine lines of BASIC to enter into your computer in order to play a game. Now I was all about playing games, and when we obtained at TRS-80 Color Computer, my parents only bought one game cartridge, so in order to play more games we had to type them into the computer. A group of neighborhood kids would get together and do this. One person would read and the other would type and others which check to make sure what was being typed was correct. Even with these precautions, however, we would, invariably make a mistake. So when you made a mistake you had to go looking through the program to find out where we made an error. Eventually, at first, we’d just go through the whole program line by line. But as we got more sophisticated we began to understand how, when the game died while doing X it meant that the program was probably at Y when this happened and so we began to understand what all that funny stuff we were typing in was. Eventually we got very good at debugging the code we typed into the computer. Indeed, in a very real sense, I learned to debug before I learned to code! (Years later I can still recall the astonishment of a high school teacher who watched me debug a program in a fairly rapid time 🙂 )
So here is a question. Sure we could teach students to program using your favorite language FAVLANG, but what if it was possible for us to teach debuging before we taught programming. What if the structure of the introduction to programming was centered around finding and fixing bugs. I mean, after reading Dreaming in Code, where the book ends with thousands of bugs left unfixed, I can only imagine that good debugging skills are important. Maybe even as important as coding skills? Just a thought. But even if this is not the way to go, how could you teach debugging before you taught programming? Now that’s fun to think about.
O brave new quantum world!
The folk wisdom is that programming is actually *easier* than debugging. This leads to the interesting conclusion that, if you write a program by coding to the limit of your abilities, you are not skilled enough to debug it.
But it’s interesting to try and correlate the idea of debugging before programming with the fact that for many programmers, their first job is maintaining and fixing an existing body of code…
Up to an o(1) term, programmming is debugging. 🙂
I remember that the AP CS test had lots of programs to debug, so I had to learn how to do it despite not knowing the language they were written in (at that time, Pascal).
Speaking of which, it looks like my “commment” above contained a syntax error. Mmm, mmm good!
Tracing/debugging statements, as they say over at ars, for the win. I’ve had to start adding verbosity switches to my code to turn off gigantic blocks of console output. On the other had, I’ve fixed problems that the guy who started this project didn’t even know he had in his code…
If I recall, wasn’t LOGO created as both a research tool (i.e., enable childhood development researchers to study how the little brats pick up geometry and how best to teach it to them) as well a geometry teaching tool? Double-duty tool.
I started with a few write(*,*)’I am here’ type statements to help figger out where the ole girl was goin belly up. Course I reckon the real trick is knowing where to PUT those kinds of things.
Single stepping is useful, again more useful if you have a debugger that lets you do that AND you know about where to look.
Weirdest error I ever got was in a Fortran compiler for PC’s, adding a write statement made the error go away. Erase the write statement it comes back….. Turns out that the command before which opened a new file was taking a value input from the keyboard and setting it to zero. Adding a write statement of the ‘I am here’ variety stopped that from happening.
We got a different compiler the next day. The poor student was just going nuts, as in debugging, you tend to have faith that YOU are wrong, and that the compiler is not doing anything funny. Of course the error messages tend to reinforce that–
‘Error 399821- disaster: you must have done something really stupid you ass you’
On a mainframe back in the old days, it took us a while to figure out that when ‘diaster error messages were issued’, and you looked up what to do and it said check the line voltage was OK before calling IBM for service, it really meant you overwrote an array boundary. The ole IBM jus din like that ‘tall!
Debugging other people’s code is hard enough when you do know the language. But imagine debugging someone else’s entry to the Obfuscated C Code Contest (http://www.ioccc.org/)…
What they don’t usually teach is that after a bug is fixed and the program works, there is often an underlying root cause behind it that still exists, i.e. a design flaw that makes certain types of bugs more likely. Usually people are so happy to see their program working, they neglect to analyze bugs any further after they seem to be gone.
What Perry described is a classic Heisenbug…i.e. a bug that goes away when you try to measure it. These types of bugs are very common in embedded environments. One way to combat them is to leave debugging code in at all times, even in production systems. A few dollars in extra RAM for debug symbols and logging often pay for themselves several hundred times over.
Related, but not exactly what you’re asking about, is the practice of Test Driven Design.
But it’s not a beginner’s way of working. Beginners’ programs are all exploration, all flailing cowboy extravaganzas. The TDD practitioners I know are essentially Zen archers; they code as if they know nothing of the rest of the program.
And the result is often pure beauty….