|
|
|
| "be consistent" | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
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 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
|
|