develooper Front page | perl.perl5.porters | Postings from June 2006

Re: Its time we set the score straight on Perl 5 and Perl 6 and debunk our own self-generated FUD.

Nicholas Clark
June 25, 2006 11:55
Re: Its time we set the score straight on Perl 5 and Perl 6 and debunk our own self-generated FUD.
Message ID:
On Fri, Jun 23, 2006 at 07:11:25PM -0400, Randy W. Sims wrote:

> The goal mentioned most often for growing the core is that there are not 
> enough *officially suppported* modules; some companies have a limited 

On Wed, Jun 21, 2006 at 07:04:39PM -0400, Randy W. Sims wrote:

> more sets, the more work to support them. But then, it seems to be much 
> more reassuring to some users, judging from other posts, to have a 
> "supported" set of modules.

"supported" seems to be the key phrase here. The assumption appears to be
that if things go into core, then the world views them as supported.

Which is wishful thinking on behalf of the world.

The reality is that the subscribers of this list provide all that support,
some subscribers more than others, but all subscribers more than nothing.
And all of the subscribers to this list are volunteering their time, and
it's already apparent that the existing core support demands overloads
the current volunteer labour. I'm not even convinced that the current state
is sustainable. I'll repeat the question I asked back in May:

which was quoted in full in the summary

and chromatic mentioned on his O'Reilly blog

yet no-one can answer:

  How do other open source languages, such as Lua, Python, Ruby and Tcl, cope
  with day to day maintenance tasks? Are they all volunteer based, or do they
  have some paid employees, either directly paid for or donated by $language-
  using companies?

Until we can address the issue of how to provide support, all other arguments
for/against more modules in the core are irrelevant.

On Mon, Jun 19, 2006 at 09:17:35PM -0700, Chip Salzenberg wrote:
> On Mon, Jun 19, 2006 at 06:50:14PM -0700, chromatic wrote:
> > On Monday 19 June 2006 18:36, Chip Salzenberg wrote:
> > > You win the thread.  Old software doesn't so much die as creak and grind
> > > slowly to a halt, and that's what's been happening to the users' view of
> > > Perl 5 for a while now.
> > 
> > Did you both *find* and *ask* a user?  'cuz said user isn't me, Chip, Abigail, 
> > Yves, or pretty much anyone reading or responding to this thread.
> Indeed, but that only serves to make my point, albeit in a roundabout way, as
> an illustration of self-selection bias.  Of *course* current Perl users (and
> especially those who participate in p5p) don't care about the slow pace of
> core development, because the ones who -do- care have wandered away, perhaps
> to Ruby or some other language; or, partly due to lack of buzz from friends,
> they never arrived.  Your observation is like holding a vote as to whether
> Thursday night is a good time for meetings, on Thursday night.

That's not a fair argument.

Core development is NECESSARILY SLOW because Perl 5 is a stable language and
backwards compatibility is valued.
The need to release the tension between "New stuff" and "keeping old stuff
working" was one of the big reasons for starting Perl 6.

I forget the exact subversion, or the exact syntax change, but in something
like PHP 5.08 the behaviour of something changed, and the developers' reaction
was "deal with it". Perl would regard any such change in a minor version as
a serious bug.

Perl developers don't suffer from the "Cascade of Attention-Deficit Teenagers"

which is a good thing. JWZ's comment:

  It hardly seems worth even having a bug system if the frequency of
  from-scratch rewrites always outstrips the pace of bug fixing. Why not be
  honest and resign yourself to the fact that version 0.8 is followed by
  version 0.8, which is then followed by version 0.8?

does not apply to Perl 5.

But the next paragraph IS the thrust of this whole message:

  But that's what happens when there is no incentive for people to do the
  parts of programming that aren't fun. Fixing bugs isn't fun; going through
  the bug list isn't fun; but rewriting everything from scratch is fun
  (because "this time it will be done right", ha ha) and so that's what
  happens, over and over again.

What's the incentive for people to keep volunteering to support the Perl core?
The parts JWZ correctly identifies as "not fun"

On Tue, Jun 20, 2006 at 08:37:48AM +0200, demerphq wrote:

> Also moving more commonly used modules into core perl, making the core
> perl experience more usable would improve the lot of many, many, many
> a perl developer who is limited by policy that they cannot form
> dependencies on modules that arent in core. A group that I think is
> much larger and IMO much more important than the "minimal core" types
> realize.

This would require addressing the support argument as above.

For what reason(s) do such policies exist?

On Tue, Jun 20, 2006 at 12:51:19AM +0200, Abigail wrote:

> They are related in the same sense that both Perl6 and Perl5.10 have no ETA.

A fair point that there is no ETA. But who on this list really *needs* 5.10?
I don't think that Rafael's employer, Mandriva, needs 5.10 to get their job
done. Fotango didn't need 5.10 [this had nothing to do with my reasons for

As best I can tell no-one that I interview with in London needed 5.10. 5.8.x
has all the features they need. Heck, I don't even think that any of them
were even running 5.8.8 yet.

There's no push to 5.10 because it doesn't scratch anyone's itch. Perl is
basically good enough to get nearly everyone's job done.

Why do we need 5.10 at all?

On Fri, Jun 23, 2006 at 07:11:25PM -0400, Randy W. Sims wrote:

> to the developer to make sure as product is suitable for use). The only 
> way the task oriented groupings would satisfy these users would be to 
> choose a namespace and close it except to a limited set of "official" 
> task sets, where presumably some committee would decide which sets to 
> produce and which modules make up each task set.
> This seems the best middle of the road solution that could potentially 
> satisfy the minimalist group (me, incl) and the kitchen sink group.

Where are the volunteers for this committee going to come from?

TPF organised a "Perl Day" last year in London. One comment that was common
from the representatives of couple of large perl using firms was this
desire for a larger distribution. Their motivation was that it cost them
lots of money to integrate and validate the modules they wanted internally.
As far as I could see they were (intentionally or unintentionally) angling to
get a free lunch by outsourcing something and removing the cost. I said that
it was hard to pluck volunteers from thin air. They ignored me.

It may only be part of the problem, but a lot of these issues seem to boil
down to the idea that companies want things in the core because they feel
that they are "supported" there, yet these companies using perl don't want
to pay any money for that support. If they want support, ActiveState
provide a product - why not use that? And the perl source is open - there's
nothing preventing any other company providing a supported distribution,
or setting up support of Perl or CPAN modules, on a commercial basis. Yet
none do. Why not?

I can't imagine that these issues are unique to Perl. So how do the other
open source scripting languages resolve them?

How do we resolve them?

Nicholas Clark Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About