Why do Pythoneers reinvent the wheel?

[Tim Daneliuk]

Kay Schluehr wrote:

> Tim Daneliuk wrote:
> 
> 
>>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.
> 
> 
> Allthough I do think that you are completely wrong in principle there
> is some true point in your statement: refactoring a foreign ill
 > designed tool that nevertheless provides some nice functionality but is
 > not mentioned for being extendable by 3-rd party developers is often
 > harder than writing a nice and even though inextendable tool on your own

It has nothing to do with being "ill designed", though that too would
pose a (different) problem. It has to do with the fact that all
realworld tools are a tradeoff between pragmatism and generic elegance.
This tradeoff yields a tool/module/library/program with some POV about
what problem it was solving. If the problem you wish to solve is not in
that same space, you can inherit, subclass and do all the usual OO
voodoo you like, you're not going to get clean results.

On a more general note, for all the promises made over 3 decades about
how OO was the answer to our problems, we have yet to see quantum
improvements in code quality and productivity even though OO is now "the
thing" everyone is supposed to subscribe to. In part, that's because it
is profoundly difficult to see the most generic/factorable pieces of a
problem until you've worked with it for a long time. Once you get past
the "a mammal is an animal" level of problems, OO starts to
self-destruct pretty quickly as the inheritance hierarchies get so
complex no mere mortal can grasp them all. This is exactly Java's
disease at the moment. It has become a large steaming pile of object
inheritance which cannot be completely grokked by a single person. In
effect, the traditional problem of finding algorithms of appropriate
complexity gets transformed into a "what should my inheritance hierarchy
be" problem.

IMHO, one of Python's greatest virtues is its ability to shift paradigms
in mid-program so that you can use the model that best fits your problem
space. IOW, Python is an OO language that doesn't jam it down your
throat, you can mix OO with imperative, functional, and list processing
coding models simultaneously.

In my view, the doctrinaire', indeed religious, adherence to OO purity
has harmed our discipline considerably. Python was a nice breath of
fresh air when I discovered it exactly because it does not have this
slavish committment to an exclusively OO model.



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