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 .msi will start to create this sort of magic and stir some excitement again.
Diversity is the new Uniformity
brian_d_foy on 2008-05-06T12:49:37
Actually, I don't think you get it
:)
You're not diversifying. You're un-difersivify. ActiveState was diversity. It was a different source for Perl and for modules. Now you've made Perl come from the same source everyone else uses and download modules from the same source that everyone else uses.
I think it's that diversity which hurt Perl for a long time on Windows. Instead of having Srawberry Perl ten years ago, we let ActiveState have that domain. With ActiveState, no one had any incentive to work that hard to make Perl installation on Windows as easy as on Unix.
As for the rest of the stuff Andy says, well, it's nothing new, and it's something that goes in cycles. People work independently, then they form groups because its easier to get things done. Wait awhile, and they think the group is holding them back, so they want to be independent again, to restart the cycle.
Just do good work and don't worry about the domain names.
:)
Re:Diversity is the new Uniformity
Alias on 2008-05-06T16:41:39
I hereby note that Strawberry supports CPAN, direct tarball installation via pip, PPM modules/repositories, PAR archives, and the .P5I install scripts, both locally and from URIs.
Instead of just PPMs from a single repository.
Voila, diversity :)
Re:Diversity is the new Uniformity
Ron Savage on 2008-05-07T02:57:00
I haven't tried pip, although I have used Strawbs.
Direct installation from CPAN is a great relief, because without it I was thinking of donating to you $1000 for a build farm and pre-compiled repository, and now you're 'saved' me the money!
As for the command line app, instead of cpan, we're surely call it peter.pan, except neither of our names is Peter :-O.
Re:Diversity is the new Uniformity
chromatic on 2008-05-06T16:46:26
To be fair, it was a huge advantage that there were people interested in Perl who knew how to write code for Windows and actually did.
I've abandoned a few projects because I couldn't get them to run on Windows and was sick of Windows users complaining but never actually trying to help fix things.
Re:Diversity is the new Uniformity
Alias on 2008-05-07T03:17:05
I'll note that the "people interested in Perl who knew how to write code for Windows and actually did" group doesn't really include me.
I am interesting, and I prefer to "actually do", but really I don't know how to write code for Windows.
I muddle through in a couple of areas (like File::HomeDir) but mostly I just bug OTHER people to make their stuff work on Win32. I mean, I didn't create the original Vanilla MinGW setup, I didn't create the original .exe builder, and I didn't do much of the toolchain porting.
All I did was 1) Blatantly copy things from other people 2) Make sure things got built collaboratively 3) Helped with a few communities (IRC, win32.perl.org)
But most importantly, I think the key insight was that if CPAN worked out the box, it would massively shorten the feedback loop. And that feedback loop is everything.
I truly believe just about anyone can work in unfamiliar territory if the response time between them making a mistake, and getting told it is a mistake, is quick enough.
That's really the key to Strawberry. Just making it easier to work on creates this huge iterative cascade of development and improvement on that platform.
The the beauty for me is that, once set up, I do almost none of the work, and still get a ton of the credit :)
Re:Diversity is the new Uniformity
chromatic on 2008-05-07T03:47:09
The the beauty for me is that, once set up, I do almost none of the work, and still get a ton of the credit :)
What I am saying is that -- without taking credit from anyone working on Vanilla, Strawberry, or Chocolate Perl -- ActiveState still deserves tremendous credit for making it possible to run the same code on Windows as Unix and Unix-like systems.
I'll push toward the front of the line for criticizing ActiveState's technical decision to push backwards compatibility and kill all hopes of getting modern CPAN modules in their PPM repository after 5.8.3 or so, but Perl 5.005 remains a huge milestone in modern Perl.
Re:Diversity is the new Uniformity
Alias on 2008-05-08T00:23:30
On this point, I agree completely.
They deserve a lot of kudos for the port, but in the last 5 years they've failed to live up to their previous standards in my opinion.
getting it
markjugg on 2008-05-06T13:48:25
Adam, I think you do "get it", and your work is much appreciated. Thanks!
Mark
Important journal
mr_bean on 2008-05-09T01:28:59
The whole set of blogs connected to Andy Lester's
TIMTOWDI interpretation is a valuable one.
Brian Foy's
crystallization of the difference in viewpoints as "Diversity is the New Uniformity" is apt.
Perhaps we can say the dialectic is one between the new and the old. Old (established) beats new and new beats old. Can't live with it. Can't live without it.
Zbigniew Lukasiak links to an eye-opening Puppet discussion of
ruby gems and other languages' distribution problems, contributed to by Russ Allbery, Jesse Vincent and Adam Kennedy representing the perl camp. Adam is interesting on CPAN.
Someone says perl's distribution strengths there are (partly) due to not having to cope with major release incompatibilities in a connected
blog from a Rails and Linux packager developer.
Re:Important journal
Aristotle on 2008-05-09T11:57:10
I think Perl really benefited from appealing to the sysadmin crowd back when it did. The people who set up CPAN were sysadmins, not programmers, so they approached the question quite differently from the various people who’ve tried to create a CPAN clone for another language in more recent times. Most of them try to recreate everything provided by the entire CPAN infrastructure, and then add even more features, in one fell swoop. Even the CPAN6 project fell into this trap. In contrast, sysadmins tend to abhor complexity and distrust abstractions, so they built CPAN the only way it could work: in layers, each the simplest thing that could possibly work at that point in time. And thus Perl has CPAN and other languages do not.
It’s a bit of a happy accident in some ways… though not an accident at all in other ways.
