|Assignment: #BrianKernighan||Due: 09/23/02018||Points: 2|
Near the end of the 20th century, Brian Kernighan (logname bwk) prepared some notes for computing students at Stanford University. The notes are related to his book The Practice of Programming. bwk kindly allowed me to post his notes to my website.
Read bwk's notes and answer some questions.
Read: bwk's Q&A with Stanford UniversityStanford: What do think are the best methods for learning or teaching C programming? bwk: There's no way to learn programming in any language except by writing programs. I think it's easiest when you alternate between trying things and reading books and manuals. As I suggested, in some ways, learning to program is like learning to communicate in a foreign language. You can study Japanese endlessly, for example, but until you try to communicate with someone who speaks only Japanese, you won't learn much. You need the feedback about what works and what doesn't. The same is true about programming: there's no substitute for trying to make something work because that teaches you what works and what doesn't. Teaching, on the other hand, requires a real effort to place yourself in the shoes of the person trying to learn a brand new and often quite unintuitive skill. It helps to have a variety of ways to explain any particular programming idea or language construct, since different ones will help different people. It's easy to forget how hard it once was to get started. It also helps to have a carefully graduated sequence of examples that reveal new things just at the time that the person learning starts to ask the questions. It's often a bad idea to try to explain too much at the beginning; some of the best teaching is a careful sequence of half-truths that gradually reveal more of the whole story. Stanford: How do you classify bugs, and what are some of the strategies you recommend in your book for testing and debugging programs? bwk: There's a whole chapter on debugging, and another one on testing, so this is a pretty abbreviated answer for a couple of big topics. New programmers make careless mistakes, like walking off the start or end of an array, or mis-matching types in function calls, or (in C) using the wrong conversion characters in printf and scanf. Fortunately, these are usually easy to catch because they cause very distinctive failures. Fortunately, they are easy to eliminate as you write the code in the first place, by "boundary condition checking", which amounts to thinking about what can go wrong as you write. Bugs usually appear in the code you wrote most recently or that you started to test, so that's a good place to concentrate your efforts. As bugs get more complicated or subtle, more is called for. One effective approach is to "divide and conquer", attempting to eliminate part of the data or part of the program so that the bug is localized in a smaller and smaller region. There's also often a pattern to a bug; the "numerology" of failing inputs or faulty output is often a very big clue to what's going on. The hardest bugs are those where your mental model of what's going on is just wrong, so you can't see the problem at all. For these, we like to take a break, read a listing, explain the problem to someone else, use a debugger. All of these help us to see the problem a different way, and that's often enough to pin it down. Testing comes after debugging, when you think a program is right and you're trying to make sure. Many of the same things matter, especially being systematic and thorough. One thing that we like to stress is to use the machine to help with testing, much more than most people do. Machines are really good at doing voluminous testing and checking the answers; it's important to enlist their services. Stanford: You've programmed in many languages. What strategies do you employ to understand and remember the syntax of a programming language? For example, many beginners to C confuse the assignment operator (=), which is the equal sign, with the double equal sign (==) used for comparing two integer values. What techniques do you recommend to comprehend and recall the syntax of a programming language more effectively? bwk: I find it easiest to learn a new language from well-chosen examples that do some task that's close to what I want to do. I copy an example, adapt it to what I need, then expand my knowledge as the specific application drives it. I poke around in enough different languages that after a while they start to blur, and it takes a while to shift gears when I shift from one to another, especially if they are not ones like C that I learned long ago. It's good to have good compilers that complain about suspicious constructions as well as illegal ones; languages with strong type systems like C++ and Java are helpful here. More generally, there's nothing like writing a lot of code, preferably good code that other people use. Next best, and much less frequently done, is reading a lot of good code to see how other people write. Finally, breadth of experience helps -- each new problem, new language, new tool, and new system helps a programmer get better, and creates links with whatever you know already. Stanford: What advice do you have for students interested in computer science research and teaching? bwk: Do something that you like to do; if it isn't fun most of the time, you're in the wrong field. Learn as many different areas as you can, since often the most interesting computing arises when computers are applied where they haven't been previously. Learn to speak and write well, especially to people who are not experts in your fields, since those are skills that will serve you well no matter where your specific technical activities take you.
Submit: Answers to the following questions. bwk believes that best way to learn programming is to do what?  Testing or debugging? According to bwk what comes first?  Finish bwk's quote... "More generally, there's nothing like writing a lot of code, preferably good code that other people use. Next best, and much less frequently done, is..."  According to bwk, what skills will serve us well no matter where our specific technical activities take us?
CS.Princeton.edu::The Practice of Programming [by bwk and Rob "Commander" Pike]
You're not required to watch bwk in The Factory of Ideas: Working at Bell Labs - Computerphile, but I would.