I was reminded of the quip in the title recently when I bumped serendipitously into an exchange between two comp.lang.perl.misc regulars. On the surface, it was on the suitability of Perl for OOP, a subject that I've seen debated a zillion times, but one of the participants (Anno Siegel) made a point that was new to me: the problem he has with Perl OOP is that he doesn't trust that other programmers will do it right. His point is that Perl's permissiveness makes it too easy for less-than-expert programmers to weaken the "available software" (e.g. CPAN). (Read Anno's post here.) But although this was all about OOP, I think the same argument can be reasonably extended to programming in general.

Perl is a very "programmer-centric" language, more inclined to accommodate the programmer than to require that the programmer accommodate to it. Perl is all about expressive freedom, multiplicity of choice, and personal responsibility. And who wouldn't want all this freedom and all this choice? Of course, responsibility comes with it, but so what? It's a very fair price to pay for what one gets in return. Or so the argument goes.

Anno's reply basically says that the reason one wouldn't want all that freedom is that one wants to be able to trust the code written by others. He is saying that Perl's freedom is in a very real sense working against the goal of CPAN, and the goal of code reuse in general.

Anno's post presents the intriguing possibility that a programmer may personally prefer to program in A, but ends up choosing B because he/she trusts the available B code more than the available A code. Similarly, a manager may conclude that, in the long run, it is better to use a language that gives the programmer less freedom of expression, even if this means less rapid development, because in this way he/she won't need to put so much trust in that the programmers will always do the right thing. (Programmers who always know what the right thing to do is tend to be pricey, you know.)

From discussions in CB, I gather that the folks working on Perl 6 are very aware of this situation, but I have not followed the development of Perl 6 closely enough to be able to say how these considerations have influenced, if at all, the design of Perl 6. Judging, however, by this quote from TheDamian I suspect that the philosophy behind Perl 6 is not very different from that behind previous versions of Perl:

Perl has always offered the ability to code at your own level and in the style that suits you best. That's not going to change, even if the style that suits you best is Perl 5.

In other posts I have speculated that in the future maybe a more limited and strict dialect of Perl will emerge as the standard (ANSI Perl?), and that corporations and other large organizations will choose this limited Perl over the richer, more idiomatic "common Perl", which in turn will gradually become relegated to the "private sphere." This would be entirely analogous to how certain dialects of English have become relegated to the private sphere, but rarely if ever used in a professional setting.

My reason for this prediction was that corporations and other large organizations have less use for brilliant code that only to a small number of Perl wizards can grok, than for mundanely-written code that even the non-wizard can follow. Anno's point is related, but subtly different, because he is not arguing for making the code accessible to non-experts, but rather that an expert who wants to be able to comfortably use code written by others would prefer if the language in which this code was written left little choose, out of otherwise comparable alternatives, the one that left less room for screw-ups.

What do you think?

Update: I reworded the last sentence in response to various comments.

the lowliest monk

In reply to TMTOWTDI... and most of them are wrong by tlm

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.