develooper Front page | perl.perl5.porters | Postings from July 2001

Re: Asking for a reprieve on new core modules (was Re: Case for XML-RPC)

From:
Brian Ingerson
Date:
July 17, 2001 16:11
Subject:
Re: Asking for a reprieve on new core modules (was Re: Case for XML-RPC)
Message ID:
20010717151805.C16386@ttul.org
Hi guys. Thanks for including me on this. As Schwern knows I have
plenty of strong feelings about putting modules in the core. My
basic philosophy is "don't". I'll try to expound in my responses to
this thread.

On 17/07/01 14:31 -0400, Michael G Schwern wrote:
> On Tue, Jul 17, 2001 at 12:00:27PM -0600, Nathan Torkington wrote:
> > *** Why should XML-RPC be in the core? ***
> > 
> > Once XML-RPC is a standard part of the core, we can begin to
> > integrate networked services with standard Perl tools.
> 
> Of course, you can do this already, with or without it being in the
> core. Putting XML::RPC into the core will *appear* to make it easier,
> but the problem is you have to assume everyone's going to be using
> 5.8.0 (or 5.8.1 more likely).  That should be a safe assumption
> somewhere around 2003. I'm not exagerating, 5.005_03 was out in 1999
> and that's as far forward as I'm daring to assume people have
> installed.

There is a bell curve of Perl users, the bulk of which fall under
5.005_03 (a Perl sweet spot) and 5.6.0. This curve moves along through
time, but experience shows us that the movement is measured in years.
Decisions should be made that will help the most people, so it's
important to view things in terms of actual usage.

One good thing is that Sarathy seems to have added very few modules to
the core, so our current bell curve state is rather homogeneous. I think
we should make decisions to take advantage of that.

There are solutions to making modules easily available besides adding
them to core. And they don't have the pitfalls of doing so. I have a
number of ideas and I am collectively includig them under a project I
call NAPC.

> What this really is is a general argument against putting modules into
> the core that aren't *really* important.  Anyone who was at Ingy's
> CPAN talk at YAPC knows the arguments, I'm not going to rehash them
> here.

Here are a few:

1) Release latency - Bug fixes and enhancements come out once a year. Even
though you can release the module sooner, it no longer has the advantage of
being in the core.

2) Bitrot - Once something is in the core it seems to often stay in the same
state. It's as if the author thinks, "I've finally made it"

3) Effect - Putting a module into 5.8.0 really won't have a substantial
effect for a couple years. *If* solutions can be found to benefit all Perls,
those are the ones we should implement.

4) Non competition - Who at this point could write a better CGI module and
ever expect it to gain acceptance? I think this *is* possible if we refactor
the problems correctly.

5) Predjudice - Only certain authors are in a social position to get the
attention of the P5P. Regardless of the quality of there work, it takes a lot
of time and personal marketing to get noticed.

6) Stigma - Modules that have non-core dependencies just don't get deployed
as much as they otherwise would. Having different core modules at many
well-used Perl versions only compounds the issue.

7) One way ticket - As Schwern points out below, the decisions are hard to go
back on. Or are they? Read on ;)

8) Dog food - On a personal note, I will never put Inline into the core. I
can acheive the same effect with other methods. This is no longer 1995. It's
time to reassess CPAN issues, in the light of what we have now.

> We're working on a few new things that will make depending on CPAN
> modules much easier (NAPC and par), concrete designs will come at TPC
> with a prototype at YAPC::Europe.  So what I'm asking for here is a
> reprieve.  Hold off on putting anything new into the core (its too
> late for 5.8.0 anyway) until after YAPC::Europe and we may be able to
> slacken the temptation to bundle My Pet Module with Perl.

I also have a strong philosophy regarding momentum. In Perl, one
person's ideas should not impede another person's. Nor should it require
the cooperation of another. Of course, it always helps to be
collaborative, but we all have only so much time to invest into this.

That said, I somewhat disagree with this request for reprieve. The P5P
should do what it thinks is best for the time being. If NAPC happens
the way I picture it, it will not even matter what modules are in the
core. It will merely solve the problems listed above if people choose
to use it. And if it "just works" people *will* use it. If it turns out
to be complete hype/bunk, then we haven't squandered anyone else's
valuable time.


> Remember, once you put a module into the core you can *NEVER* get it
> out.

Yes, but if one day the CPAN is simply available on demand, all of these
issues will just flake off like dead skin, and we'll wonder what the big
deal ever was :)

---

So what is NAPC? I won't tell you what it stands for, because it means over a
dozen things at current. Use your imagination...


The idea is basically that when someone builds a module for a particular
platform, the result can be shared to any other Perl running under similar
conditions. Of course, this varies per module. Think of it as the community
building PPM repositories for every single platform that is in use.

Benefits?

1) PPM(esque) installs are fast. They can actually be done seamlessly on
   demand (ala Inline), if a user opts into that. So it's (potentially)
   like having the entire CPAN installed and up to date at all times.

2) Places the burden of build automation on the entire community, rather
   than one organization or small dedicated group.

3) Modules don't need to be tested with administrative permissions as is
   often the case with CPAN.pm. Unlike PPM, users will still be able run
   test suites before (or after) installation.

4) All kinds of good stuff can be piggybacked onto this. Kwality
   assurance and module rating for example.

If this raises a boggling number of questions in your mind, it should.
But a lot of this has already been hashed out by many of the better
minds at YAPC. Let's continue the discussion/implementation at the
upcoming conferences.

Cheers, Brian




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About