Programmingis something thats an inherently fun affair. It lets you be the masterof your creative energies. It lets you become god for some time, Itlets you create. And that gives a programmer immense pleasure andsatisfaction. Just like sex. And then there is debugging. The darkerand uglier side of programming. Where you have to deal with themistakes that you so blissfully overlooked when you were busy creating.The pleasure comes back as a pain to haunt you. Again, just like sex.

Ihave been busy hacking on a feed reader in lisp these days and tryingto fix an XML parser into accepting something as brain dead as 'CDATA 'and the XML parser was actively fighting back. Just like a wounded dogyou are sotrying to help but still bites you back. It was more of a debugging(pains) session than a pure programming (pleasure) session. I was at mywits ends, unable to fix the damn thing. My code to my eyes lookedright and my compiler was conking out. It was like trying to fight aninvisible enemy. The worst bugs to fight are those that are not in yourcode, but in someone else's code. But this was not even that. It waswhat happens when induvidually correct programs are coupled and theirinteractions create a semantic monstrocity that its hard for even thecreator to understand, let alone anyone else. This particular problemis what happens when you take an untested XML parser, SLIME, Emacs and SBCLand put them into a mixer and then try to figure out whats wrong withyour parser. It turned out that SLIME uses a limited form of encodingcalled iso-8859-1 whereas most web transfers and the CDATA in RSS feeds are in UTF-8type encoding. You think thats hard to figure out? - You bet it is! Theproblem is the other characters apart from your original ascii aremostly invisible. And hence vrey hard to even insert your timely printdebug statements to observe what actually is going on.

Onething that definitely helps when you are debugging is taking a break.In fact, from my experience taking a well deserved break definitelyspeeds up your following debugging session. But in spite of this, likemost other programmers I was caught in 'fixing' the bug that I waslosing concentration and was basically getting frustrated. I knew I hadto take the break, but I used each and every excuse to convince myselfnot to. But fortunately the bell rang and it was the TV repairman. Thiswas when I started my journey across the line of magic.Now let me explain what the magic line actually is - every programmerhas to learn one of the most important concepts in programming and isoften exposed to it at the earliest stages in any good computer sciencecourse and thats abstraction . Abstraction is just a formal way oftelling that you should stop bothering about the nitty gritty detailsand get to work on your problem. The level of abstraction depends onthe nature of the problem and the programmer. In fact abstractions areevery where and people use it all the time. Files are abstractions overthe various device dependent process for storing bits onto storagedevices. Your operating system is an abstraction over the raw hardwareand your processor and so on. One characteristic of a good abstractionis that its as 'not' leakyas possible. Infact most good abstractions totally make invisible theunderlying implementation. Files are good examples of those types ofabstraction. And in general, us programmers should not bother aboutwhat lies beneath our abstractions otherwise we are doomed to the samefate as the web surfers of the pre-google era - information overload.But since most abstractions inevitabily turn out to be leaky there isno way but to break the law of abstractions. The question is all aboutwhere to draw the line. The line beyond which you trust yourabstractions unqestionably that you don't even bother to know how itsworking. And this particular line is what I call the magic line.

Programming in Lisp had recently raised my line from what it was when Iwas writing C code, and sometimes its just nice to find your roots.Comming back to the TV repairman, our TV had been busted recently dueto the monsoonal rains and erratic electricity and no TV was somethingthat was totally unacceptable to my 'tv-serial' addicted parents. Sothey called in a funny looking guy to fix it. Usually I hate doinghouse work, and espescially helping out TV repairmen and all that andto be honest I din't take this guy too seriously in the begining, butthere was something that just din't fit in about this guy. So hestarted to work on our TV and then I saw this lookon his face. I have rarely seen this except on a few close friends ofmine. The last time I saw it on a guy's face the guy was working onimplementing minimax trees and alpha-beta search. Did I say implement?Let me make a small correction. He was trying to debugit. This look, which I had considered the secret trade-mark of uselitist geeks, was exactly what I saw on the repairman's face. This wasobviously an expert at work. And the best way to learn anything is tolearn by watching the experts do it, and this time I had to cross mymagic line to the realm of bits and piecies and all your fancyelectronics - the resistors, the capacitors, the transistors and whatnot. And very soon it dawned on me that he was in a similar predicamentas I was just before he had rung the bell. Fixing a system where thebug is in the connections rather than the components themselves.

Andhe debugged the system beautifully. My words don't do justice to theskill of this expert, but anyhow here is my feeble attempt to describeit. As usual he started with a problematic system. There was no outputon the CRT, no sound from the speakers nothing. For all practicalpurposes the system was dead. He started out by pulling out all plugs,and all the other things that hold the tv together, he was taking apartthe system into its individual pieces and took a good look at the wholesystem. the main PCB, the CRT connectivity boards and the audiosubsystem. I guess he took a moment to understand the complexity in itswhole. Then he went about looking at all the usual sources of problemsin TV system, and incredibly his first guess was right. It was thepower subsystem that had been totally busted. He took out the old powersystem and replaced it with a new one. And walah ! - the system stilldidn't work (got you there didn't I?). Now this is where the wholeprocess gets close to what real debugging is like. He was poking aroundwith a multimeter and various points and once he found something wassuspicious he tried to unsolder and try the system again. He did thisfor various components, unsoldering and soldering them back. At somepoint he even inserted new components (a resistor to be precise) tocircumvent a diode that he was sure of being broken. And with the diodehe added a couple of buffers and a weird three legged device which Iwon't name as I won't risk my knowledge (or lack thereof) ofelectronics being exposed here. Seems so close to all those gartituousprint statements that I litter in my code when debugging. And once hegot a reading on the multimeter I saw the "Aha!" look on his face.Seems like he had finally nailed the bug and in fact he did. Hereplaced the faulty component (which I presume is a diode), with a newcomponent and the system sprang to life albeit with a grainy pictureand almost indecipherable sound. Now, there is a difference betweenreal debugging and his method. We programmers might have let it go andleft it for version 2.0, but this guy didn't stop. He twiddled withvarious controls, some resistors changing one component for anotheruntil the picture was clear. Next he worked on the sound system and hegot it working in no time. It took him one painstaking hour to fix ourbroken TV form dilapidated old hag to "good as new"condition and he was working for minimum wage. Now thats India for you.I paid the equivalent of what a boy would get for one hour's work ofdelivering pizza in the US to watch an obvious expert at work andwithout the complaining too!!.

Signing Off,
Vishnu Vyas.