[Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
lac at openend.se
Tue Apr 7 07:09:06 CEST 2009
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
>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
>module, how best to factor it all out, when to decimate a long routine in
>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
>(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
>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
>... the resultant code is hard to follow, hard to document, hard to exte
>or change, and probably slower than it might be, and I wouldn't want to l
>in that, either. When I try to plan my code the way I might plan a hous
>I soon find myself swimming in possible ideas, going in circles with
>different plans, having disparate approaches in different parts of the
>I'm wondering if some wizard has written a guide to program structure
>paradigms for the intermediate programmer. Or perhaps this kind of thing
>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
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.
More information about the Edu-sig