Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Aristotle (5147)


Blah blah blah blah blah []

Journal of Aristotle (5147)

Saturday December 03, 2005
11:08 AM

Do we need a Discussion Polarity Indicator?

[ #27840 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I don't write end-user software because the support cost of providing end-user software is far higher than the support cost of providing reusable components for other programmers to use.

    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 (re

    • Randal L. Schwartz
    • Stonehenge
    • 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

  • I have to wonder how much that essay is

    He says if you can't say what you are doing in a
    sentence, then it is not JFDI. Actually, being
    articulate about what you are doing is a sign
    that you are not Just Fucking Doing It. You have
    thought about what you are doing, rather than
    plunged straight in.

    Is the essay an expression of the angst of CPAN
    authors wondering if their tools are being used?

    He seems to be saying that one of the strengths
    of perl, its practicalness, is not strong enough.

    What evidence
    • 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 hear

      • 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.
        • 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.