In my opinion one of the best and most important talks at last Saturday’s London Perl Workshop was the first talk in the beginners track where Greg McCarroll talked about “Rediscovering the Joys of Perl”. Greg introduced a couple of quick hacks that he had written to make his life better. He went on to say that the best way for a programming language to prove itself is for people to stop building over-complex frameworks (or, worse, talking about building over-complex frameworks) and to just get on and write useful applications. If people took just one idea from from the LPW then I hope if was Greg’s message of “JFDI”[1].
Greg and I were talking about this in more depth last night and we agreed that the Perl community often suffers from a lack of JFDI. In many ways CPAN has proved to be a double-edged sword. Of course it’s great that it enourages people to write and, more importantly, share reusable code. But on the other hand it often seems that writing reusable code libraries is all that Perl programmers do. There’s precious little evidence of them ever writing useful end-user applications. Of course there are great Perl applications out there, but they seem to be the exception rather than the rule.
During our discussion we came up with a rough and ready way to measure whether what you’re currently doing is JFDI or not. The idea is that if a programmer knows that what they are doing isn’t currently JFDI then they have a strong indication that they would be more productive if they reordered their priorities.
So, I give you the McCarroll-Cross Productivity Indicator (MCPI):
If you can’t explain what you are currently doing to a non-technical person in one short sentence, then you are not JFDI
[1] “Just Fucking Do It”.
No other comment than “hear! hear!” :)
This not doing things is probably directly linked to what I would consider to be the poor marketing campaign of Perl and its frameworks, and hence the low adoption of these technologies. In other words people get inspired by practical results.
Ian,Yes. That’s pretty much exactly what I meant.
I don’t think that’s a particularly productive way to break down things; see my response to this on use Perl.
While it might seem like that, quite often we’re writing end-user applications for @work. Those generally cannot be open-sourced. Instead, many of us take the knowledge we’ve gleaned there and share the results with others even though the end-user apps cannot be shared. This is simple economics, too. It’s much easier to release small, special-purpose modules than to build and release an entire application.
Maybe visible Perl projects need to be more explicit about the frameworks they use? I note (since it’s about the only visible Perl project I’m even remotely involved in) that http://openguides.org/page/software is directly linked from the OpenGuides front page, but doesn’t mention Template Toolkit or any of the other frameworks that it builds on. It does at least mention that it’s written in Perl.