On Mon, Apr 6, 2009 at 1:50 PM, Gary Pajer <gary.pa...@gmail.com> wrote:
> On Mon, Apr 6, 2009 at 3:34 PM, kirby urner <kirby.ur...@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.

What do you want it to do? Could you start with a manageable piece of
that, so that you could give it a reasonable structure, then refactor
it to the point where you can explain it to someone else before you
add on the next bit? (Also, so that you have a place to attach the
next bit cleanly?) Lather, rinse, repeat? That is how most Linux
utilities grew, and each part of it is highly recommended in some of
the Agile programming methods I have worked with. I have Fowler's book
on Refactoring sitting on the desk in front of me at all times. Now
where did I put Design Patterns?

Take off your coder hat from time to time, and approach your app as a
pure user? Would you take this crud from anybody else? If not, fix it.

> 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...
>
> -gary
>
>>
>>
>> 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?

Or a Hamiltonian, or Feynman diagrams?

>> 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.
>>
>> Kirby
>>
>> On Mon, Apr 6, 2009 at 11:33 AM, Gary Pajer <gary.pa...@gmail.com> wrote:
>> > On Wed, Mar 25, 2009 at 4:43 PM, kirby urner <kirby.ur...@gmail.com>
>> > wrote:
>> > [...]
>> >
>> >>
>> >> 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,
>> > that
>> > 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
>> > beginners
>> > manuals, but what's the best way to learn better programming techniques
>> > /
>> > structures / etc?

Steal from the best coders you know. I'm currently stealing from Alan
Kay. Well, not really stealing. Let me put that another way.

For education, only work in Open Source.

>> > 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@python.org
>> > http://mail.python.org/mailman/listinfo/edu-sig
>> >
>> >
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig@python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
>



-- 
Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://earthtreasury.net/ (Edward Mokurai Cherlin)
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Reply via email to