Razões que levaram o OpenData-BR a escolher Perl
Enviado por Blabos (blabosΘgmail·com):
“Confesso que fiquei com o pé atrás quando soube que o artigo do Breno no Equinócio deste ano chamaria-se Por que Perl?, mas para minha alegria eu estava errado.
Em uma análise técnica e bastante objetiva ele discorre sobre as razões que levaram o projeto de hacking de dados públicos OpenData-BR a utilizar a linguagem Perl como base do seu desenvolvimento.” [referência: sao-paulo.pm.org]
• Publicado por Augusto Campos em
2011-03-02
@brlinuxblog
Feed RSS
A análise foi objetiva sim, mas de forma alguma “técnica”.
Vi diversos motivos “mercadológicos”, “ideológicos”, entre outras motivações diversas para opção de Perl, mas praticamente nenhum argumento técnico.
Cá entre nós, acho um pouco difícil falar em “argumentos técnicos” quando a linguagem em questão sequer possui meios para determinar você está passando o número correto de argumentos para as funções. Para códigos que não passam de 3 ou 4 páginas a linguagem é ótima – para qualquer coisa além disso, é como se você estivesse martelando um prego com uma chave de fenda.
Eu já programei bastante em Perl, desde programas simples para lidar com processamento de dados de texto até aplicativos gráficos usando Gtk2-Perl, inclusive com comunicação via TCP/IP, por isso posso dizer que estou falando por experiência própria.
Ah sim, só reforçando: estou falando da linguagem e seus argumentos técnicos. Não estou falando de APIs, módulos, implementações, comunidade, desenvolvedores, etc.
Leonardo
Quando precisei dar manutenção num código Perl, tive uma péssima 1a impressão da linguagem. Felizmente, a culpa era do programador que era muito desorganizado.
Hoje gosto de Perl e a tenho na minha ‘caixa de ferramentas’ para Shell Script, principalmente quando tenho que programar no AIX.
MAS
A concorrência tá feroz, até o C quer ser shell script (TCC). Fora que tem Ruby, Python, Groovy, Scala e Javascript (até ele!!!) chegando junto.
Hoje, quem quiser defender a sua linguagem de programação vai ter que ser na base do “Eu gosto de Java e pronto!” (hehe, deu pra sacar qual a que eu mais gosto?)
Leonardo,
Discordo de você, há vários projetos de grande porte desenvolvidos em Perl e que utilizo diariamente: Shorewall, MailScanner, Zentyal (antigo eBox), Webmin, OpenWebmail etc., todos excelente projetos e com bem mais que 3 ou 4 páginas como você afirmou.
Tive a feliz oportunidade de conhecer o Breno e vários outros gurus Perl no evento YAPC::Brasil que ocorreu aqui em Fortaleza ano passado, os caras são muito bons e Perl é muito mais do que isso que você descreveu no seu comentário.
Sem querer desmerecer as outras linguagens, muito pelo contrário, mas experimente renomear o binário perl da sua distribuição linux favorita e veja o que acontece ao reiniciá-la.
Cá entre nós, acho um pouco difícil falar em “argumentos técnicos” quando a linguagem em questão sequer possui meios para determinar você está passando o número correto de argumentos para as funções.
Perl tem sim (e há muito tempo) um mecanismo de verificação da quantidade de argumentos em tempo de compilação:
http://perldoc.perl.org/perlsub.html#Prototypes
Perl é a linguagem ETL mais Prática que existe.
pena que parou no tempo…
@Tarcísio,
O fato de existirem softwares feitos na linguagem e que fazem coisas práticas não quer dizer que ela é indicada – só significa que ela tem expressividade suficiente para tal.
Afinal, foi isso que quis comentar com minha analogia: você consegue bater o prego com uma chave de fenda (usando o cabo), mas vai ter mais trabalho e talvez não consiga batê-lo completamente.
Estou falando de pegar um programa feito em Perl e numa linguagem mais indicada para programas maiores/complexos, os dois feitos da mesma forma e com os mesmos algoritmos, e comparar – por exemplo – custo de manutenção para alterá-los para adicionar algum recurso, ou reestruturar o código dos mesmos.
@Eden Cardim,
Lá no meio está escrito assim:
Perl supports a very limited kind of compile-time argument checking using function prototyping.
Lembro que já tentei usar e não surtiu muito resultado.
Além disso, esse foi só uma questão. A linguagem como tem diversos outros problemas, como por exemplo incoerências sintáticas.
Se há uma vasta gama de módulos e uma comunidade em volta que facilitam as coisas e permitem desenvolver grandes softwares, isso é algo muito bom, e um dos motivos pelos quais também já programei nela. Entretanto, a linguagem em si não é uma boa referência.
Talvez Perl6 mude isso, quando sair.
Leonardo
Talvez Perl6 mude isso, quando sair.
E automaticamente perder a vantagem de não poder usar a gigantesca quantidade de bibliotecas do CPAN, visto que o perl6 tem a sintaxe bastante incompatível com seu predecessor…
E automaticamente perder a vantagem de não poder usar a gigantesca quantidade de bibliotecas do CPAN, visto que o perl6 tem a sintaxe bastante incompatível com seu predecessor…
Perl 6, como de costume em releases de perl, é retrocompatível com todas as versões anteriores do perl.
Lembro que já tentei usar e não surtiu muito resultado.
Então você usou errado, se os protótipos do perl não funcionassem você não estaria usando internet pra mandar essa mensagem.
Além disso, esse foi só uma questão. A linguagem como tem diversos outros problemas, como por exemplo incoerências sintáticas.
Um blog post completamente ignorante, equivocado e datado de 2002 sobre a sintaxe de perl não indica que a linguagem tem incoerência. Isso seria o caso se a mesma sintaxe fizesse coisas diferentes, te desafio a encontrar um caso onde isso ocorre (não só em perl, como em qualquer linguagem, até PHP). Perl é bem diferente de Lisp no tratamento de listas, inclusive o paradigma é outro, então a comparação não procede.
@Leonardo
Só por curiosidade!? Quanto tempo você trabalhou com a linguagem e quanto tempo se dedicou a aprender e aperfeiçoar seus conhecimentos na mesma?
(De peso à palavra DEDICOU)
Forte abraço,
Acho que o artigo do Breno é a análise que faltava para as pessoas que tem medo de Perl, que não conhecem, ou que acham que conhecem terem uma outra visão sobre a linguagem, e sobre o que ela tem a oferecer, sem excesso de argumentação técnica, quase ‘comercial’ eu diria. Gostei muito! Meus parabéns!
Porque gastar uma página inteira pra explicar a escolha de uma linguagem quando, na verdade, a escolha com certeza foi na base do “é a linguagem que a gente mais gosta e que a gente mais sabe e pronto”?
Quem gostar de Perl que contribua e quem não gostar (como eu) não contribua ou o faça na linguagem que escolher.
eu gosto mais do argumento “eu gosto mais” do que do argumento “o gerente de bolso cheio gosta mais”. :)
@Copernico Vespucio
Não precisa concordar.
Só não minta ao afirmar coisas sobre as quais você não tem compreensão.
Perl nem é a linguagem que eu mais sei, aliás você nem tem como provar isso, então, o que você disse não passa de uma falácia.
Abraços
@Patola,
Com certeza – mas como falei, estava tentando falar só no nível de linguagem. Comunidade, bibliotecas disponíveis.. isso tudo é outra coisa, fora do escopo do meu comentário.
@Eden Cardin,
Isso seria o caso se a mesma sintaxe fizesse coisas diferentes,
A mesma sintaxe fazendo coisas diferentes pode ser, por exemplo, sobrecarga de operadores. Nada tão incoerente assim, se corretamente especificado.
Entretanto, quando falo “incoerências sintáticas” digo você escrever um trecho de código baseado em conhecimentos anteriores, esperar um comportamento, e o programa apresentar outro – neste caso, por diversas considerações equivocadas na parte sintática da linguagem. Isso sim é uma incoerência.
[...] te desafio a encontrar um caso onde isso ocorre (não só em perl, como em qualquer linguagem, até PHP).
Incoerência? Tinham algumas coisas ali naquele post que citei. Se quer mais, a minha hora é R$ 50 – recebo em dinheiro.
A propósito, se 2002 é antigo demais para você, eu devo lembrá-lo que a linguagem não teve alterações neste sentido desde muito antes.
Também não entendi porque você citou “Lisp” e tratamento de listas – estava falando de um comportamento anômalo da sintaxe, só isso. Não estava de forma alguma citando listas ou manipulação de qualquer outra estrutura de dados, por mais que isso fizesse parte do exemplo.
@Daniel Vinciguerra,
Quanto tempo você trabalhou com outras linguagens, outros paradigmas, e por quanto tempo aperfeiçoou seus conhecimentos nos mesmos?
Não acho que esse tipo de argumentação leve a algum lugar – não vim aqui arrotar títulos, nomes de linguagens ou conceitos diversos. O que comentei é que a linguagem tem sim suas incoerências e seus problemas – coisas típicas de uma linguagem que manteve um legado por tanto tempo.
Acha que Perl é tão bom assim? Continue usando e seja feliz.
Cá entre nós, eu uso Perl de vez em quando para coisas diversas – afinal, um canivete suíço é muito útil em diversos momentos. Entretanto, você jamais desmontaria de forma eficiente um Boeing usando o tal canivete. Cada ferramenta tem seu propósito, especialmente quando o problema é real e exige algo mais específico.
Enfim, o que eu tinha para dizer, é isso.
Leonardo
Entretanto, quando falo “incoerências sintáticas” digo você escrever um trecho de código baseado em conhecimentos anteriores, esperar um comportamento, e o programa apresentar outro – neste caso, por diversas considerações equivocadas na parte sintática da linguagem. Isso sim é uma incoerência.
“Baseado em conhecimento anterior” é bastante relativo e subjetivo. Mas baseado nesse raciocínio, em C, por exemplo, não poder escrever 1 + “10″ seria uma incoerência pra quem não sabe o mínimo que deveria sobre a linguagem e perfeitamente aceitável pra quem sabe. Em Ruby, poder alterar o valor de uma constante seria uma incoerência sintática. Em python, não poder usar a quantidade de whitespace que eu quero seria incoerência sintática. Em qualquer linguagem OO (java, C++, etc.), executar uma função num namespace diferente por conta de polimorfismo seria uma incoerência pra quem não sabe OO (por incrível que pareça, já vi programadores C reclamando de C++ por conta disso). Muita gente também reclama de linguagens funcionais, por falta de estruturas de loop, mas é pura ignorância a respeito do paradigma. O que está acontecendo nesse artigo que você citou é que o autor desconhece as propriedades semânticas básicas e paradigmáticas da linguagem e está reclamando que não funciona da forma como ele espera (invés de ir aprender como é que funciona e porque).
A propósito, se 2002 é antigo demais para você, eu devo lembrá-lo que a linguagem não teve alterações neste sentido desde muito antes.
Se for pra levar em consideração opiniões de 2002, ninguém pode usar python ou ruby. De lá pra cá muita coisa mudou, em todas as linguagens, inclusive perl (só que perl mantém a retrocompatibilidade, senão a internet ia parar de funcionar)
Também não entendi porque você citou “Lisp” e tratamento de listas – estava falando de um comportamento anômalo da sintaxe, só isso. Não estava de forma alguma citando listas ou manipulação de qualquer outra estrutura de dados, por mais que isso fizesse parte do exemplo.
Porque no artigo de 2002 que você citou, o cara reclama que perl não funciona da forma que ele espera porque ele esperava que funcionasse como Lisp, e você usou isso pra embasar teu argumento furado de que perl tem incoerência sintática. Isso é equivalente a reclamar de PHP porque não funciona como Assembly.
Não acho que esse tipo de argumentação leve a algum lugar – não vim aqui arrotar títulos, nomes de linguagens ou conceitos diversos. O que comentei é que a linguagem tem sim suas incoerências e seus problemas – coisas típicas de uma linguagem que manteve um legado por tanto tempo.
Realmente a linguagem tem vários problemas (como o sistema de gerenciamento de memória, falta de bom suporte a threading e até bugs grotescos nas distribuições Red Hat), mas não os que você citou arbitrariamente. Esses “problemas” provém da tua ignorância a respeito da linguagem (e de qualquer pessoa que tentou aprender pegando um tutorial e lendo em 15 minutos).
Eu quis dizer conhecimentos anteriores da própria linguagem. Ou seja, você aprendeu uma determinada operação, e quando vai generalizar se depara com uma coisa contrária ao que lhe seria natural.
Que eu saiba, a “internet” é feita de roteadores, servidores, e outros máquinários diversos cujos softwares são escritos em linguagens de nível muito mais baixo que Perl. Talvez Perl esteja lá em alguns servidores web, em determinados sites e utilitários – mas eu diria que é muito mais um nicho do que uma regra.
Se foi dito isso em algum lugar, desculpe mas não cheguei a ler o artigo inteiro. O ponto é a incoerência sintática mesmo.
Claro que uma linguagem funcional lida melhor com estruturas recursivas (como listas), mas não entrei nesse mérito, e nem queria entrar.
Você está falando de listas, opiniões antigas (2002 é antigo?), entre outros. Mas o meu ponto é a incoerência sintática, do tipo que você não pode alterar sem modificar a definição da linguagem – e aí quebrar compatibilidade
Talvez não pareça grande coisa, mas enfim.
Sabe o que é engraçado? Leio esses comentários e me lembro de quando programava em Perl e achava a linguagem o máximo também.
Lembro de um problema que tive justo com o sistema de threads, visto problemas de compilação. Isso foi em 2003, e eu já programava pelo menos um ano com a linguagem.
Enfim, a linguagem continua com as mesmas características nos pontos que comentei, e o único jeito de corrigir os problemas é quebrando compatibilidade.
Resumindo, na questão linguagem, Perl deixa realmente muito a desejar, e existem linguagens que estão a anos luz em nível de expressividade, coerência e corretude – mas se ela resolve seus problemas de maneira mágica e miraculosa, continue usando ela e seja feliz. Ok?
E é isso.
Leonardo
Não é questão de “achar o máximo” ou não. É questão de criticar com embasamento, você não apresentou argumento algum a não ser a tua opinião pessoal e arbitrária sobre a linguagem. Se você quer discutir os diversos problemas da linguagem, fala sobre um que realmente existe, tem vários pra você escolher e eu já falei sobre alguns anteriormente.
Quer dizer que você nem leu direito a única citação que você usou como referência? Isso tá com cara de FUD gratuito.
Um ano não é suficiente pra falar autoritativamente sobre linguagem alguma.
O problema que você postou em 2003 não tem nada a ver com threads ou com a linguagem ou com a compilação, tem a ver com quebra de retrocompatibilidade específica entre o Gtk2 e a biblioteca de binding, isso acontece o tempo todo em qualquer linguagem.
O problema que tem com perl e threads é vazamento de memória. E os mantenedores da linguagem ignoram o problema porque a maioria dos desenvolvedores perl prefere o modelo de fork() invés de threads.
“expressividade”, “coerência” e “corretude” nesse contexto são termos subjetivos. Faltou uma crítica mais objetiva e embasada, posta um artigo comparando exemplos de “expressividade”, “coerência” e “corretude” de uma linguagem qualquer com o equivalente em perl (mas lê o artigo todo dessa vez, ok?)
Novamente, a única “mágica” envolvida pra resolver os problemas é conhecer a sintaxe básica da linguagem, e isso se aplica a qualquer linguagem. No caso de perl, aprender precedência e dereferenciação é conhecimento básico, assim como é em C (com ponteiros), ou Python, ou Ruby ou qualquer linguagem de escala industrial.
Eu particularmente prefiro haskell à qualquer outra sintaxe. O problema que eu quero ilustrar aqui é que é injusto qualificar qualquer linguagem sem ter conhecimento mínimo.