Monday, July 27, 2009

Perl's popularity problem...

There has been a recent flurry of blogs on Perl's perceived popularity problem:


I'm a little cynical. Many good insights and areas for improvement are identified. But Perl needs to gain mindshare. And the only way to do that is to deliver the goods: Perl needs best of breed and/or innovative killer apps...

There is very little going on today which makes Perl relevant to anyone outside the Perl community. The reality is that Perl isn't much on anyone's radar except the people who already use it...

The insights which particularly appealed to me are:

  • Perl5 and Perl6 could definitely benefit from a "This is not your father's Oldsmobile" slogan. Perl doesn't market itself well.

  • Perl could use a modern clean cohesive comprehensive web portal which borgs the best of what the scattershot sites out there provide: CPAN, PAUSE, Perl Mongers, perldoc, perlmonks, ironman, use.perl, perlbuzz, the various community SCM repositories, professional training, perl jobs, etc. An effort to unify those disparate sites and services into a cohesive whole using modern and enlightened Perl would give Perl5 a chance to redefine itself.



Perl may look dead to outsiders, but there is a lot going on within the Perl ecosystem. There is: Perl6 (std, Parrot, Rakudo, SMOP), Moose, Catalyst, DBIx::Class, Web.pm. The list will vary from one Perl programmer to another. There is Padre, which shows promise of being of interest to non-Perl developers. And new in-roads into Bioinformatics. But O'Reilly and James Tisdall laid that foundation back in 2001 and 2003.


Another problem we need to answer, is why projects which are bootstrapped with Perl leave it behind?

Git, Linus Torvald's SCM love child, was originally assembled with a whole lot of Perl duct table, bubble gum, and glue. But if you visit http://git-scm.org/gitwiki/InterfacesFrontendsAndTools, you'll be surprised by how irrelevant Perl now appears to be to git.


Where are the new exciting, relevant solutions which use Perl?

Maybe they exist, but we're not aware of them? Muldis Rosetta is a truly relational RDMS (not SQL) being developed by Darren Duncan. Sounds interesting and promising... Does it work? Is it fast enough? Is it ready for use in production environments? Can it work with DBI, DBIx::Class, ODBC, JDBC, etc? Why aren't more developers involved with it?

Mojolicious looks like a fresh new MVC. In a fairly crowded field, it may be hard to distinguish itself. Take a look at Sebastian Riedel's recent Mojolicious::Lite blog.


Where are the other fertile grounds from which new solutions will arise? What other projects are out there which are using Perl to solve something new or solve an old problem in a better way?

Thursday, July 9, 2009

Legacy Traps

Here's an interesting dialogue from #perl6 yesterday:
TimToady  but the fact is, Perl 5 is basically in a no-win
situation long term, which we first recognized in
2000
PerlJam TimToady: now you're alienating all the staunch perl
5 supporters :)
TimToady I'm only alienating them "long term"
KyleHa If loving Perl 5 is wrong, I don't want to be right.
8-)
PerlJam Someone mentioned (probably on use.perl somewhere)
that Nicholas tried regular release cycles a while
back. I'd like to know if that's true and if so,
what became of it.
ruoso I don't really think the regular releases is the
issue...
TimToady I love Perl 5 too, but it's stuck (culturally, and
maybe technically) in a legacy trap, and the Perl 6
approach is the only long-term way out of that.
moritz_ ruoso: it's not about *regular*, but about being
able to release when there's something to fix
TimToady Perl 5 is a velociraptor, but we need an
acceloraptor now.

There ought to be a corollary to that saying about "Fast, Good and Cheap. -Pick any two". -Something to deal with legacy vs. innovation and revolution vs. evolution. But I suppose the latter is fundamentally a balance between looking backward while moving forward, the threshold of pain you're willing to undergo, and how you attempt to minimize it.

I wouldn't pretend to have the experience or wisdom to find the right balance. However, it doesn't appear to be a new problem.

C++ went through a period of upheaval not too long ago. There was a nice Dr. Dobb's article on it back in 1997. Well worth reading.

Here's a Linux kernel developers thread on the same topic of evolution and change. -A nugget from Theodore Tso:
"Clearly, we are right to mock Solaris for making claims that
they will never, ever, *ever* change an interface, not even
one that goes back sixteen years to Solaris 2.3. But it
doesn't follow the opposite point of view, that constant
mutability of kernel interfaces to make sure that things are
always perfect and pure and clean is the right one either."