On Tue, Apr 7, 2009 at 1:09 AM, Laura Creighton <[email protected]> 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 >
_______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
