Over the last year I have been interested in developing my programming / coding, to get to the point where I can be more confident of sharing my code with other people. And also to be able to contribute to general purpose numerical / statistical software.
As part of this effort I have dipped in to The Art of Computer Programming (TAOCP) by Donald Knuth. The cover says "this multivolume work is widely recognized as the definitive description of classical computer science." American Scientist listed it as one of the 12 top physical-science monographs of the 20th century alongside monographs by the likes of Albert Einstein, Bertrand Russell, von Neumann and Wiener - http://web.mnstate.edu/schwartz/centurylist2.html.
I am sure there are many other books that cover similar material at a more introductory level, but I find something exciting about going back the source and reading an author who was personally involved in fundamental discoveries and developments.
There are also probably more modern accounts of computer programming that better reflect more recent innovations. Knuth himself encourages readers of TAOCP to look at his more recent work on Literate Programming. But I also think it is worth dwelling on things that have proven to be useful to a wide range of people over an extended period of time.
I have Volume 1 in the Third Edition of TAOCP, published in 1997, which is already prehistoric in some senses - it is before Google was founded (1998) and way before Facebook was launched (2004). However parts of the book date a lot further back than that - Knuth's advice on how to write complex and lengthy programs was mostly written in 1964!
Here is a summary of that advice (p191-193 of TAOCP Volume 1),
Step 1 : develop a rough sketch of the main top-level program. Make a list of subroutines / functions that you will need to write. "It usually pays to extend the generality of each subroutine a little."
Step 2 : create a first working program starting from the lowest-level subroutines and working up to the main program.
Step 3 : Re-examine your code starting from the main program and working down studying for each subroutine all the calls made on it. Refactor your program and subroutines.
Knuth suggests that at the end of Step 3 "it is often a good idea to scrap everything and start again". He goes on to say "some of the best computer programs ever written owe much of the success to the fact that all the work was unintentionally lost, at about this stage, and the authors had to begin again." - quite a thought-provoking statement!
Step 4 : check that when you execute your program, everything is taking place as expected, i.e., debugging. "Many of today's best programmers will devote nearly half their programs to facilitating the debugging process in the other half; the first half, which usually consists of fairly straightforward routines that display relevant information in a readable format, will eventually be thrown away, but the net result is a surprising gain in productivity."
I don't know whether today's best programmers still do this. I know some pretty good programmers and have been surprised how much effort they devoted to the kind of activity that Knuth is describing. Personally I now rely quite a lot on the debugger in Visual Studio, and (indirectly) on compilers to give me most of the debugging information I need for not much effort.
As part of this effort I have dipped in to The Art of Computer Programming (TAOCP) by Donald Knuth. The cover says "this multivolume work is widely recognized as the definitive description of classical computer science." American Scientist listed it as one of the 12 top physical-science monographs of the 20th century alongside monographs by the likes of Albert Einstein, Bertrand Russell, von Neumann and Wiener - http://web.mnstate.edu/schwartz/centurylist2.html.
I am sure there are many other books that cover similar material at a more introductory level, but I find something exciting about going back the source and reading an author who was personally involved in fundamental discoveries and developments.
There are also probably more modern accounts of computer programming that better reflect more recent innovations. Knuth himself encourages readers of TAOCP to look at his more recent work on Literate Programming. But I also think it is worth dwelling on things that have proven to be useful to a wide range of people over an extended period of time.
I have Volume 1 in the Third Edition of TAOCP, published in 1997, which is already prehistoric in some senses - it is before Google was founded (1998) and way before Facebook was launched (2004). However parts of the book date a lot further back than that - Knuth's advice on how to write complex and lengthy programs was mostly written in 1964!
Here is a summary of that advice (p191-193 of TAOCP Volume 1),
Step 1 : develop a rough sketch of the main top-level program. Make a list of subroutines / functions that you will need to write. "It usually pays to extend the generality of each subroutine a little."
Step 2 : create a first working program starting from the lowest-level subroutines and working up to the main program.
Step 3 : Re-examine your code starting from the main program and working down studying for each subroutine all the calls made on it. Refactor your program and subroutines.
Knuth suggests that at the end of Step 3 "it is often a good idea to scrap everything and start again". He goes on to say "some of the best computer programs ever written owe much of the success to the fact that all the work was unintentionally lost, at about this stage, and the authors had to begin again." - quite a thought-provoking statement!
Step 4 : check that when you execute your program, everything is taking place as expected, i.e., debugging. "Many of today's best programmers will devote nearly half their programs to facilitating the debugging process in the other half; the first half, which usually consists of fairly straightforward routines that display relevant information in a readable format, will eventually be thrown away, but the net result is a surprising gain in productivity."
I don't know whether today's best programmers still do this. I know some pretty good programmers and have been surprised how much effort they devoted to the kind of activity that Knuth is describing. Personally I now rely quite a lot on the debugger in Visual Studio, and (indirectly) on compilers to give me most of the debugging information I need for not much effort.
