Re: Time for a Revolution

[Matisse Enzer]

chromatic wrote:


 produce a short, focused manuscript


This sounds remarkably like a series of technical books the began  
being published in Massachusetts, in the late 70's or early eighties  
- I think they were called the "berry-sized handbooks" or the "nuts  
sell handbooks", something like that. I believe they were wildly  
popular.


---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/





smime.p7s
Description: S/MIME cryptographic signature

Re: Time for a Revolution

[Robert Hicks]

chromatic wrote:

On Friday 14 July 2006 12:27, Jonathan Rockway wrote:



I should be more clear; I'm looking for 10-15,000 word short books on very 
specific areas -- XML Processing with Perl, Writing Ajax Applications with 
Perl, Refactoring Perl, et cetera.  I'm not ruling out a book or discouraging 
people from submitting book ideas, just pointing out that it's much easier 
and faster to write and produce a short, focused manuscript than a large 
project.


-- c
That would be cool. Haven't "short" focused hot topical books on various 
subjects. It would be really good for new users of Perl.


:Robert

Re: Time for a Revolution

[Adam Kennedy]

Why? Oh, why do people lately insist on offering up enticing tidbits of 
/what is to be the next great ordained (core|6pan|etc)/ without offering 
the community a chance to comment or participate? =(


Randy.


Well, in this case two reasons.

Firstly, although I have what I hope is a tentative mandate from Larry, 
I'd like to be sure I'm not obviously and completely wrong first.


And secondly, because even if I was ready to consult with the community 
about it (and don't worry, I most certainly will) I _right_now_ don't 
have the time to actually hold a detailed technical conversation over 
the length of a whole thread... or at all really.


And in a month, I should.

If I were to go into detail now, it would be vapour or the conversation 
would be noisy. If I just did a simple overview, I'd be pressed for details.


So for me at least, the only feasible methodology I've found to get a 
decent result is.


1. Think to myself
2. Proof of concept for myself
3. Consult with experts (here etc)
4. Realise my ideas sucked and revise them
5. Proof of concept for experts
6. Implement
7. Release to public

So yes, you'll be consulted.

That is all :)

Adam K

Re: Time for a Revolution

[Randy W. Sims]

Adam Kennedy wrote:
Unlike what others said, "core" perl shouldn't be the vehicle for 
this, most likely, given the more stringent support and backwards 
compatibility.  We want to be able to change the composition of 
"PerlPlus" overtime, and once things go into core, they're pretty stuck.


I should note for the record that the concept of "core" has only about 6 
months left to live.


I had a chat with Larry at the YAPC hackfest about solving this problem 
more thoroughly for Perl 6 (and back-porting the solution to Perl 5), 
and I think we are in agreement. So I'll be dealing with this general 
area (core, preferred sets of modules) starting with perlmodlib and 
working outwards, in about a month when my main work project is slowing 
a bit and I have more than just a spare 10 minutes to reply to mailing 
lists.


Why? Oh, why do people lately insist on offering up enticing tidbits of 
/what is to be the next great ordained (core|6pan|etc)/ without offering 
the community a chance to comment or participate? =(


Randy.

Re: Time for a Revolution

[Adam Kennedy]

Unlike what others said, "core" perl shouldn't be the vehicle for this, 
most likely, given the more stringent support and backwards 
compatibility.  We want to be able to change the composition of 
"PerlPlus" overtime, and once things go into core, they're pretty stuck.


I should note for the record that the concept of "core" has only about 6 
months left to live.


I had a chat with Larry at the YAPC hackfest about solving this problem 
more thoroughly for Perl 6 (and back-porting the solution to Perl 5), 
and I think we are in agreement. So I'll be dealing with this general 
area (core, preferred sets of modules) starting with perlmodlib and 
working outwards, in about a month when my main work project is slowing 
a bit and I have more than just a spare 10 minutes to reply to mailing 
lists.


Adam K

Re: Time for a Revolution

[Chris Dolan]

On Jul 14, 2006, at 8:03 PM, chromatic wrote:


On Friday 14 July 2006 17:59, Andrew Savige wrote:


I thought Chromatic might be the name of chromatic's father or older
brother.


No, that's Mixolydian and Ionian, respectively.

-- c

(Yes, of course my mother is Dorian.  What were you thinking?)


Whoa, this is becoming an unexpectedly educational thread...
Chris

--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Re: Time for a Revolution

[chromatic]

On Friday 14 July 2006 17:59, Andrew Savige wrote:

> I thought Chromatic might be the name of chromatic's father or older
> brother.

No, that's Mixolydian and Ionian, respectively.

-- c

(Yes, of course my mother is Dorian.  What were you thinking?)

Re: Time for a Revolution

[Andrew Savige]

--- Nicholas Clark wrote:
> On Sat, Jul 15, 2006 at 08:36:54AM +1000, Andrew Savige wrote:
> > Who's Chromatic?
> 
> And it wasn't even the start of a sentence. :-)
> 
> [When doing the perl 6 summaries, Piers reconciled the forces of accuracy and
> traditional grammar by ensuring by always rephrasing to some sentence order
> that didn't start with "chromatic"]

I thought Chromatic might be the name of chromatic's father or older brother.

/-\







 
On Yahoo!7 
Messenger - Make free PC-to-PC calls to your friends overseas. 
http://au.messenger.yahoo.com 

Re: Time for a Revolution

[Nicholas Clark]

On Sat, Jul 15, 2006 at 08:36:54AM +1000, Andrew Savige wrote:
> --- Clayton O'Neill wrote:
> > I think a core difference between your list and Chromatic's is that
> > yours would be part of the standard library in a lot of languages,
> > whereas Chromatic seems to be aiming more for things that would be
> > part of the language.
> 
> Who's Chromatic?

And it wasn't even the start of a sentence. :-)

[When doing the perl 6 summaries, Piers reconciled the forces of accuracy and
traditional grammar by ensuring by always rephrasing to some sentence order
that didn't start with "chromatic"]

Nicholas Clark

Re: Time for a Revolution

[Andrew Savige]

--- Clayton O'Neill wrote:
> I think a core difference between your list and Chromatic's is that
> yours would be part of the standard library in a lot of languages,
> whereas Chromatic seems to be aiming more for things that would be
> part of the language.

Who's Chromatic?

/-\







 
On Yahoo!7 
Messenger - Make free PC-to-PC calls to your friends overseas. 
http://au.messenger.yahoo.com 

Re: Time for a Revolution

[Clayton O'Neill]

On 7/14/06, H.Merijn Brand <[EMAIL PROTECTED]> wrote:

Look at the list of modules I include in my perl distributions for HP-UX at
http://mirrors.develooper.com/hpux/#Perl and you might get an idea of what
I think are useful modules that my work more effective. Not quite like yours
is it?


I think a core difference between your list and Chromatic's is that
yours would be part of the standard library in a lot of languages,
whereas Chromatic seems to be aiming more for things that would be
part of the language.  Not to disparage your list, but I think his is
oriented more towards higher level abstractions, whereas yours is more
task oriented.

Because of that, I don't really see the dichotomy as strongly as you.
I think you can argue over which inside out object module to use, but
that's a different sort of argument than whether or not XPath or SOAP
support should be included in core, or some PerlPlus bundle.  At least
it seems that way to me.

Re: Time for a Revolution

[chromatic]

On Friday 14 July 2006 12:27, Jonathan Rockway wrote:

> A book like this is something that's been in the back of my mind for a
> while.  If there were real interest in this topic (and I think there
> is), I would be happy to help out in a significant way, like writing
> several chapters.
>
> If someone is interested, maybe we can hash out a ToC / outline and
> submit a proposal to O'Reilly?  That would be pretty neat :)

I should be more clear; I'm looking for 10-15,000 word short books on very 
specific areas -- XML Processing with Perl, Writing Ajax Applications with 
Perl, Refactoring Perl, et cetera.  I'm not ruling out a book or discouraging 
people from submitting book ideas, just pointing out that it's much easier 
and faster to write and produce a short, focused manuscript than a large 
project.

-- c

Re: Time for a Revolution

[Jonathan Rockway]

Or, perhaps we need the "Perl CPAN Cookbook" -- which would be like the
Cookbook but focuses *only* on the greatest-hits modules across all the
same categories.  If CPAN is one of Perl's greatest strengths, shouldn't
that get more attention, too?


Er, right.  Now let me don my editor hat.

Authors welcome!
  
A book like this is something that's been in the back of my mind for a 
while.  If there were real interest in this topic (and I think there 
is), I would be happy to help out in a significant way, like writing 
several chapters.


If someone is interested, maybe we can hash out a ToC / outline and 
submit a proposal to O'Reilly?  That would be pretty neat :)


Regards,
Jonathan Rockway

Re: Time for a Revolution

[chromatic]

On Friday 14 July 2006 08:18, David Golden wrote:

> Or, perhaps we need the "Perl CPAN Cookbook" -- which would be like the
> Cookbook but focuses *only* on the greatest-hits modules across all the
> same categories.  If CPAN is one of Perl's greatest strengths, shouldn't
> that get more attention, too?
>
> Or, perhaps, to break up or both Cookbook into individual books covering
> certain topics in more depth.  This might be good for O'Reilly's PDF
> book series -- low cost and easy to update over time.
>
> More generally, I think Perl needs to be focusing on how it helps people
> get stuff done faster/cheaper/better -- task focused, not tool focused
> -- and in areas where there is buzz and excitement.  E.g. "Writing AJAX
> applications in Perl".

Er, right.  Now let me don my editor hat.

Authors welcome!

-- c

Re: Time for a Revolution

[David Golden]

chromatic wrote:
Why is there not a Bundle::PerlPlus (and yes, I've lathered up my yak with 
that name) that downloads and installs the modules that should have been in 
the box?


For one, that should be "Task::PerlPlus".  :-)

Second, for any pre-packaged distribution like Strawberry Perl (see 
vanillaperl.com), adding in the "must have" modules is pretty easy.  One 
of the goals of the Vanilla Perl project is to get win32 Perl to a point 
where we can offer an "end-user" Perl with all the best modules already 
installed.


Unlike what others said, "core" perl shouldn't be the vehicle for this, 
most likely, given the more stringent support and backwards 
compatibility.  We want to be able to change the composition of 
"PerlPlus" overtime, and once things go into core, they're pretty stuck.


But I concur with others that that the issue is awareness and usage, not 
installation.  We need an easily accessible way for people to learn that 
there are some best modules along with best practices.  (And thank you, 
Damian, for encluding lots of module recommendations in that book.)


One idea I had is that we need a new edition of the Perl Cookbook, with 
new recipes that cover not only how to use core built-ins and modules, 
but that highlight some of the best CPAN modules for certain tasks as 
well.


Or, perhaps we need the "Perl CPAN Cookbook" -- which would be like the 
Cookbook but focuses *only* on the greatest-hits modules across all the 
same categories.  If CPAN is one of Perl's greatest strengths, shouldn't 
that get more attention, too?


Or, perhaps, to break up or both Cookbook into individual books covering 
certain topics in more depth.  This might be good for O'Reilly's PDF 
book series -- low cost and easy to update over time.


More generally, I think Perl needs to be focusing on how it helps people 
get stuff done faster/cheaper/better -- task focused, not tool focused 
-- and in areas where there is buzz and excitement.  E.g. "Writing AJAX 
applications in Perl".


Regards,
David

Re: Time for a Revolution

[H.Merijn Brand]

On Fri, 14 Jul 2006 07:45:55 -0400, "Clayton O'Neill" <[EMAIL PROTECTED]>
wrote:

Why off-list? this is a good reaction.

> On 7/14/06, H.Merijn Brand <[EMAIL PROTECTED]> wrote:
> > Look at the list of modules I include in my perl distributions for HP-UX at
> > http://mirrors.develooper.com/hpux/#Perl and you might get an idea of what
> > I think are useful modules that my work more effective. Not quite like yours
> > is it?
> 
> I think a core difference between your list and Chromatic's is that
> yours would be part of the standard library in a lot of languages,
> whereas Chromatic seems to be aiming more for things that would be
> part of the language.  Not to disparage your list, but I think his is
> oriented more towards higher level abstractions, whereas yours is more
> task oriented.

Probably correct.

> Because of that, I don't really see the dichotomy as strongly as you.
> I think you can argue over which inside out object module to use, but
> that's a different sort of argument than whether or not XPath or SOAP
> support should be included in core, or some PerlPlus bundle.  At least
> it seems that way to me.

IMHO none of those should be included in the core at all. It should be made
easier to *add* them after the core is installed. Either by a website or a
GUI or whatever. Select the box "OO programming" choose "functionality", tick
all that apply, and hit [Install]. If that script/site calls 'curl ...' or
'perl -MCPAN ...' or "frobnicator2 ...' is not of any interrest to me at this
point.

If I'm not mistaken, there has been a lot of effort to enable inside-out
objects in perl-5.9 from the core side of view. So it is being appreciated
that people want it. Not that I am likely to ever use it, but that is not
being discussed here.


-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x  on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin.   http://qa.perl.org
http://mirrors.develooper.com/hpux/   http://www.test-smoke.org
   http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Time for a Revolution

[H.Merijn Brand]

On Thu, 13 Jul 2006 23:52:02 -0700, chromatic <[EMAIL PROTECTED]> wrote:

> On Thursday 13 July 2006 23:37, H.Merijn Brand wrote:
> 
> > If I got it right, the wish that was expressed is more like the wish for
> > an installer with a GUI.
> 
> Nope, just for a nice, easily-installable bundle of modules that work around 
> the unpleasant backwards compatibilities and warts of Perl 5.

I was talking about the wish of the person I talked to. Not your wish :)
But your exposition makes some things quite clear.

> For example, I use SUPER a lot because it's completely silly that the method 
> redispatcher works based on the stash of the subroutine, set to its compile 
> time package, not on the current class and method name.
> 
> I'm warming up to Class::MOP because I'm tired of fiddling with package 
> variables and symbolic references to deal with @ISA.
> 
> It would include a profiler that actually works, unlike Devel::DProf which, 
> as 
> far as I can tell, is a Perl module to segfault.
> 
> It would include File::Find::Rule because it has an interface less prone to 
> face-stabbing than File::Find, which is only in the core because it's been in 
> the core forever, not because its interface is nice (it isn't) or the code is 
> nice (it really isn't).
> 
> It would include Class::Std or Object::InsideOut or one of those because it's 
> about time Perl encouraged people to write classes that make sense.
> 
> It would include documentation about which modules I chose and why and when 
> to 
> use them.
> 
> That's what I want -- the useful modules that aren't in the core that do 
> things that should have been in the language for the start but weren't.  In 
> other words, it's the modules I use all the time to be productive.

For *you* to be productive. For *me*, I would see all that as bloat. I *hate*
OO programming. Not only in Perl. It is that DBI and Tk have no alternatives,
so I have to do some OO, but it still does not feel like the FUN I get out of
the other corners of the many perl features

> Novices shouldn't have to spent eight years learning the language and the 
> good 
> modules the way I did to be productive.

What makes someone productive? They want to get the job done. If they only
convert CVS to MS-Excel or vise-versa, they will never ever need all the
things you mention. If they want to set up a simple web page with MySQL and
DBI, they don't need it either.

I cheer your plan. Really I do, but then there should be targetted bundles.
Not 'Plus' or 'Extra'. What is Plus for one is Minus or Bloat for others.

Look at the list of modules I include in my perl distributions for HP-UX at
http://mirrors.develooper.com/hpux/#Perl and you might get an idea of what 
I think are useful modules that my work more effective. Not quite like yours
is it?

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x  on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin.   http://qa.perl.org
http://mirrors.develooper.com/hpux/   http://www.test-smoke.org
   http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Time for a Revolution

[chromatic]

On Thursday 13 July 2006 23:37, H.Merijn Brand wrote:

> If I got it right, the wish that was expressed is more like the wish for
> an installer with a GUI.

Nope, just for a nice, easily-installable bundle of modules that work around 
the unpleasant backwards compatibilities and warts of Perl 5.

For example, I use SUPER a lot because it's completely silly that the method 
redispatcher works based on the stash of the subroutine, set to its compile 
time package, not on the current class and method name.

I'm warming up to Class::MOP because I'm tired of fiddling with package 
variables and symbolic references to deal with @ISA.

It would include a profiler that actually works, unlike Devel::DProf which, as 
far as I can tell, is a Perl module to segfault.

It would include File::Find::Rule because it has an interface less prone to 
face-stabbing than File::Find, which is only in the core because it's been in 
the core forever, not because its interface is nice (it isn't) or the code is 
nice (it really isn't).

It would include Class::Std or Object::InsideOut or one of those because it's 
about time Perl encouraged people to write classes that make sense.

It would include documentation about which modules I chose and why and when to 
use them.

That's what I want -- the useful modules that aren't in the core that do 
things that should have been in the language for the start but weren't.  In 
other words, it's the modules I use all the time to be productive.

Novices shouldn't have to spent eight years learning the language and the good 
modules the way I did to be productive.

-- c

Re: Time for a Revolution

[H.Merijn Brand]

On Fri, 14 Jul 2006 01:25:51 +0200, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:

> * chromatic <[EMAIL PROTECTED]> [2006-07-14 00:55]:
> > Sure, but it's only one thing people need to remember.  One
> > thing is easier than N things, especially as N changes every
> > time the core changes.
> 
> Yes, I agree. Don’t get me wrong, I’m not saying Bundle::PerlPlus
> is a bad idea (though in adding a grain to the sandpile it *can*
> have a detrimental effect).
> 
> I’m just saying that I don’t see how it will achieve the purpose
> for which you proposed it. Sure would be handy, but will hardly
> single-handedly rejuvenate Perl.

I've been talking with someone who has to learn perl over and over again,
because this poor person forgets the details because perl is not used on
a daily basis.

If I got it right, the wish that was expressed is more like the wish for
an installer with a GUI. Let's assume YaST2 or so. The interface should
be able to show package groups (Graphic, Development, Databases, Network,
Math, ...) and squares to tick: I want this module installed. The install
program should then automatically tick all the modules it needs to make
the install happen.

At this point the user should not want to know if it is *possible* that
this module *can* be installed at all (at least that is what that user
told me). e.g. DBD-Pg needs DBI, but there is no Postgres installed.

I for one would shed no tear if CGI would be removed from the CORE, and
I will bet that most of you would cheer if all formatting related stuff
would be removed from the CORE, which I use heavily on a daily basis.

We have to realize that one person's PerlPlus necessities are not the
same as someone else's. We - as seasoned perl users/programmers - quite
often assume too much, and think too technical in ways of things to be
possible or not. That is not how our target audience perceives it.

I hope I have expressed the conclusion of that chat correctly. But it
*does* make sense to me.

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x  on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin.   http://qa.perl.org
http://mirrors.develooper.com/hpux/   http://www.test-smoke.org
   http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Time for a Revolution

[A. Pagaltzis]

* chromatic <[EMAIL PROTECTED]> [2006-07-14 00:55]:
> Sure, but it's only one thing people need to remember.  One
> thing is easier than N things, especially as N changes every
> time the core changes.

Yes, I agree. Don’t get me wrong, I’m not saying Bundle::PerlPlus
is a bad idea (though in adding a grain to the sandpile it *can*
have a detrimental effect).

I’m just saying that I don’t see how it will achieve the purpose
for which you proposed it. Sure would be handy, but will hardly
single-handedly rejuvenate Perl.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Time for a Revolution

[chromatic]

On Thursday 13 July 2006 15:40, A. Pagaltzis wrote:

> People would install these modules anyway even if they
> never get into core or a Bundle::PerlPlus, if they knew that
> these modules are important to them in the first place.

That's really the point.  Instead of saying, "Go install X and Y and Z 
and...", wouldn't it be easier to say "Go install Bundle::FOO and you'll get 
everything, including documentation on which is there and why"?

> Which just goes to show: we need more effective ways to educate
> people. Bundle::PerlPlus would wouldn’t change anything
> fundamental about the big picture – some people would know about
> it, some wouldn’t, and as far as beginners are concerned, it
> would be just one more grain on the huge sandpile of accreted
> knowledge about good development practices in Perl.

Sure, but it's only one thing people need to remember.  One thing is easier 
than N things, especially as N changes every time the core changes.

-- c

Re: Time for a Revolution

[A. Pagaltzis]

* chromatic <[EMAIL PROTECTED]> [2006-07-13 23:25]:
> On Thursday 13 July 2006 13:32, A. Pagaltzis wrote:
> >I thought that’s called “the core distribution.” NEXT is
> >already in there. So is List::Util (a big deal for me).
> 
> Maybe for Perl 5.9.x... but how long will it be between someone
> realizing "Hey, SUPER should have been in Perl 5 from the
> start" and SUPER getting into Perl 5.9.x or Perl 5.11.x or Perl
> 5.13.x and eventually making its way into everyone's toolbox?

As I said, I don’t think that’s the core problem. (No pun
intended.) People would install these modules anyway even if they
never get into core or a Bundle::PerlPlus, if they knew that
these modules are important to them in the first place.

Conversely, there are lot of gems in core that noone uses;
perlmodlib is so large at this point that it’s worth periodically
poring over even (in fact, PARTICULARLY) if you’ve been a Perl
programmer for a decade, and even if you didn’t upgrade your Perl
since last time you looked at the list, simply because there’s
*so* *much* stuff in there by now that noone can memorise that
entire kitchen sink.

Which just goes to show: we need more effective ways to educate
people. Bundle::PerlPlus would wouldn’t change anything
fundamental about the big picture – some people would know about
it, some wouldn’t, and as far as beginners are concerned, it
would be just one more grain on the huge sandpile of accreted
knowledge about good development practices in Perl.

> It's a lot faster and easier to roll a new
> Bundle::TheMissingModules than it is to expect people to
> upgrade to a new stable major version, especially if it's more
> than a year between new stable major versions.

Hadn’t someone proposed a while ago to make per-Perl-version
bundles for all the dual-lived core modules or something vaguely
like that? I think the motivation was similar, too.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Time for a Revolution

[Ian Langworth]

On 7/13/06, chromatic <[EMAIL PROTECTED]> wrote:


Why is there not a Bundle::PerlPlus (and yes, I've lathered up my yak with
that name) that downloads and installs the modules that should have been in
the box?


Sure, a Bundle::PerlPlus would be fun. Installing it wouldn't be.

Perl module installation is tough. There are a lot of modules that do
a lot of different things. There are a handful of ways to install all
of those modules. There are a number of module installation modules.
These modules may be pure-Perl or require compiling. What there isn't
is:

  $ curl go.cpan.org | sudo perl
  > install Foo
  > quit
  $ perl -MFoo ...

Exploring and using CPAN modules isn't fun. CPAN asks way too many
users for the casual explorer, plus try explaining to them how to
install a module locally. I'm not saying that this is a trivial
problem or that it's easy to solve. I'm saying that to rope people in
it's got to be Dead Fricking Simple.

--
Ian Langworth

Re: Time for a Revolution

[chromatic]

On Thursday 13 July 2006 13:32, A. Pagaltzis wrote:

> I thought that’s called “the core distribution.” NEXT is already
> in there. So is List::Util (a big deal for me).

Maybe for Perl 5.9.x... but how long will it be between someone 
realizing "Hey, SUPER should have been in Perl 5 from the start" and SUPER 
getting into Perl 5.9.x or Perl 5.11.x or Perl 5.13.x and eventually making 
its way into everyone's toolbox?

It's a lot faster and easier to roll a new Bundle::TheMissingModules than it 
is to expect people to upgrade to a new stable major version, especially if 
it's more than a year between new stable major versions.

-- c

Re: Time for a Revolution

[A. Pagaltzis]

* chromatic <[EMAIL PROTECTED]> [2006-07-13 21:10]:
> Why is there not a Bundle::PerlPlus (and yes, I've lathered up
> my yak with that name) that downloads and installs the modules
> that should have been in the box?

I thought that’s called “the core distribution.” NEXT is already
in there. So is List::Util (a big deal for me).

The problem is how to get neophytes clued in quickly that these
are the modules they need to make Perl into more of the language
they should be using.

It isn’t just the modules, you know.

Few beginners are indoctrinated to use lexical filehandles and
three-arg `open` from the very beginning.

Even the reflexive use of narrowly scoped lexical variables is
not something they are conditioned to early on – really
unfortunate, since there are s many classes of bugs you
simply won’t run into if you don’t keep variables around. Eg.
I can count on my fingers the number of times that I’ve had to
explicitly clear a populated array within a loop. I almost never
even need to think about such issues, it all works out correctly.
And the code is shorter too.

Knowledge like that isn’t available to `cpan -i`.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;