[PD] code and compilers

[Mathieu Bouchard]

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