Why do Pythoneers reinvent the wheel?

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Tim Daneliuk]

OO ideas predate C++ considerably. The idea of encapsulation and
abstract data types goes back to the 1960s IIRC.

Did not Simula-67 have it all already?

When C++ came along, much later, I asked someone knowledgeable in the
field of language design what was his opinion about C++. He answered
very laconically: Simula-- . And this was not far from fully true:
Simula had many virtues which are still missing from C++.

Moreover, a language like Simula cannot be made up of thin air, it only
crystallizes a long maturation of many trends. The term "OO" may have
been coined later, but the concepts were already there. In computer
science, I often saw old concepts resurrecting with new names, and then
mistaken for recent inventions. New ideas are not so frequent...

 

[Steve Holden]

- They want the feeling that they are in the same league as the original inventor ;-)



- Think more carefully about ego satisfaction cost/benefit vs getting the job done ;-)

Indeed, the simple answer to the original question is "because they
can". Python as a language attracts many people who aren't already
familiar with programming methods, which is why this list sees many
questions with relatively simple answers. I love the way the responses
determinedly refuse to put the questioners down for the simplicity of
the questions: we all have to learn, after all.

Generally as we get more experienced in programming we will spend a much
larger amount of time looking for (and carefully evaluating) existing
solutions to a problem, and rather less time trying to write our own
code to solve a problem.

Python's elegance and simplicity encourages people with less programming
experience to attempt solutions to larger problems, albeit with varying
degrees of success. So, despite the language's "There should be one (and
preferably only one) obvious way to do it" philosophy, we often end up
with many "competing" solutions to a given problem.

While this can sometimes be tedious, it's probably an overall indication
of Python's health.

regards
Steve

 

[Gregory Bond]

In computer
science, I often saw old concepts resurrecting with new names, and then
mistaken for recent inventions. New ideas are not so frequent...

"There are very few problems in Computer Science that cannot be solved
with an additional level of indirection."

-- Dunno who said it first, but I wish it was me.

 

[Claudio Grondi]

Here some of my thougts on this subject:

I think that this question adresses only a tiny
aspect of a much more general problem the
entire human race has in any area.
Reinventing the wheel begins when the grandpa
starts to teach his grandchild remembering well
that he has done it already many times before
to own children.

As any of us takes the chance to be somehow
different and writing program code does need
much understanding how and why something
works, it is very probably, that what is there is hard
to understand (Python as a programming language
is not really an exception here). There is not much
around of so universal value, that it can be
taken any time by anyone.

When I am coming myself back to what I have created
in the past I often see what trash I have produced.
The unique discoveries of the kind "wow! today I would
do it the same way or even less smart not given enough
time" don't change the general picture.

So the question is here, where are the tools making
it possible to find a piece of code solving a
problem when the problem is formulated only
using natural language? I am finding myself reinventing
the wheel all the time only because I am not able to find
appropriate pieces of code in the collection I have put
together (am I alone here? bad memory? lack of
proper filing system?).

It seems, that posting to a newsgroup is usually
the best choice, but even this needs much work
in advance before it is possible to communicate what the
problem is, that one has.
In case of the OpenCV interface to Python even that
seem not to help ... (I am pretty sure there is someone
out there who would be able to put me in the right
direction).

Are there any tools in Python based on associations
looking for specific types of code?
Something similar to http://www.qknow.com , but addressed
towards specific needs of a programmer looking for code
snippets? (not a kind of search engine or system of
folders with cross links, but a system able to find a chain
of snippets required to solve a problem).

To name a simplest example:
What should I do to find a piece of code taking an
integer and giving a string with binary form of a
number? How to put some available pieces of code
together if the binary form is needed and the integer
is provided as a string holding its hexadecimal form?
What if the string is the binary representation of the
integer value as internally stored in memory?
What if I would like the binary form to be splitted
in nibbles separated with one space and bytes with
two spaces?

How can I avoid to reinvent the wheel, when I
don't have the tools to find what I am looking
for?

Saying it in words of the Beatles song:
"Help me if you can, I'm feeling down.
And I do appreciate you being round.
Help me, get my feet back on the ground,
Won't you please, please help me,
help me, help me, oh. "

Claudio

What is pythonutils ?
=====================
ConfigObj - simple config file handling
validate - validation and type conversion system
listquote - string to list conversion
StandOut - simple logging and output control object
pathutils - for working with paths and files
cgiutils - cgi helpers
urlpath - functions for handling URLs
odict - Ordered Dictionary Class

Fuzzyman, your post reminded me of something I can't stop thinking
about. Please don't take this as a critique on your work. I place
myself on the same side of yours.
I just wanted to share this thought with everybody had an opinion about it.

I wonder how many people (including myself) have implemented their own
versions of such modules, at least once in their pythonic life. I
indeed have my own odict (even same name! . My own pathutils
(different name, but same stuff). My own validate... and so forth.

This is just too bad.
There are a few ares where everybody seems to be implementing their
own stuff over and over: logging, file handling, ordered dictionaries,
data serialization, and maybe a few more.
I don't know what's the ultimate problem, but I think there are 3 main
reasons:
1) poor communication inside the community (mhm... arguable)
2) lack of a rich standard library (I heard this more than once)
3) python is such an easy language that the "I'll do it myself" evil
side lying hidden inside each one of us comes up a little too often,
and prevents from spending more time on research of what's available.

It seems to me that this tendency is hurting python, and I wonder if
there is something that could be done about it. I once followed a
discussion about placing one of the available third party modules for
file handling inside the standard library. I can't remember its name
right now, but the discussion quickly became hot with considerations
about the module not being "right" enough to fit the standard library.
The points were right, but in some sense it's a pity because by being
in the stdlib it could have had a lot more visibility and maybe people
would have stopped writing their own, and would have begun using it.
Then maybe, if it was not perfect, people would have begun improving
it, and by now we would have a solid feature available to everybody.

mhm... could it be a good idea to have two versions of the stdlib? One
stable, and one testing, where stuff could be thrown in without being
too picky, in order to let the community decide and improve?

Again, Fuzzyman, your post was just the excuse to get me started. I
understand and respect your work, also because you put the remarkable
effort to make it publicly available.

That's my two cents,
stefano

 

[Magnus Lycka]

To name a simplest example:
What should I do to find a piece of code taking an
integer and giving a string with binary form of a
number? How to put some available pieces of code
together if the binary form is needed and the integer
is provided as a string holding its hexadecimal form?
What if the string is the binary representation of the
integer value as internally stored in memory?
What if I would like the binary form to be splitted
in nibbles separated with one space and bytes with
two spaces?

It's possible that you have a point in principle,
but these examples don't strengthen your point.

A function that turns e.g. 5 into '101' is trivial
and just a few lines of code. Finding that in some
kind of code catalog would certainly be more work
than to just code it. Besides, there are a number
of variants here, so a variant that makes everybody
happy when it concerns dealing with negative numbers,
range checks, possibly filling with zeros to a certain
length etc, would probably be both bigger and slower
than what the average Joe needs.

This is simply the wrong level of reuse. It's too
simple and too varied. To be able to express things
like that in code is very basic programing.

You create integers from numeric representation in
strings with the int() function. You should read
chapter 2 in the library reference again Claudio.
This is one of the most common builtin function.
int() accepts all bases you are likely to use and
then some.

Filtering out spaces is again trivial.
"0101 0110".replace(' ','') Also chapter 2 in the
library manual.

You should read this until you know it Claudio! It's
really one of the most important pieces of Python
documentation.

I might be wrong, but I suspect you just need to get
more routine in programming. Your reasoning sounds a
bit like: "I don't want to invent new sentences all the
time, there should be a catalog of useful sentences
that I can look up and use.

Sure, there are phrase books for tourists, but they are
only really interesting for people who use a language
on a very naive level. We certainly reuse words, and
it's also very useful to reuse complete texts, from
short poems to big books. Sure, many sentences are often
repeated, but the ability to create new sentences in
a natural language is considered a basic skill of the
user. No experienced user of a language use phrase
books, and if you really want to learn a language
properly, phrase books aren't nearly as useful as proper
texts.

There are simply so many possibly useful sentences, so
it would be much, much more work to try to catalog and
identify useful sentences than to reinvent them as we
need them.

It's just the same with the kinds of problems you described
above. With fundamental language skills, you'll solve these
problems much faster than you can look them up. Sure, the
first attempts might be less than ideal, especially if you
haven't read chapter 2 in the library manual, but you learn
much, much more from coding than from looking at code
snippets.

 

[konrad.hinsen]

There are a few ares where everybody seems to be implementing their
own stuff over and over: logging, file handling, ordered dictionaries,
data serialization, and maybe a few more.
I don't know what's the ultimate problem, but I think there are 3 main reasons:
1) poor communication inside the community (mhm... arguable)
2) lack of a rich standard library (I heard this more than once)
3) python is such an easy language that the "I'll do it myself" evil
side lying hidden inside each one of us comes up a little too often,
and prevents from spending more time on research of what's available.

I'd like to add one more that I haven't seen mentioned yet: ease of
maintenance and distribution.

Whenever I decide to use someone else's package for an important
project, I need to make sure it is either maintained or looks clean
enough that I can maintain it myself. For small packages, that alone is
often more effort than writing my own.

If I plan to distribute my code to the outside world, I also want to
minimize the number of dependencies to make installation simple enough.
This would only stop being a concern if a truly automatic package
installation system for Python existed for all common platforms - I
think we aren't there yet, in spite of many good ideas. And even then,
the maintenance issue would be even more critical with code distributed
to the outside world.

None of these issues is specific to Python, but with Python making new
developments that much simpler, they gain in weight relative to the
effort of development.

It seems to me that this tendency is hurting python, and I wonder if
there is something that could be done about it. I once followed a

I don't think it hurts Python. However, it is far from an ideal
situation, so thinking about alternatives makes sense. I think the best
solution would be self-regulation by the community. Whenever someone
discovers three date-format modules on the market, he/she could contact
the authors and suggest that they sit together and develop a common
version that satisfies everyone's needs, perhaps with adaptor code to
make the unified module compatible with everyone's individual modules.

Konrad.

 

[Jorgen Grahn]

[Tim Daneliuk]

OO ideas predate C++ considerably. The idea of encapsulation and
abstract data types goes back to the 1960s IIRC.

Did not Simula-67 have it all already?

When C++ came along, much later, I asked someone knowledgeable in the
field of language design what was his opinion about C++. He answered
very laconically: Simula-- . And this was not far from fully true:
Simula had many virtues which are still missing from C++.

I can believe that.

The hype however, and all the "a mammal is an animal" talk was something
most people weren't affected by until the late 1980s, I think.

In computer
science, I often saw old concepts resurrecting with new names, and then
mistaken for recent inventions. New ideas are not so frequent...

Yeah. I've often wished for some overview or guide that translates the
current buzzwords to old concepts I'm familiar with. For example, I'm sure
you can capture the core ideas of something like .NET in a couple of
sentences.

(Or maybe not. It would take me a couple of paragraphs to summarize Python.)

/Jorgen

 

[Jorgen Grahn]

I'd like to add one more that I haven't seen mentioned yet: ease of
maintenance and distribution.

Whenever I decide to use someone else's package for an important
project, I need to make sure it is either maintained or looks clean
enough that I can maintain it myself. For small packages, that alone is
often more effort than writing my own.

If the licenses are compatible, you also have the option to simply steal the
code and merge it into yours -- possibly cutting away the stuff you don't
need. Or if not, to read and learn from it.

That's another kind of reuse, which is sometimes overlooked.

/Jorgen

 

[Mike Meyer]

Yeah. I've often wished for some overview or guide that translates the
current buzzwords to old concepts I'm familiar with. For example, I'm sure
you can capture the core ideas of something like .NET in a couple of
sentences.

Just taking a stab in the dark, since I'm only vaguely familiar with
..NET: P-code for multiple languages?

<mike