Front page | perl.perl5.porters |
Postings from June 2006
John Adams wrote: > Let me recap: > > You've got someone who cares enough about Perl to be on p5p, > someone who says he'd like to use Perl for various purposes but can't, > and who can clearly articulate reasons why not. Instead of listening to what > he's saying, you're telling him why he's wrong. > > Could this possibly have something to do with why he isn't using Perl? > We did listen. The OP's complaints were predicated on assumptions that many of us believe to be misconceptions, or easily corrected with a little discipline, and maybe some text processing scripts. We pointed out that the issues raised were not generally unique to Perl (tho Perl is perhaps subjected to the most egregious abuses). That he "can't" use Perl is debatable; I don't recall any mention of Perl's *functional* omissions or failings. Apparently the fear of deploying Perl for production use is based solely on the idea that its diverse syntax can lead to accidental obfuscation, even though: - nothing in Perl requires code to be written in cryptic syntax. Most punctuational special variables can be coerced into mnemonics via "use English", and, in fact, Perl supports a more natural language syntax than many languages which are presumably considered acceptable for production use - there are organizations which do use Perl in production deployments, and in some cases for high reliability/availability environments Frankly, some of the OP's assertions call into question the QA processes in the OP's organization; they imply there's no code review (or its evil cousin, pair programming), nor enforced coding standards, for production code. In such an environment, the OP is probably right to not use Perl for production development. He should probably also reconsider using *any* language until such controls are put in place. Nonetheless, suggestions were offered to address his challenge, e.g., a perltidy enhancement (perhaps exploiting PPI ?) to address his concerns about Perl's syntactic diversity by enforcing whatever his organization deems to be acceptable syntax. And suggesting that, by dismissing Perl solely on the basis of easily correctable syntactic issues, he and his organization were missing an opportunity for significant productivity improvements. Wrt the original subject, if Perl's greatest challenge is its syntactic freedom, then I doubt there's much to worry about (tho a better OO syntax would be welcome). However, I think most of us can agree there are other more urgent challenges. My personal list is concerned with functional issues: reducing threads footprint, and (esp.) finding an alternative to the threads::shared shared interpreter context and its global lock bottleneck. Once those issues are addressed, I've very little reason to ever trouble myself about Perl6.Thread Previous | Thread Next