Why do Pythoneers reinvent the wheel?

[Tim Daneliuk]

Stefano Masini wrote:

> On 10 Sep 2005 02:10:59 EDT, Tim Daneliuk <tundra at tundraware.com> wrote:
> 
>>As someone who implemented their own configuration mini-language
>>with validation, blah, blah, blah (http://www.tundraware.com/Software/tconfpy/)
> 
> 
> Well, a configuration mini language with validation and blahs is not
> exactly what I would call _simple_... :) so maybe it doesn't even fit

It's actually not *that* complicated.  Then again, the code is not
as elegant as is might be.

> 
>>1) The existing tool is inadequate for the task at hand and OO subclassing
>>    is overrated/overhyped to fix this problem.  Even when you override
>>    base classes with your own stuff, you're still stuck with the larger
>>    *architecture* of the original design.   You really can't subclass
>>    your way out of that, hence new tools to do old things spring into
>>    being.
> 
> 
> That's true, but usually only when the original design if too simple
> comparing to the complexity of the problem. Instead a very general
> solution can usually be subclassed to easily handle a simpler problem.
> You still have to actually understand the general and complex design
> in order to be able to write subclasses, so maybe one can be tempted
> to punt on it, and write its own simple solution. But in this case it

The problem is that for a lot of interesting problems, you don't know
the "generic" big-picture stuff until you've hacked around at small
specific examples. This is one of the deepest flaws in the gestalt of
OO, IMHO. Good OO requires just what you suggest - and understanding of
generics, specific applications, and just what to factor. But in the
early going of new problems, you simply don't know enough. For the
record, I think Python is magnificent both in allowing you to work
quickly in the "poking around" stage of things, and then later to create
the more elegant fully-featured architectures.

One other point here: In the commericial world, especially, software
tends to be a direct reflection of the organization's *processes*.
Commercial institutions distinguish themselves from one another (in an
attempt to create competitive advantage) by customizing and tuning these
business processes - well, the successful companies do, anyway.  For
example, Wal-Mart is really a supply chain management company, not a
consumer goods retailer.  It is their supply chain expertise and IT
systems that have knocked their competitors well into 2nd place.  And
here's the important point: These distinguishing business processes are
unique and proprietary *by intent*. This means that generic software
frameworks are unlikely to serve them well as written. I realize this is
all at a level of complexity above what you had in mind, but it's easy
to forget that a significant portion of the world likes/needs/benefits
from things that are *not* particularly generic.  This is thus reflected
in the software they write.


>>2) It's a learning exercise.
> 
> 
> Well, so we might as well learn a little more and rewrite os.path, the
> time module and pickle. Right? :)

I'm not deeply committed to that level of education at the moment :P

> 
> 
>>3) You don't trust the quality of the code for existing modules.
>>    (Not that *I* have this problem :-p  but some people might.)


> So, let's talk about a way to more effectively present available
> solutions to our good programmers! :)

Grappa?

-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra at tundraware.com
PGP Key:         http://www.tundraware.com/PGP/