On Sat, 8 Dec 2007, pd-list-request@iem.at wrote:
On Fri, 7 Dec 2007, Hans-Christoph Steiner wrote:
As for Pd vs. C, there was a time in the not-so-distant past where programmers thought that compilers were horribly inefficient, and that they were only really good for prototyping things. Then you'd code things for real in assembly. That lasted well into the 80's.
It even lasted well into the 90's, but it depends for what. The 80's had plenty ofy apps use a blend of asm and C-or-Pascal, while in the 90's it became limited to really needy applications (games, demoscene, etc). The amount of asm code still being written is shrinking but still somewhat present. For example, devel_0_39 has asm code in it.
I once wrote a final exam for a mandatory course in Assembly Language programming in the late 1990s where the most important question was to determine what a block of Motorola 68k assembly code was doing. People were just pulling their hair out! (mine never grew back!). It turned out the code was doing basically nothing. That was one of the best CS courses I ever took.
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.
The questiion today might be whether auto-vectorising compilers are as good as hand-unrolled loops (I highly doubt it). The point is well-taken however: we should use high-level tools for the rapidity, expressivity and clarity they offer us in realising our particular ideas. It never hurts, nonetheless, to understand what that code is actually doing on the processor and in memory etc.
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.
cheers, Andrew
"[...] the introduction of the blackboard has had more impact on classroom education than any innovation in technology since, including the introduction of cheap paper or the introduction of the internet and personal computers"
Bill Buxton
On Dec 8, 2007 4:38 PM, Andrew Brouse brouse@music.mcgill.ca 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.
I like that. It sounds strangely fulfilling. It's like a deaf composer writing a symphony. Cribbage was invented by a poet. Sometimes they surprise us! William Rowan Hamilton, on the other hand, was said to enjoy writing poems, and was encouraged to stick with math...
-Chuckk
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
morning all,
On 2007-12-08 21:08:29, Mathieu Bouchard matju@artengine.ca appears to have written:
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.
In fact, i recently spent about 2 days chasing a bug in some old code of mine that i only managed to track down by looking at the literal memory positions, and if I had had a spiffy blinky pseudo-analogue StarTrek kind of data display, I probably would have seen the bug immediately, whereas it took me the said 2 days using ddd.... oh well ;-)
marmosets, Bryan (philosopher-turned-hacker)
On Sat, 8 Dec 2007, Bryan Jurish wrote:
In fact, i recently spent about 2 days chasing a bug in some old code of mine that i only managed to track down by looking at the literal memory positions, and if I had had a spiffy blinky pseudo-analogue StarTrek kind of data display, I probably would have seen the bug immediately, whereas it took me the said 2 days using ddd.... oh well ;-)
I would like to hear more about this bug.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Andrew Brouse -
Bryan Jurish -
Chuckk Hubbard -
Mathieu Bouchard