Perl! - onde está você?

paulo1205
(usa Ubuntu)

Enviado em 30/06/2015 - 20:19h

Prezado mineirobr,

A primeira coisa que eu quero que fique clara -- e que eu disse na minha primeira intervenção -- é que Perl é minha principal ferramenta de trabalho. Mais do que isso, eu _gosto_ de Perl. Mas gostar não é motivo para ser cego ou acrítico para com as limitações da linguagem.



Eu estou falando de fim dos anos 1990 e início de 2000, quando a prática mais comum era ter o Apache (e alguns lugares ainda se tinha NCSA ou CERN httpd!) invocando todos os CGIs como comandos externos. Eu vivi essa época, trabalhando em grande parte justamente com isso, então você pode considerar que eu falo com conhecimento de causa. Além do tempo necessário para fazer fork+execve do interpretador Perl, ainda existia o tempo de “compilação” do script (junto com todos os módulos de que ele dependesse) para o formato interno usado pelo Perl.

Se isso é “um pouco” ou se é muito, depende do programa. Mas tempo de carregamento (e eu nem entrei no mérito de inicializar coisas depois do script compilado, como definir estruturas de dados, abrir conexões com bancos de dados etc.) é só uma parte do problema. Se você pensar no contexto do fim dos anos 1990 e início de 2000, em que as pessoas ficavam de queixo caído quando você falava sobre um servidor com mais do que 64MiB (sim, eu quis dizer "mega", não "giga"), ter um monte de processos isolados executando os mesmos scripts, mas sem compartilhar praticamente nada de memória (além do próprio binário do Perl, coisa que o SO se encarregava de fazer) era realmente um cenário de somas de desperdícios. Não é à toa que quase todo mundo migrou para JEE (na época, J2EE) assim que a tecnologia se mostrou suficientemente segura (e não, eu não defendo JEE; eu detesto JEE), ou, numa segunda leva, para outros frameworks com linguagens diferentes de Java, como o Zope, que usa Python, ou .NET.

Sobre a competência do programador ajudar em segurança: é claro que é um dos fatores relevantes. A competência do programador ajuda até no problema de overhead que mencionei acima. O problema é que CGI, como modelo de programação, não tem nenhuma preocupação com segurança. A única preocupação era passar dados do cliente para o servidor e gerar conteúdo dinâmico. Frequentemente, um mero “ps awwwex” era suficiente para descobrir dados passados do cliente para o servidor.



Quando você citar alguém, evite colocar palavras não ditas ou remover palavras ditas. Eu não disse só que OO em Perl é complicada, mas que é ridiculamente complicada. E é.



Não, eu nunca ouvira falar do Moose. De fato, ela é interessante, e eu, como perleiro, vou estudá-la.

Em todo caso, sua existência não invalida o que eu disse. Moose (e Class::MOP, que lhe dá base) é uma forma de estender a linguagem para que OO fique mais simples de fazer do que usando apenas aquilo que a linguagem nativamente oferece. (Mal) comparando, seria como dizer que o conjunto de macros e tipos auxiliares da GObject fazem do C uma linguagem orientada a objetos.

Além disso, o contexto da minha colocação era elencar fatores que contribuíram para o declínio da posição que Perl tinha no final dos anos 1990. Moose só aparaceu quase uma década depois.



A citação original é a seguinte (fonte: Usenet, 199806181642.JAA10629@wall.org).



Eu entendo a postura dele. Ele quer olhar para o futuro. E está certo.

Ou nem tanto. Esse futuro já está quinze anos atrasado. E, na sua lenta gestação, está anunciando que vai parir um “Perl” que é tão diferente do Perl que já se conhece quanto várias outras linguagens.



Eu elogiei Catalyst, não falei mal dele. E a questão não é contar quantos sites o utilizam ou deixam de usar -- até porque seria ridículo contar quantos sites _não usam_ Catalyst.

Minha colocação tinha um contexto histórico, e nesse contexto, troca de informações via Web era quase sinônimo obrigatório de Perl. Qualquer oferta de emprego exigia que se soubesse Perl. Hoje, ofertas de emprego pedem de tudo -- C, Java, PHP, Python, C++, Lua, e até Haskell --, mas não se pede Perl. Eu não sei se essa realidade seria necessariamente diferente se algo como o Catalyst tivesse surgido uns oito ou dez anos antes, mas talvez houvesse mais interesse em Perl do que há hoje.

Note, de novo, que eu _não disse_ que ninguém usa Perl ou que a linguagem está morta, usada apenas por zumbis que não evoluem. Só que ela hoje tem um emprego muito restrito do que já teve um dia -- nichos, perto do que já foi.



Cuidado para não deixar o fanatismo afetar sua capacidade cognitiva. Eu NUNCA disse nada parecido como que o você me acusa de ter dito. O que eu fiz foi citar o mod_perl como _uma das soluções_ parciais e ruins.

Algo que eu não disse sobre ela, mas digo agora, é que eu digo que ela era ruim com conhecimento de causa, porque eu a usei em 1998-1999, e a achei insatisfatória de muitas maneiras, principalmente por causa de problemas de compatibilidade. Eu admito que essa foi a última vez que mexi com ele, pois diminuí muito meu contato direto com administração de servidores Web desde 2000, e mais ainda com desenvolvimento para web. Possivelmente o mod_perl de hoje é bem melhor do que o da época. Tomara que seja! Mas eu não sei se isso é relevante. Ainda existe alguém que desenvolva sistemas a sério usando CGI e módulos estanques (não estou falando de scriptzinhos de front-end web de um relatório ou outro)?

removido
(usa Nenhuma)

Enviado em 30/06/2015 - 21:06h

Percebo que o debate está bom. Múltiplos pontos de vista.

Thiago211, se você quer adminstrar sistemas Unix deveria aprender primeiro comandos de terminal.
Aprofundar expressões regulares, comandos sed, awk, grep, find, expr, test etc.
E saber linguagens de scripts principais de administração, bem como diferenças de shell script rodados em ash, dash, ksh, csh, tcsh, bash e zsh.
Python e Perl podem esperar um pouquinho.

--
http://s.glbimg.com/po/tt/f/original/2011/10/20/a97264_w8.jpg

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. — Edward Snowden

dvinciguerra
(usa Debian)

Enviado em 15/10/2015 - 14:43h

Perl esta presente no site da W3C Brasil
http://www.w3c.br/Home/WebHome

Para quem não sabe, a W3C é a principal organização responsável ão de padronização da internet como conhecemos hoje.
Se uma entidade tão importante aposta e confia no Perl é por que o mesmo é uma plataforma sólida.

Perl é utilizado por grandes empresas como Amazon, Google, Yahoo... até onde sei era utilizado até pela Microsoft até pouco antes de eles lançarem o PowerShell que veio pra substituir a necessidade de uma linguagem de script para administração de sistemas e tarefas mais especificas.

Perl não é uma linguagem puramente orientada a objetos mas ela tem um excelente suporte ao paradigma. Possivelmente o fato de a linguagem não ser puramente orientada a objetos deixa algumas pessoas desconfortáveis, o que não significa que a linguagem seja inferior a Js, Python ou Ruby por exemplo (a verdade é que Perl inspirou essas linguagens).

Empresas nacionais como o Serasa e o LeisMunicipais, por exemplo, também usam Perl em seu core business:
http://www.vagas.com.br/vagas/v1182889/analista-de-sistemas-sr