[Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
kirby.urner at gmail.com
Mon Apr 6 22:56:35 CEST 2009
There's the design patterns literature, sometimes fun to just eyeball
so you get used to seeing patterns, even if different from the ones
In some of my venues, there's a rule against any one person getting to
code a whole project i.e. deliberate management strategy to force a
minimum of two heads in any one black box, with the thought being, if
you have to explain it to me as you go, and I to you, then we won't
get away with just "documenting in our heads" (I'll get back to it
later). When your counterpart starts saying "I no longer understand
this" then you know you've got some rewriting to do. More than two if
Of course that's too much a luxury some maybe thing. Also, don't get
me wrong: to collaborate on code is still to write big pieces of it
yourself. It's just that the other coder has to be a consumer of your
Encapsulation: I'm exporting some API for this other coder to use,
and once I've put it out there, I should think twice about changing
it, lest I break stuff I don't know about... that's a good mentality
in general, even if just writing for yourself. Think of the little
"dashboards" that makes sense e.g. "increase heartrate" (if a patient
comp.lang.python also good, any number of friendly people.
Programming is hard, if doable. Having collaborators makes it easier
in part by adding to the fun. Plus think of coding as a kind of
publishing and how academia puts such stress on "peer review" (at
least when addressing outsiders). So why should code be any
You're probably familiar with test driven development (TDD). If not,
I'd do some reading. Write tests, lots of them, as you go, partly
just as an advertisement to another coder what your API is expected to
do. doctest is good, easy. I'd say "every module comes with tests"
is a good rule of thumb.
This is especially important in Python where so much happens only at
runtime, i.e. there's no compile time type checking or stuff of that
nature, so writing lots of traps, looking for holes, is a huge time
saver in the end.
Then stick to the discipline of never committing (publishing, sharing)
code that breaks your own tests.
A lot of this is "passing on lore" i.e. I've done a lot of solo coding
in my day, with no one to explain it to, and test driven development
hasn't always been my thing either. However, if you're really seeking
more discipline and professionalism in the coding department (as I am,
as we all are) then it makes sense to heed what the experts are
In sum: design patterns, TDD / XP.
PS: I also like list comprehensions, use 'em quite a bit.
Generators: way cool. Limited experience with scipy distro,
suspicious of traits, scared of Zope. Lots of small modules, using
__init__.py for package management (ever do that?).
On Mon, Apr 6, 2009 at 1:24 PM, Gary Pajer <gary.pajer at gmail.com> wrote:
> On Mon, Apr 6, 2009 at 3:34 PM, kirby urner <kirby.urner at gmail.com> wrote:
>> Hey excellent questions Gary, expect others will pipe up.
>> What I see as a challenge with Python is precisely its liberal nature,
>> as coders from earlier generations, cutting teeth in BASIC or FORTRAN,
>> find there's sufficient procedural syntax to sort of barrel ahead with
>> the same kind of thinking, involving loops within loops, not many
>> user-defined classes.
> It would be nice if a discussion ensued, but I'm still a little concerned
> that this might not be the right place.
> But to clarify: I've been programming in python for about six years, along
> 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 make a
> module, how best to factor it all out, when to decimate a long routine into
> a bunch of shorter ones, how best to organize input, computation and output
> (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 code
> ... the resultant code is hard to follow, hard to document, hard to extend
> or change, and probably slower than it might be, and I wouldn't want to live
> in that, either. When I try to plan my code the way I might plan a house,
> 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...
More information about the Edu-sig