ease (was Re: Messaging in Py?)

[Alex Martelli]

"Kendall Clark" <kendall at monkeyfist.com> wrote in message
news:aa03c0d9.0105241048.1220f1c3 at posting.google.com...
> "Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:<9eak3d08ca at enews1.newsguy.com>...
> > "Kendall Clark" <kendall at monkeyfist.com> wrote in message
> > news:aa03c0d9.0105201805.2bd5a19c at posting.google.com...
> >     ...
> > > Seriously, while I agree that it's easy to write networking code
> > > in Python, nothing's easier than finding out someone's already done
                                      ^^^^^^^^^
    ...
> > Python makes certain kinds of tasks *SO* deucedly easy (this
> > doesn't necessarily apply to the specific one being discussed
> > here -- this is just a generic musing!-), that the temptation
> > IS serious to just recode it and be done, rather than start
> > looking for an already-almost-there solution out on the web.
>
> Gee, Alex, that was, after all, my point. That is, no matter
> how easy Python makes programming, it's easier to use the code
                                                   ^^^^^
> someone else has already written, if it does what you need, or
> can easily be adapted to do what you need. The other benefit is,

Tut, tut: your point was that it's easy to *FIND OUT* that
someone has already done something you can use -- at least,
that is what you WROTE.  I counter-claim that, in Python,
it's often easier to just write the thing, than it is to
LOOK for already-made solutions.  In other words, I strongly
dispute the claim "nothing's easier than finding out" etc.
I think it's very often HARD to find out about already existing
solutions that you could just reuse or easily adapt.

Not Python's fault - the proliferation of information predates
Python!-).  Even when you find out, "yep there are libraries
X and Y that look like they might include the stuff I need",
determining whether they can be re-used, or EASILY adapted,
still requires downloading it and studying them a while.  If
what you want to do is simple enough, and particularly if it
is slightly atypical, you could maybe have coded it up in an
hour, and it may take you two hours to determine that it's
"just" half an hour's work to adapt existing stuff.. this is
a GAIN?-)  And what if the existing stuff turns out to have
unacceptable licensing conditions, or...?-)

It partly depends on somebody's skill as a Python designer
and coder vs that body's skill as a websurfer and searcher.
I think I'm pretty good at both tasks, and find both fun,
but the ratio of ease and/or fun may well differ for others.


> as you point out, non-proliferation of modules in the same space,
> all of which are just different enough so as to prevent consolidation
> and improvement.
>
> And now, for a bit of heresy, I wonder if there isn't something to
> be said, in addition to the ease of Python, against Python too?

Sure -- I'll start.  The same argument as was made by many in
the Church when the novel and troublesome idea of teaching higher
culture to laymen first surfaced (a bit less than 1,000 years
ago, in Bologna -- accidentally my hometown).  "If we let just
EVERYBODY have this [knowledge/programming-power], they'll just
do WHATEVER they want without our wise guidance for their good!".
This is clearly unacceptable and MUST be squelched.

The Churchmen were right, btw.  From the Alma Mater Studiorum
(official name of Bologna's teaching organization from the 11th
century -- "Universitas" is a rather newer word, also coined here
in Bologna) came the thinkers who told the Emperor his power's
legitimacy did NOT descend from the Pope, sparking centuries of
clashes and wars between Emperors and Popes, ending the relative
quiet of the Middle Ages and fostering the emergence of such
blights as city-states, capitalism, the Renaissance, eventually
the Reformation.  What untold evils might come from the wild
amount of power Python places in users' hands?!  Let's quash
the threat before it becomes too big for us... all power to
the professional programmer!


> Is there less code reuse than there should be and is that a fault
> of Python's? Of Pythoneers? Of lacks in infrastructure (think CPAN
> for Perl, code images in Smalltalk)?
>
> Or maybe my expectations for reuse are too high, or I'm not seeing
> all the reuse that's going on?

Problem number one is that *FINDING OUT* that you claimed
was so easy.  I know of no solution to THAT.  A CPAN-alike
will be of some modest help, the distutils are a BIG help
(will be bigger as more and more "stuff that's out there"
actually USES them:-), but they're all solutions to lesser
problems compared with the huge, stark one of FINDING OUT.


> I have been able to confirm, in the course of reading these lists and
> coding Python for about two years, what a Squeaking Erlanger friend of
> mine, Bijan Parsia, has said about Python for some time: the chief unit
> of Python code reuse and modularity is not the class but the module.

Makes sense.  In a language-independent way, R. Martin long
ago explained that this is exactly as it should be -- all of
his writings are worthwhile and interesting, see specifically
http://www.objectmentor.com/publications/granularity.pdf:
"""
The Reuse/Release Equivalence Principle (REP):
THE GRANULE OF REUSE IS THE GRANULE OF RELEASE. ONLY
COMPONENTS THAT ARE RELEASED THROUGH A TRACKING
SYSTEM CAN BE EFFECTIVELY REUSED. THIS GRANULE IS THE
PACKAGE.
"""

"Package" here is used in the UML sense, and also as
commonly used in Ada and Java -- Martin explains that
he considers the terms equivalent to Booch's “class
category”, Meyer's "cluster", Coad's "subject area",
Shlaer and Mellor's "domain".  One might dispute the
exactness of the equivalence, but "package" as in
Python isn't too far ("module" is fine too, but some
sets of modules are interdependent and released --
thus reused -- as packages...).

The "tracking system" detail up there, related to
the "finding out" issue, is the snag...:-).


Alex