[clue] debuging programs

Tue May 17 11:08:46 MDT 2011

Good comments, Chris.  In my experience (a career as a software 
engineer, designer & developer, plus lots of experience teaching 
programming languages to engineers and laypeople), the hardest thing for 
the newcomer to learn is "how to `think like' a computer (or program)."

This means simultaneously grasping the big picture, the macro-structure 
(the design -- What's this program s'posed to actually do or accomplish 
-- What does it "compute"?) *and* the minute details, the microcosm of 
"Is this instruction correct?  Does it fit in with its predecessor(s) 
and successor(s) to accomplish just the right thing (logic) at this point?"

A good interactive debugger and/or IDE can really help with the latter 
(the microcosm), but doesn't help much with the former (macrocosm). 
Talking and communicating with other, experienced coders (things like 
code walkthroughs, informal critiques and coding style reviews, etc.) 
help with the macro, but not so much with the micro...

For the new programmer, just getting syntax right, in whatever language 
you're learning (and Python's a good place to start -- so is Ruby) is 
the first big deal.  Later, as statement and structural syntax issues 
start "feeling like old hat," the newbie can start learning to grasp the 
larger issues of semantics, things like how does this function/routine 
work and hang together overall, how to best decompose the overall 
program logic into a system of subroutines (functions, etc.), and to 
start seeing the common idioms, vernacular and design patterns which 
experienced programmers tend to take for granted.

It seems like a lot to learn, Louis, but the good news is that you don't 
have to (cannot) learn it all at once.  Seems like, from what questions 
you've posted and the other responses thus far, that you're on the right 
track.

Probably the best additional advice that I can offer, in addition to 
what's already been said, and what you're already doing, is for you to 
READ LOTS OF GOOD CODE IN THE LANGUAGE YOU'RE LEARNING, STUFF WRITTEN BY 
OTHER EXPERIENCED PROGRAMMERS.  In software, we learn that "originality" 
isn't always the best idea -- plagiarism (with appropriate credits, of 
course) is the norm -- don't reinvent the wheel.  Learn from the folks 
who have already written Good Code, and then copy and adapt it for your 
own needs.  I think that's one of the fastest paths to learning and mastery.

Of course, it also helps to read lots of good books on the subject, 
especially on your language of choice.  O'Reilly, Pragmatic and Manning 
are among the good-to-great publishers in these topic areas, so there's 
a wealth of good books to own and grok.  Hope this helps...

best regards,
   -- Lorin

On 05/17/2011 07:30 AM, chris fedde wrote:
> Programming is hard. People are just not very good at being perfect. 
>  And software has to be perfect in some sense to work properly.  This is 
> what makes programming hard.  So the best plan is to work in a tight 
> think, code, test loop. There are plenty of techniques that help you 
> isolate trouble too.   The first technique everyone figures out is 
> diagnostic print statements.  Second is usually learning how to use an 
> interactive debugger for your environment.   Third is often automated 
> testing.   Fourth is code review if you are working with someone else.
> 
> For me one of the best tools for programming is prospective 
> documentation.  Call it requirements or system design if you like.  I 
> like to write down in English what I want the program to do before I 
> start programming.  Usual this is nothing very formal.  Just a 
> few sentences and paragraphs, maybe a picture or two that convey the 
> concepts and sequences that will go into the design.  From this I can 
> work out a modular breakdown and some high level functionality goals.
> 
> Then I can take each module and goal and break them down further, 
> implement each including automated testing and at least a stub of 
> documentation and finaly integrate them together into a complete system 
> including as much automated integration testing as I can muster.   When 
> the system is finished and if you are lucky people start using your 
> system.   And that's when it starts getting really hard. 
> 
> 
> On Tue, May 17, 2011 at 6:39 AM, Mike Bean <beandaemon at gmail.com 
> <mailto:beandaemon at gmail.com>> wrote
> 
>     Besides, I know I'm basically just a wanna-be, but my experience of
>     coding is very...different, then the public perception of the work,
>     especially in large projects.  write a couple lines, test, curse at
>     the monitor, tweak, test, curse at the monitor, tweak, throw the
>     monitor out the window.   Get a new monitor, tweak, test again, go
>     out to lunch, get an idea, tweak, it finally works, write a few more
>     new lines and repeat the whole process ad nauseum.
> 
>     I wrote a python calculator, nothing special, just adds and
>     subtracts.  50 lines.   Took me at least a week.  Granted, it's not
>     my full time job, but I did some scribbling in various notebooks at
>     Wendy's over dinner when I could until I could type it out
> 
>     Most of the large projects I've seen don't tend to have one person
>     in charge of the whole source,  this guy writes a function, that guy
>     writes the video driver...etc...etc...  To a degree you all end up
>     leaning on each other anyway.   Case and point,
>     http://www.nerdmeritbadges.com/products/rubberduck
> 
>     Bean
> 
>     On Mon, May 16, 2011 at 11:42 PM, Brian Gibson <bwg1974 at yahoo.com
>     <mailto:bwg1974 at yahoo.com>> wrote:
> 
>          > In learning to program, can you get someone else to help
>         debug the programs...?
> 
>         Yes. The actual process of explaining your code to someone else
>         often helps to highlight where you made your mistake.
> 
> 
> 
>         ------------------------------------------------------------------------
>         *From:* Louis Miller <veganguy at canadaseek.com
>         <mailto:veganguy at canadaseek.com>>
>         *To:* clue <clue at cluedenver.org <mailto:clue at cluedenver.org>>
>         *Sent:* Sun, May 15, 2011 1:40:31 PM
>         *Subject:* [clue] debuging programs
> 
>         Hello,
> 
>               I'm working on the fourth program from the "Learn Python
>         the Hard Way" book. It isn't working, right. In learning to
>         program, can you get someone else to help debug the programs, or
>         to see that you typed everything correctly, or are you supposed
>         to be all on your own? If it is not inappropriate to get help
>         with this, then how would I go about finding someone online?
>         Maybe, there is a program that compares lines of text,
>         automatically, that you can use?
> 
>         Louis
> 
>          
>         ------------------------------------------------------------------------
>         Get email for your site ---> http://www.canadaseek.com
> 
>         _______________________________________________
>         clue mailing list
>         clue at cluedenver.org <mailto:clue at cluedenver.org>
>         http://cluedenver.org/mailman/listinfo/clue
> 
> 
> 
>     _______________________________________________
>     clue mailing list
>     clue at cluedenver.org <mailto:clue at cluedenver.org>
>     http://cluedenver.org/mailman/listinfo/clue
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> clue mailing list
> clue at cluedenver.org
> http://cluedenver.org/mailman/listinfo/clue