Defending the Python lanuage...

[Cliff Wells]

On Tue, 5 Feb 2002 08:38:53 +1100
Peter Milliken wrote:

> 
> Hmmm.... Sounds like we have a small "disconnect" - this sounds like what
I
> would consider design to me - now I am in the "real" world of commercial
> programming, it is becoming more and more obvious that this just doesn't
> happen (design documentation I mean :-)). As a programmer for defense
> contractors, you did preliminary designs and then detailed designs (with
> attendant reviews) so the "coding problems" were all worked out at that
> stage i.e. by the times you had sorted out design to the point of pseudo
> code (or somewhere of that level) the coding became very straight forward
-
> and you knew it was all going to hang together! :-) (assumed that
> traceability of the requirements was done correctly and no boo-boos were
> made! :-)).  Perhaps I am wrong though? Anyway, it sounds like a good,
> comfortable working relationship that could only help you both generate
> better product.

I haven't had the (mis?)fortune to work on a large enough project where
there were a lot of preliminary steps and documentation, pseudo-code, etc,
generated prior to actual coding.  Of course there were discussions with
management and customers to outline what was wanted, but usually after that
it came down to discussing (with the other programmers) what
tools/libraries (and how they would fit in a general scheme) would be used
to develop the application.  Much discussion revolved around longevity,
simplicity, and generalization of developed code.  What we usually strived
for was to develop generalized libraries that could be used throughout the
application (and elsewhere). After that, application-specific code would be
used to glue the whole thing together.  The main goal was always to reduce
the amount of application-specific code needed for any particular program.

We developed this approach based upon statements made by Richard Stallman
(and common sense ;) on the GNU approach to development: 

1. no arbitrary limits
2. embed a language in your application and use that to develop parts of
the application
3. turn parts of the program into independent libraries  <-- repeat,
repeat, repeat

To this I would add that using an n-tier design will greatly extend the
lifetime of a piece of software (especially since much "upgrading" often
involves cosmetic changes or changes that are irrelevant to the function of
the software [like supporting a different SQL backend]) and makes things
like redundancy easier to implement.  Of course this is just an extension
of the Unix "tools" philosophy.

Python is an excellent language if you plan to follow these guidelines
(especially #2 which can otherwise be very difficult).

The difficult thing with this approach is that it does slow initial
development down a bit (or it appears to).  However, that lost time is
usually quickly recovered near the end of the development cycle (not to
mention debug times).  Also, given an extensible infrastructure, it's
tempting to start extending right away (hey, you have to test it, right? ;)
and not focus on the original spec.

-- 
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308  (800) 735-0555 x308

"Then with your new power you'll accomplish all sorts of cool stuff 
 in no time, and We'll All Be Sorry.  At that point you can either 
 gloat a bit, and then relent, or go ahead and send the robot army 
 after us." - Quinn Dunkan