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.
He goes on to propose the McCarroll-Cross Productivity Indicator:
If you can’t explain what you are currently doing to a non-technical person in one short sentence, then you are not JFDI.
I happen to think that polarising the discussion into “JFDI” and “not JFDI” is, to put it mildly, counterproductive. Why is this need to make “this is good”/”this is bad” drawers to put things in? Does someone have to teach us the lessons from Why I hate advocacy all over again?
The claim that there aren’t any Perl applications is puzzling unless you qualify it as “applications that an end user can download and install” (in which case I would have to agree); because there certainly isn’t any shortage at all of custom-built Perl applications everywhere on the web.
What I see is that Perl seems to attract predominantly “end users” who are interested in building their applications themselves – an ilk that considers the CPAN a dream for obvious reasons. There are much fewer of those who have an interest in building shrink-wrap software.
Which explains all of the biases in the Perl community in one fell swoop.
Now, doesn’t putting things is this light provide a more productive basis for addressing the issue than polarising the arena can? Let’s see:
I think the Perl community suffers no shortage of JFDI at all. If anything, that’s the least of our problems. What we need actually are more people who build reusable code – namely, applications. If the CPAN is a double-edged sword, as Dave maintains, then it’s because it makes JFDI too easy. Shrink-wrap software does not get built, because shrink-wrap software is a lot of unrewarding work; just scratching one’s own particular itch in a non-reusable fashion is an order of magnitude easier than generalising the code and making it easy to unwrap and deploy for other people. Likewise, extracting code for a particular purpose from an application and broadening its scope into a packagable module, while slightly more work than going the JFDI route, is still a lot easier than writing shrink-wrap software, and it offers the JFDI hacker a direct benefit – as well as rewards in ego.
It follows that I don’t see the current situation as all that negative. In fact, I believe it is indicative of an amazing strong point of the Perl community. No doubt, the lack of shrink-wrap software that has resulted from this culture is a weakness in the visibility of the language. But from my view of the situation follows that it shouldn’t be hard to address if we simply encourage people to polish and share their JFDI work.
There is no need to get judgemental about anyone’s choice of what they do with the language. Evangelising what we need more of in an encouraging way instead of admonishing people for what they have been doing so far is more likely to gain a favourable response. You catch more flies and so on.
What does seem to be in need of addressing on the road to applications is infrastructure. Ours doesn’t seem to make this easy enough. On Unixoid systems and given root privileges, Perl applications are trivial to deploy; dare step outside these boundaries, though, and things get tricky, if not downright hairy. PAR might be of some help, but PAR executables aren’t particularly well integrated with the CPAN infrastructure we already have.