Assignment: #BrianKernighan Due: 03/02/02019 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 University
Stanford: 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
     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
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
Submit: Answers to the following questions.
[0] bwk believes that best way to learn programming is to do what?

[1] Testing or debugging? According to bwk what comes first?
[2] 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..."

[3] According to bwk, what skills will serve us well no matter 
    where our specific technical activities take us?

Extra Edification 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.