develooper Front page | perl.perl5.porters | Postings from June 2006

Re: Its time we set the score straight on Perl 5 and Perl 6 and debunkour own self generated FUD.

Thread Previous | Thread Next
Dean Arnold
June 16, 2006 15:10
Re: Its time we set the score straight on Perl 5 and Perl 6 and debunkour own self generated FUD.
Message ID:
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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About