Andy Lester on PerlBuzz...
Adam Kennedy's Strawberry Perl is a marvel of the principles [decentralize, diversify and colonize] I've talked about. Strawberry decentralizes, as it uses none of the core perl.org infrastructure, and it diversifies and colonizes by giving Windows users an alternative to ActivePerl, which for many users is not robust enough. When people talk about Strawberry Perl, it helps with mindshare as well.
For me, Strawberry is a combination of three principles, triggered by one specific annoyance.
The (continuing) annoyance was the vast swathes of CPAN that simply don't work on ActivePerl, for utterly stupid reasons.
CPAN is one of the two unique selling points for Perl, and as the sole gatekeeper for CPAN to their entire userbase, ActiveState was in a position of great responsibility. And by neglecting their PPM repository, they've neglected all of us.
This came to a head for me when (as I see it) ActiveState damaged my PPI OSCON talk by not letting me run the super-shiny PPI::Tester application during the talk live, because they wouldn't build my modules.
Diversity in this case is most needed when the "one true solution" starts to get stale or rusty. ActivePerl, use.perl.org and several other areas of the Perl universe of clearly sub-optimal and annoying people enough that the additional variation is a boon.
When the gatekeepers of the "one true solution" are responsible and responsive, like Graham with his proprietary search.cpan.org, it makes it much easier to live with that control, because it is not damaging.
Once I'd decided that I needed a Perl distribution, what I'll (for the purpose of this post at least) call the "Principle of Familiarity" kicked in. Perl's second unique selling point is it's universality. It's available EVERYWHERE, even in places that are unexpected.
In Oslo at the Go Open conference, we had quite a long conversation with a recent graduate that's working on Big Iron VMS stuff, where he says Perl is pretty much still THE utility language.
Perl availability by default on every Unix is still a huge win, and only in the embedded arena do we struggle (witness the tortured and epic efforts by the OLPC people to remove Perl from the OLPC computers to save storage space).
We don't treat this with the respect it deserves. There's a lot to be said for omnipresence as a feature, but it's even more powerful when you aren't just present everywhere, but when you are the SAME everywhere. Just ask McDonalds.
I hate most McDonalds food, but when I'm fresh off the plane in a new country and don't quite have the time to invest in discovering the local cousine, even I head there as a convenient default.
So clearly having Windows Perl not just work, but work exactly the same, would yield major benefits.
The real importance of this for me though came about from chance comment by Steffen Mueller when he was visiting in Australia.
He mentioned at some point that he'd whipped up a simple script in a day or so that sucked some data out a legacy system, stuffed it into an Excel spreadsheet, and emailed it to some middle management or marketing types. Not only did they adore it, but were astounded it was done so fast. And it ran on Windows.
What it made me realise was that for so many people stuck in corporate Windows land, the creation of random utility functions is still annoying and slow.
There's never been a simple utility language that stuck around over time from Microsoft, because they keep breaking them or removing them for the next big thing. And getting access to the "Don't need to talk to procurement, don't need to justify ROI" benefits of Open Source software has always been tricky, because there a good equivalent of "apt-get install whatever" for Windows either.
That MASSIVE group of people is just screaming out for a utility language that is compact, easy to install, easy to procure libraries for just about anything for, and won't disappear out from underneath them when Microsoft decides to release a new version.
And what I realized is that Perl has the potential to tick all these boxes, plus it also works on every other operating system. Perl could be the ideal corporate duct tape, just as it was for a long time the ideal unix duct tape as well, if only it was presented correctly.
Finally, I've tried to put a lot of effort into a "Strawberry Experience", which is a horridly marketing way of saying I'm trying to reduce the amount of thinking and learning needed everywhere I can, starting with the Strawberry Perl website. It's intended to be both extremely low-maintenance for me, and be as simple and elegant as I can make it about explaining the core message to Unix Perl programmers (who are the primary users of Strawberry).
The CPAN client is zero-configuration, because it has grown over time to become unapproachably large. Seriously, why the fuck should everyone be forced to set their build cache in megabytes, or what COLOUR SCHEME they want for the command line client. Sure they can go with defaults, but we still force them to read about them.
Andy praises strawberry for not using the perl.org services, but really, having http://cpan.strawberryperl.com/ is primarily just a way to have people not have to select their continent, then country, then a mirror, which could go stale later anyways. At least this way I can bounce people to mirrors that I know are good.
It also gives me a hugely valuable stream of data on what people actually install from CPAN. Or rather, what the people that prefer to just stick with the default settings install, so I know what modules are the biggest priorities for bundling by default.
Perl on a Stick is the next extension of this push towards playing to Perl's joint strengths of Omnipresence and CPAN.
We've only just begun to tap into the market of casual programmers that don't know Perl isn't cool, but just want to "Get Shit Done" easily.
My hope is that the combination of Chocolate Perl (which is aimed at Perl newbies) + Perl on a Stick plus