Over in The McCarroll-Cross Productivity Indicator, Dave complains:
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.
That's because other programmers bring along their common vocabulary, ability to dig in to the details, and willingness to tolerate my foibles as a fellow "member of the tribe".
End users just wanna push buttons.
For an example of this, subscribe for a week or two to the NMS support mailing list. NMS is a great idea (replace Matt Wright end-user scripts with really good versions), but the mailing list gets the most inane bizarre questions.
That's one great example of why I don't want to support end-users for free. I don't mind writing full apps for clients, who will likely pay me more to make further tweaks, and I don't mind writing CPAN modules, but I'm not about to lose the rest of my life supporting end-users for free.
Re:
Aristotle on 2005-12-03T16:38:44
I know! But evidently, there are people who can be bothered to do this sort of thing: the PHP world is full of readily deployable shrink-wrap software.
I don’t see any reason to call what you are doing “not JFDI” per Dave’s “MCPI” and consider it ivory tower pastimes or something.
What we need to do is better encourage those who are inclined to write applications, as well as make it easier for them to package up their software for shrink-wrapping. (PHP apps are trivial to deploy for anyone who can click buttons in a GUI FTP client. Perl is 10× more picky.)
Re:Confused/confusing
davorg on 2005-12-07T11:23:47
I have to wonder how much that essay is tongue-in-cheek.Then wonder no more. I was completely serious.
I'm saying that I'm tired of people talking about PHP as the web development languages of choice because they can find any number of ready-rolled applications on the internet that that they can just download and install[1]. And I'm tired of people saying that Ruby on Rails is the next big thing because 37Signals create useful and interesting web applications using it. And most of all I'm tired of hearing Perl programmers bemoaning those first two facts whilst uploading yet another bloody templating system (which no-one will ever use) to CPAN.
But perhaps I'm overreacting.
[1] Yes, you know and I know that many of these applications have huge security holes. But to the people downloading them that doesn't matter. It should matter. But the reality is that it doesn't.
Interesting/interested
mr_bean on 2005-12-07T13:13:03
I went and read the article again. I appreciated
it more than my comment suggests.
JFDI is anti BDUF and similar to YAGNI.
What I like about programming (in perl) is that I
don't have to do the Big Design Up Front. I can
build the program up on the basis of the results
from my half-baked code. I can learn as I go.
That's a bottom-up process.
I don't know why this is an interesting topic to
me. Perhaps because I think about the path to
becoming a CPAN author from the present state of
my code.an analogy with making plastic utensils
mr_bean on 2005-12-09T23:59:12
I understood better by comparing the situation
with a manufacturer of rejiggable plastic moulds
who is unhappy about his customers. These
customers are 'happy campers' who are spending
all their time rejigging their moulds, rather
than producing plastic utensils.
Meanwhile, metal and ceramic utensil
manufacturers are producing and selling large
amounts of non-plastic utensils.
