paulo1205
(usa Ubuntu)
Enviado em 29/06/2015 - 18:55h
Mesmo depois que perdeu espaço na web e no background do mundo UNIX para Python, Perl ainda manteve alguns nichos. Pelo que li uma vez, o pessoal de Biologia que trabalha com sequenciamento de genes usava muito Perl por causa das conveniências no tratamento de expressões regulares.
Com a universalização de regexps (grandemente inspiradas na funcionalidade das regexps do Perl, que, por sua vez se inspirou nas do UNIX), acho que a tendência é diminuir ainda um pouco mais.
O Fábio expôs alguns fatores muito pertinentes para o declínio do uso do Perl. Mas eu me atrevo a apontar mais um punhadinho deles.
O primeiro é que Perl ficou meio estagnada no tempo. Depois da versão 5.x, quando alcançou seu clímax -- e também quando algumas escolhas feitas no passado começaram a dar sinais de que atrapalhariam evoluções futuras --, o esperado anúncio da versão 6 demorou a chegar. Quando finalmente ele veio, foi em termos vagos e com rumo meio incerto. Entre as poucas certezas estava a de que haveria uma ruptura com o que havia até então, a ponto de prejudicar o funcionamento de código existente. Outra certeza é de que a nova versão ainda demoraria alguns anos até ficar pronta, então os usuários deveriam se manter com a 5.x durante esse tempo, mesmo correndo o risco de ver seu código parando de funcionar quando a versão 6 finalmente fosse lançada.
Ótimo
marketing, não é? Qual
player sério do mercado escolheria investir numa ferramenta com um prognóstico desses, feito pelos seus próprios criadores? A única coisa boa a respeito desse anúncio é que ele foi sincero: admitia que havia problemas a resolver e dizia que a solução ainda iria demorar. Demorou mesmo: até hoje, 15 anos depois, não se fechou a forma final do Perl 6, e não existe uma implementação final pronta para uso em produção.
Enquanto isso, Perl 5 começou a sofrer golpes vindos de dentro de sua própria comunidade original:
- O pessoal de web começou a enxergar limitações de desempenho, controle de ciclo de vida e segurança ao trabalhar com CGI.
- O pessoal de redes sentiu dificuldades de usar IPv6 com Perl por causa do IPv4 atrelado diretamente à linguagem (em vez de serem ambos modulares, usando bibliotecas, por exemplo).
- O pessoal de tempo real (incluindo jogos) tinha mais dificuldade em embutir scripts em Perl nos seus sistemas do que outras linguagens, como Python ou Lua.
- O pessoal de Windows, MacOS Classic, VMS e outros sistemas não-UNIX sofria com a clara orientação a UNIX de partes essenciais da linguagem e com o amplo uso desses recursos, nem sempre muito bem reimplementados em seus respectivos sistemas, em código existente, inclusive no CPAN (por exemplo:
fork e
pipes).
- Orientação a objetos em Perl 5 é até rica e flexível, mas ridiculamente complicada de fazer direito, especialmente quando comparada com outras linguagens (porque é na verdade uma adaptação em cima de módulos, não algo pensado para a linguagem desde sua criação).
- O pessoal da infraestrutura (eu, inclusive) tinha dificuldade em compartilhar seus
scripts com colegas de trabalho. Mesmo com eventuais ganhos expressivos de desempenho em relação a
scripts implementados em
shell mais
coreutils (por fazer num só processo coisas seriam de ser feitas com vários comandos externos em processos diferentes, com passagem de dados entre eles através de
pipelines ou arquivos intermediários), a verdade é que grande parte das ferramentas do dia-a-dia trabalha com volumes pequenos de dados, e acaba conseguindo fazer o trabalho num tempo aceitável, mesmo com todas as ineficiências. Para muitos administradores (inclusive colegas meus), o esforço de acompanhar a curva de aprendizado da nova linguagem simplesmente não valia o esforço em 99,5% dos casos. Para o 0,5% restante, chama-se um especialista (torcendo para ele não resolver usar Java!).
- Para muitos, de várias áreas, a linguagem não é só estranha, mas também é feia. O próprio Larry Wall conta uma história mais ou menos assim “eu estava no meu computador, programando em Perl, e minha filha pequena chegou perto e olhou para o monitor; ao ver aquele monte de caracteres ‘@$#%&’ pela tela, ela perguntou: ‘O que é isso, papai? Xingamentos?’”.
A maioria desses problemas não teve solução ou teve apenas soluções parciais e ruins (como o
mod_perl para o Apache, para tentar melhorar o desempenho sofrível de CGIs). Nos raros casos em que houve uma solução real (por exemplo, o Catalyst, que é um
framework para Web comparável a Plone ou Ruby-on-Rails), o momento para o Perl já havia passado, e mesmo esses movimentos acabavam conquistando apenas nichos.
Apesar disso, Perl ainda tem seus pontos fortes. Até pouco tempo atrás, quando comparados dois programas com função equivalente, sendo um em Perl e outro em Python, a versão em Perl era geralmente mais rápida, e isso na maioria dos domínios de problemas. Um dos usos que eu mesmo mais faço de Perl é com scripts de uma linha, logado no terminal de algum servidor, como parte inicial ou final de uma
pipeline, e isso, num caso não-trivial, é impossível (ou artificiosamente difícil) de fazer em Python, que exige a indentação de códigos em blocos em múltiplas linhas. E, claro, é mole manipular texto em Perl, sem a necessidade de criar objetos ou usar variáveis intermediárias para aplicar funções de transformação sobre elas, e sem precisar de encadear uma dezena de comandos separados (e.g. grep + sed + awk + sort + uniq + cut + wc + etc.) em
pipelines ou em sequência.
Eu ainda uso Perl para praticamente tudo o que eu faço (com C num distante segundo lugar, e depois Shell e C++, que é minha linguagem predileta). Eu aprendi Perl “na marra”, na época da faculdade, obrigando-me a implantar nessa linguagem, ainda na versão 4.036, coisas que apareciam para fazer no departamento da Universidade em que eu trabalhava. Como muitas dessas tarefas eram justamente processar dados em forma de texto e produzir relatórios, Perl calhou de ser uma opção interessante naquele momento (antes eu só usava C e, raramente, C++ (ainda antes de ser padronizado) -- imagine manipular strings só com funções nativas ANSI C!).
Eu já era Perleiro pesado quando Python começou a ganhar relevância. Sempre achei que uma oportunidade ideal de aprender a nova linguagem seria fazer como fiz com Perl, obrigando-me a implantar coisas novas com a nova ferramenta. Só que eu acabei nunca fazendo isso, às vezes porque o prazo era apertado, e eu não podia me dar ao luxo de gastar tempo reaprendendo a fazer o bê-a-bá (na faculdade, o tempo era uma coisa muito mais maleável, tanto para mim, solteiro e sem filhos, quanto para quem me demandava as coisas), às vezes porque meu acesso era limitado e os servidores onde a ferramenta deveria rodar não dispunham do interpretador Python -- e reconheço que, em ambos os casos, havia uma certa pitada de falta de organização pessoal. Acabei investindo meu tempo de estudo mais em C++.
