[Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)

[Gary Pajer]

On Tue, Apr 7, 2009 at 1:09 AM, Laura Creighton <lac at openend.se> wrote:

> In a message of Mon, 06 Apr 2009 16:50:09 EDT, Gary Pajer writes:
> >But to clarify:  I've been programming in python for about six years, alo
> >ng
> >the way abandoning Matlab in which I was a local go-to guy.   By the way,
> >I've also adopted Traits and the Enthought Tool Suite, which IMHO might
> >possibly be the future of practical laboratory programming in python.  So
> >I'm comfortable enough with the nuts and bolts of OOP.   But higher level
> >questions like what to make a function, what to make a class, what to mak
> >e a
> >module, how best to factor it all out, when to decimate a long routine in
> >to
> >a bunch of shorter ones,
>
> That last is telling.  It could indicate where your problem is, which is
> that you tend to put too much stuff, and the wrong stuff, in a routine.
>
>
> >how best to organize input, computation and outp
> >ut
> >(Traits' MVC architecture helps there), how to think about designing for
> >reuse, how to reuse what's already available, when does sub-classing make
> >sense, when do exceptions make sense...  and so on and so on.
> >
> >My current habit is to start coding somewhere and keep patching things on
> >till it does what I want.  Imagine building a house starting with "I know
> > I
> >need at least one upright piece of lumber.  I'll put it here.  I need
> >another to hold it up.  Then another set over here, and a horizontal one
> >over there...".   I wouldn't want to live in the resulting house.  My cod
> >e
> >... the resultant code is hard to follow, hard to document,  hard to exte
> >nd
> >or change, and probably slower than it might be, and I wouldn't want to l
> >ive
> >in that, either.   When I try to plan my code the way I might plan a hous
> >e,
> >I soon find myself swimming in possible ideas, going in circles with
> >different plans, having disparate approaches in different parts of the
> >program, etc.
> >
> >I'm wondering if some wizard has written a guide to program structure
> >paradigms for the intermediate programmer.  Or perhaps this kind of thing
> > is
> >actually taught in books somewhere...
>
> If your problem is 'I have way too many fiddly bits' then what your problem
> may be is that you don't know enough useful data structures, and you need
> some.  A data structures course (and there are textbooks for this) will
> help.  And they can give your code some needed all-over structure.  Just
> learning to think in data structures will help your ability to write code
> in any case.
>
> But your problem may be 'I don't have enough fiddly bits' -- and it sounds
> like that from your description.  It sounds like while you are writing
> code,
> and solving one bit of the problem you start thinking about a different
> problem, and stick that solution in there, just as you are writing.  This
> will result in pieces of code that are very hard to refactor, debug,
> document and test, and with bugs due to subtle dependencies in addition.
>
> Or you could be truly blessed and have both problems at the same time.
>
> If your problem is the second, then the best thing to do is to practice
> test-driven development.  Write the test first.  Then only write enough
> code to make the test pass.  Then write another test.  and so on and
> so forth.  By making the tests really small, you can limit the size of
> the routines that you are making.  And by having to write the test first
> you will get a little more perspective on where in your existing code
> it should go.  So you get fewer 'I put it here because that was
> what I happened to be writing at the time' problems.  Finally, if you
> catch yourself having brilliant ideas and wanting to race off and code
> them 'before I forget' .. then TDD will improve things a lot for you.
> Because writing the test is usually a whole lot easier than writing
> the code, and if you can get your brilliant idea down in a test, then
> its a lot safer for the rest of your code.  Lots of errors happen in
> this business because one is not paying attention to the code that one
> is actually typing down at the moment, but are instead listening to
> your inner voice design the code that you will be typing in 10 minutes,
> or 10 hours.
>
> If I were you I would go over to
> http://diveintopython.org/toc/index.html
> and work through the examples in sections 13, 14, and 15  which introduces
> unittesting, test first programming, and refactoring.  See if it makes
> you feel any different.  If you aren't used to test first development, it
> will be hard for a while, but persevere, it is worth it.
>
> Martin Fowler's Refactoring: Improving the Design of Existing Code
> may be worth a read, too.
>
> Good luck!
>
> Laura


Hey Laura, you seem to grok my situation quite well.  Thank you for
responding, and thanks to all others, including they who have something to
say but haven't yet.

I am but a poor physicist and self-taught (out of necessity) programmer,
aside from one course in FORTRAN in 1973.  Until this discussion I was not
at all familiar with the terms  TDD,  unittest, design pattern, class model,
state model, interaction model.  And thanks for the pointers to Fowler, and
Dive Into Python.  I really do feel like I'm looking at a pile of lumber,
nails, hammers, and saws, and being expected to build a house. My apps are
getting complex, and seat-of-the-pants isn't working so well anymore.

Gratefully,
-g




>
>
> >
> >-gary
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20090407/7dc89c99/attachment-0001.htm>