Re: [Edu-sig] Progamming advice.
Somewhat apropos:
http://worldgame.blogspot.com/2009/03/patterns-in-python.html
I see Fowler getting mentioned a lot in this thread. Below, a couple
more titles:
Jacob: Tests are the programmer's stone, transmuting fear into boredom
(Kent Beck, author of Test Driven Development). Build in time to write
tests. TDD = Test Driven Development. Jacob doesn't do it hardcore,
gets annoyed with the dogma. Read Code Complete, published by
Microsoft -- one of the best books ever. When you start down the
testing road, you're making a contract with yourself to not check in
code with broken tests.
That's from my write-up, (Jacob = Jacob Kaplan-Moss of Django dojo):
http://worldgame.blogspot.com/2009/03/django-workshop.html
Kirby
On Wed, Apr 8, 2009 at 7:25 AM, Christian Mascher
wrote:
> Hi Gary,
>
> Kirby is right: this is what you should be looking at.
>>
>> There's the design patterns literature, sometimes fun to just eyeball
>> so you get used to seeing patterns, even if different from the ones
>> described.
>
> Some IMHO really good books on the practical aspects of software design with
> agile languages are:
>
> Refactoring, by Martin Fowler. You have probably heard of this book.
>
> Smalltalk Best Practice Patterns, by Kent Beck.
> A set of "rules" how to write cleaner code (in Smalltalk). I like it,
> because it adresses little, practical aspects like appropriate naming ("Role
> suggesting temporary variable name", , "Type suggesting parameter name")
> which can be applied to Python-code (weakly typed like Smalltalk). I am not
> aware of a similar book for Python. Does anyone?
>
> (Kent Beck also wrote a book on Test-Driven Delopment where he actually uses
> Python in the second part.)
>
> HTH
>
> Christian
> ___
> 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
Re: [Edu-sig] Progamming advice.
Hi Gary,
Kirby is right: this is what you should be looking at.
There's the design patterns literature, sometimes fun to just eyeball
so you get used to seeing patterns, even if different from the ones
described.
Some IMHO really good books on the practical aspects of software design
with agile languages are:
Refactoring, by Martin Fowler. You have probably heard of this book.
Smalltalk Best Practice Patterns, by Kent Beck.
A set of "rules" how to write cleaner code (in Smalltalk). I like it,
because it adresses little, practical aspects like appropriate naming
("Role suggesting temporary variable name", , "Type suggesting parameter
name") which can be applied to Python-code (weakly typed like
Smalltalk). I am not aware of a similar book for Python. Does anyone?
(Kent Beck also wrote a book on Test-Driven Delopment where he actually
uses Python in the second part.)
HTH
Christian
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Progamming advice
On Tue, Apr 7, 2009 at 7:12 PM, David MacQuigg wrote: > At 09:35 AM 4/7/2009 -0400, Gary Pajer wrote: << SNIP >> > Send me some examples of early versions of your programs, and I'll help make > them into a sequence that will serve as good examples for students. See the > sequence OhNo.py for what I have in mind. This example is a bit artificial, > but perhaps some of your real-world programs could be the basis of something > much better. > > -- Dave I'm eager for Dave's proposed course (and course ware) to flourish, especially if he continues being so generous with his PDFs etc. So true that working non computer scientists might benefit from a "best practices" course. There should be no stigma around sharing draft code, what liberal cultures encourage. Lots of people stop themselves saying: I don't want to publish code others might criticize. But that's the whole point: flag the code as a work in progress and invite comments, suggestions. This is how we learn. As R0ml Lefkowitz points out, free as in freedom is where "liberal arts" come in, with software skills becoming the "new rhetoric" in some ways. http://mybizmo.blogspot.com/2008/07/more-oscon-keynotes.html >>> Random observations re scientific computing w/ Python: The SciPy site has a lot of materials geared for the scientist needing to get work done (yeah, some of those links are broken. http://www.scipy.org/Topical_Software http://www.scipy.org/wikis/topical_software/Tutorial (long and detailed, lots of work directly in the shell which I like) http://pypi.python.org/pypi/ is scary to me, such a hodge podge. Anyone in the habit of using Bruce BTW? http://pypi.python.org/pypi/bruce/3.2.1 PyMOL doesn't seem as accessible as I remember, documentation only for subscribers: http://pymol.sourceforge.net/ I'm out of date on Numpy but have it as a consequence of compiling Visual Python: http://numpy.scipy.org/ http://vpython.org/ Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Progamming advice
At 09:35 AM 4/7/2009 -0400, Gary Pajer wrote: >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. Sounds like we have similar backgrounds. You are exactly the type of non-programmer professional that I have in mind for the "CS2" class I have been thinking about. http://ece.arizona.edu/~edatools/index_classes.htm CS majors have a sequence of classes to learn all about CS, with a lot of emphasis on tools and techniques used by professional programmers. Non-programmers get only one freshman-level class in C or Java, and miss a lot of the really good stuff that could be distilled from the three courses taught to CS majors, stuff like OOP, that is helpful to an individual writing his own programs. I really believe we can do this in one semester without making it seem rushed or overwhelming. One good design will teach the concept of design patterns. Most of the others are not that useful anyway. Many of the tools only improve productivity if you use them all the time, and get in the way if you have to stop and review the manual because you were working on something else for six months. Send me some examples of early versions of your programs, and I'll help make them into a sequence that will serve as good examples for students. See the sequence OhNo.py for what I have in mind. This example is a bit artificial, but perhaps some of your real-world programs could be the basis of something much better. -- Dave ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
Gary Pajer wrote: > 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. > 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... A good book on exactly this subject is "Object-Oriented Modeling and Design with UML" by Blaha and Rumbaugh. Here you will learn about Class Models, State Models, and Interaction Models. It may be a little tough for self-study, however. I studied it in a class on OOP, taught by a professor who was not only an inspiring teacher, but had plenty of experience in large projects. It might have been a dull read otherwise. He also had us work in teams of 3 to 4 students each, thereby forcing us to pay attention to modular design and interface definitions. Another good book, maybe better for self-study is Steve McConnel's "Code Complete". This is more like an encyclopedia of good programming, so you can read a topic without reading the whole book. If you want a quick summary of the "goto" debate, look here first. I think what you really need, however, can only be acquired through real-world experience designing systems that are complex enough to *require* good modular design, well-defined interfaces, etc. I think of OOP as just one tool in a bag of good engineering practices. TDD is certainly another. Using good data structures is another, and Python is really superb at getting you to formulate your problem in terms of simple data structures. -- Dave ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
On Tue, Apr 7, 2009 at 1:09 AM, Laura Creighton 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
Re: [Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
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 > >-gary ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
On Mon, Apr 6, 2009 at 1:50 PM, Gary Pajer wrote: > On Mon, Apr 6, 2009 at 3:34 PM, kirby urner 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 >> scienc
Re: [Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
There's the design patterns literature, sometimes fun to just eyeball so you get used to seeing patterns, even if different from the ones described. 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 feasible. 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 API. 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 object). 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 different? 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 telling us. In sum: design patterns, TDD / XP. Kirby 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 wrote: > > On Mon, Apr 6, 2009 at 3:34 PM, kirby urner 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 approache
Re: [Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
On Mon, Apr 6, 2009 at 3:34 PM, kirby urner 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... -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? > > 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 wrote: > > On Wed, Mar 25, 2009 at 4:43 PM, kirby urner > 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 thi
Re: [Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
Gary Pajer wrote: ... 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? OK, I may be CS-biased, but I think a data structures course, taught well, can be the quickest way to get to core structures you'll need. As to general programming rules: much like in writing in English, go for short clear exposition. Think of a program not so much as controlling a computer as describing to another programmer how you go about accomplishing this computing task. Just as you don't write twelve-page paragraphs; don't write 12-page functions or methods. Remember the other programmer may be you in year or two, so be kind about making details clear. Although this is tangential, I've recently been remembering one of the great moments in "Corporate Politics JuJitsu" that I experienced decades ago. I was working in an OS and Languages group, and we would regularly get requests for short programs do "just do something simple." We would give estimates that frustrated the requester, in that we'd be taking a week for what may well have been a half-day programming task. Of course, a lot of our maintenance work consisted of coping with hack- on-hack-on-hack software. Finally, we hit upon a solution. We offered two-pronged estimates: one day if we delete the source before delivering the program, or one week if we keep the source. The dual-estimate satisfied everyone. We had the luxury of getting things right to support, without "over-charging" for things that were truly one-off productions. It was amazing how many one-time requests wanted the full week version when they realized that "what you did last week with this little change" was going to cost them a full redevelop. These days I see this as matching the Agile Programming goal of leaving the customer in charge, but then I just thought it was a miraculous way of explaining explaining what the extra time went for. --Scott David Daniels scott.dani...@acm.org ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
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. 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. Kirby On Mon, Apr 6, 2009 at 11:33 AM, Gary Pajer wrote: > On Wed, Mar 25, 2009 at 4:43 PM, kirby urner 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? > > 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
[Edu-sig] Progamming advice. (Was: Why MIT switched from Scheme to Python)
On Wed, Mar 25, 2009 at 4:43 PM, kirby urner 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? 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
