[Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
gary.pajer at gmail.com
Mon Apr 6 22:50:09 CEST 2009
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
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...
> My friend Bernie Gunn was a scientist of this variety, a veteran of
> Pascal, a serious-minded geochemist. He was evaluating Java versus
> Python for a next iteration. Making the leap across paradigms was far
> from trivial for the guy (who flew his own plane well into his 80s):
> http://www.geokem.com/ (you'll see a write-up on Python in the
> Background section)
> The hype around "object oriented" rubbed a lot of seasoned
> professionals the wrong way and many still refuse to make it the
> ground zero for coding, think a year of procedural code should be a
> prerequisite for all that newfangled object stuff (kind of like
> insisting on a land line before moving to cell).
> However, I think most happy camper Pythoneers have become comfortable
> with OO and exploit its chief ability, which is to mirror a problem
> domain using the shoptalk of the trade. The Python version should
> "fit your brain" because it's pretty close to the way you were
> thinking about things anyway.
> Your code is in terms of your chemistry, biology, astronomy or
> whatever. Things (nouns) have behaviors (verbs) and attributes
> (adjectives). You're sharing ideas with peers in your field, with
> Python syntax becoming more incidental, getting out of the way. Like
> with other mathematical notations, you might use code snippets to
> describe what's going on. Two particles collide, what's that look
> like in snake?
> Just trying to aim for what I take to be the "aesthetic ballpark" (our
> Pythonic Valhalla): using lots of classes and objects to mirror the
> stuff one actually encounters on the job.
> Think of Python as a language for talking shop to your peers (the best
> code is collaborative) and not as a way to pay homage to the computer
> science gods (or goddesses, as the case may well be). Of course some
> people are computer scientists and their Python is "about CS". So
> much other code isn't like that.
> On Mon, Apr 6, 2009 at 11:33 AM, Gary Pajer <gary.pajer at gmail.com> wrote:
> > On Wed, Mar 25, 2009 at 4:43 PM, kirby urner <kirby.urner at gmail.com>
> > [...]
> >> What does the robot look like I wonder. Open source? API? Yes, I
> >> should Google, but I'm trying to track a "Django in the real world"
> >> workshop at the moment. Pycon. Packed room. They're showing the
> >> slide that scares me the most: LiveJournal Backend: Today (roughly).
> >> LAMP isn't as easy as it sounds.
> >> Here're the slides we're looking at FYI:
> >> http://jacobian.org/speaking/2009/real-world-django/
> > This is orthogonal to everything:
> > I looked at those slides, and they hint at good practical tips and advice
> > for structuring your Django app.
> > Just this past weekend I was wondering where I could find such things,
> > is, help at learning good ways to structure a python program (for generic
> > python, not specifically Django), written for the non-programmer
> > scientist/educator. When I write my programs I always feel that
> certainly I
> > am attacking the problem in the least-elegant, least-extendable,
> > least-reusable, most-brute-force way possible. It's easy to find
> > manuals, but what's the best way to learn better programming techniques /
> > structures / etc?
> > Maybe the request is a bit off-topic, but it came up in reference to the
> > above, and besides, there are probably people here who understand the
> > question and can answer it!
> > Thanks,
> > gary
> > _______________________________________________
> > Edu-sig mailing list
> > Edu-sig at python.org
> > http://mail.python.org/mailman/listinfo/edu-sig
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Edu-sig