All the Perl that's Practical to Extract and Report
use Perl Log In
acme (189)
(email not shown publicly)
http://www.astray.com/
Leon Brocard (aka acme) is an orange-loving Perl eurohacker with many varied contributions to the Perl community, including the GraphViz module on the CPAN. YAPC::Europe was all his fault. He is still looking for a Perl Monger group he can start which begins with the letter 'D'.
Perl 5 day summary
A few weeks ago I attended a Perl 5 day organised by the Perl Foundation and I promised to summarise the day. It's hard to summarise a day-long meeting with no agenda. We were around 25 people; split about half way core Perl developers and large enterprises which use Perl. Choice fact: the BBC serves around 2k requests per second with mod_perl. An enterprise is multiple people working together with people coming and going so standard interfaces are required: looks like Damian's Perl Best Practices will help here.
Packaging seems to be a major problem for large companies. Many ideas were thrown around based upon "blessed stable CPAN modules" (like Activestate Perl) but enterprises need certain specific things, not old stable modules. The struggle between needing the stable and needing the newest version of a module or perl came up a few times. There is no good way to solve this, although creating flexible packaging tools might help. Of course, once you start packaging CPAN modules, you also start caring about the C libraries and external programs they depend on...
For perl 5.10 one of the original plans was to throw all the modules out of the core (keeping the bare minimum needed to install modules) and moving the modules into a seperate SDK. This helps the core size be small and portable and makes it easier to upgrade modules in the SDK (but more maintenance work and testing for the SDK). This idea was brought up again. Also that we need more volunteers to handle perl bug triaging.
Volunteers are always a short supply, but it did seem odd that there were some companies there which are making millions, if not billions, of pounds a year with Perl and yet they turn up to the Perl Day to complain about something that they could easily have hired a core Perl person or pumpkin to do. The Perl Foundation isn't Perl, Perl is what you make it
Overall lots of talk and not many action points, which is a shame as I'm an action kinda person.This post was brought to you with the cry of the yellowhammer bird...
--Larry Wall in stab.c from the perl source code
Thanks! (Score:1)
Here in Seattle I'm pimping Damian's book. When one writes Perl as a profession, they should stick to the guidelines. There's still room for Perl-as-art, but we have a common foundation that's not di
The great thing about multitasking is that several things can go wrong at once.
you could have (Score:2)
written that 10 years ago or 2 days ago for all that has changed since then. Ah, the joys of enthusiasm for an SDK that gets shot down nearly every time it comes up.
And CPAN wouldn't be such a collossal pain in the ass if more/better/complete metadata would be included with each distribution, but I suppose that, too, has fallen by the wayside.
Why would/should people give money to an organization that seems to be unable to fund the very problems that have needed fixing for 10 years or more and instead
Re:you could have (Score:2)
I think because TPF doesn't have a specific core engineering remit, and hasn't thought it needed to, for a couple of reasons. Firstly because for most of Perl 5's life Perl 5 development has done just fine thanks to patronage offered by various