On Sat, 8 Dec 2007, Andrew Brouse wrote:
An old-school hacker (poet turned progammer, classic!) once told me that he used to debug his programmes (on mainframes, with not even 1M of memory) by actually just watching a display of activity in all memory locations. After a while, he just subconsciously internalised what was going on and managed to debug the code.
This can't possibly be used nowadays, but there are better ways of visualising code. Because C values are typed, you can (to a certain extent), view the data topologically, by following pointers, which get drawn like arrows that are connecting boxes containing data. This is what DDD does (it's a GDB wrapper). This is more useful because the positions in memory are somewhat meaningless, because the connectedness of the data happens because the program follows pointers rather than using any arithmetic other than for a single array or struct.
On a fundamental level, any code we run is just changing patterns of electrons bouncing about on a wafer of impure silicon. Thus, when our high-level tools fail us or don't give the expected result, we sometimes have to dig down a little deeper. Maybe there is a chunk of code, like that block of 68k assembly, which is just churning electrons around, basicaly doing nothing.
On a different fundamental level, any code we run is for ourselves, it's for communicating us back a result. Many possible programs fulfill the requirements that we have in writing a program. Trying out several strategies giving the same results in different times helps us figure out efficient solutions. If you have enough RAM, there's always a long enough list that will be sorted faster with a quicksort in BASH than with a bubblesort in assembly language. (And it doesn't even take that much RAM).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada