Visite também: Currículo ·  Efetividade BR-Mac

O que é LinuxDownload LinuxApostila LinuxEnviar notícia


Por que Perl?

“Otávio Fernandes descreve de forma simples e objetiva os motivos que o levaram a estudar Perl. Descreve o processo de aprendizagem e principalmente suas referencias e comparações com outras linguagens assimiladas por ele. uma boa pedida para quem está buscando maiores informações sobre o assunto”

Enviado por Erick Tostes (erickΘgeekbr·com·br) – referência (otaviof.blogspot.com).


• Publicado por Augusto Campos em 2008-10-19

Comentários dos leitores

Os comentários são responsabilidade de seus autores, e não são analisados ou aprovados pelo BR-Linux. Leia os Termos de uso do BR-Linux.

    Tércio Martins (usuário não registrado) em 19/10/2008 às 1:08 pm

    Isso me lembrou de um texto que fala mal de Perl com estilo:

    Laurel e Hardy Tentam Escrever um Programa em C

    foobob (usuário não registrado) em 19/10/2008 às 2:36 pm

    Ótimo link, Tércio! LOL! Capturou muito bem o estilo de comédia do duo… :D

    Por que Perl? Porque geeks amam aprender novas linguagens de programação, mesmo que esotéricas como brainfuck. :)

    Bem, no caso de Perl ainda há o bônus de ser a mais prática maneira de se processar em lote grandes quantidades de arquivos texto. Practical Extraction and Report Language, afinal. Para qualquer coisa além disso, é melhor Python ou Ruby, pois Perl rapidamente vira um amontoado desconexo de pseudoclasses escritas em bash, funções sem parâmetros formais e cifrões pra tudo que é lado que nem todo warning no mundo ajuda…

    O ponto de vista do autor é interessante e consenso entre a maioria dos que programam em Perl, mas existem alguns pontos que ele defende da linguagem que particularmente discordo:

    - Sua sintaxe não é assim tão simples. Perl abusa de símbolos obscuros e regras complexas que dificultam a leitura do código e prejudicam a produtividade.
    - “There is more than one way to do it” pode ser uma virtude, mas também pode ser um problema em projetos complexos, a partir do momento que abre a oportunidade para a “gambiarra” – especilidade brasileira. O resultado novamente são códigos difíceis de entender.
    - Perl é prazeroso até a vigésima linha de código.

    Apesar das críticas, a base de conhecimento do Perl é respeitável. Também é impossível para qualquer um que conheça a trajetória dessa linguagem ignorar sua importância no desenvolvimento do Unix e dos primeiros passos da Web dinâmica.

    E já que o assunto veio à tona, nada melhor do que apimentar essa discussão com o conhecido artigo do Eric Raymond: Why Python?

    Henrique (usuário não registrado) em 19/10/2008 às 8:08 pm

    Porque _não_ Perl:
    Python & Ruby

    Perl foi uma aberração inventada para sysadmins criarem scripts rápidos e sujos de forma um pouco mais poderosa do que shell scripts, sem precisar aprender uma “linguagem de verdade (TM)”. Pra algo a mais do que isso, Perl é um tiro no pé.

    Frederico (usuário não registrado) em 20/10/2008 às 1:30 am

    Incrivel como vocês repetem clichês sem experimentar de fato.

    Simbolos obscuros: Quais simbolos obscuros?

    “rapidamente vira um amontoado desconexo de pseudoclasses escritas em bash, funções sem parâmetros formais e cifrões pra tudo que é lado que nem todo warning no mundo ajuda…”

    pseudoclasses escritas em bash? Essa eu não entendi mesmo.

    Sobre sifrão, toda vez que você ver um sifrão, é sinal que ele é uma variavel escalar. Só isso.

    Eu sugiro uma visita ao http://www.perl.org.br :) Vale a pena para acabar com alguns mitos.

    Selialkile (usuário não registrado) em 20/10/2008 às 8:39 am

    Eu acho Perl foda… viva o Perl o/
    Mando bem Pombo!

    Leandro Mendes (usuário não registrado) em 20/10/2008 às 9:06 am

    Particularmente não gosto de Perl, mas respeito a linguagem. Eu me sentia tremendamente incomodado com aquele monte de operadores, mas enfim, depois de um certo tempo vi que outras linguagens também ofereciam a mesma complicação (Ruby por exemplo, também tem ‘@var’, ‘$var’ e ‘var’).

    Acredito antes de criticar de determinada linguagem, primeiro precisa-se ter um conhecimento profundo da mesma, e que a melhor linguagem é sempre aquela qual você tem o domínio.
    Parabéns pelo artigo Otávio!

    Incrivel como vocês repetem clichês sem experimentar de fato.
    Simbolos obscuros: Quais simbolos obscuros?

    #!/usr/bin/perl
    sub u { local($name)=getpwuid($_[0]); $name && "($name)";}
    sub g { local($name)=getgrgid($_[0]); $name && "($name)";}
    sub bynum { $a - $b; }
    print "uid=$<",&u($",&u($>) if $> != $<;
    print " egid=", $)+0,&g($)) if $) != $(;
    @groups=split(' ',$(); shift(@groups);
    print " groups=", join(',',sort bynum grep(($_ .= &g($_)) || 1, @groups))
    unless $#groups < $[;
    print " ";

    Orientação a objeto?

    package MyClass;
    sub new {
    my $class = shift;
    my $self = {};
    bless $self, $class
    $self->initialize(); # do initialization here
    return $self;
    }

    Lógico que existem qualidades no Perl, mas legibilidade com certeza não é uma delas.

    Bruno (usuário não registrado) em 20/10/2008 às 10:49 am

    Legibilidade é uma das competências do programador, e nunca conheci uma linguagem que impossibilitasse a criação de códigos difíceis de compreender. Perl é uma linguagem fantástica e a ferramenta certa para determinadas tarefas. O mesmo vale para Ruby, Python, C#, Java ou seja lá o que estiver na moda.

    Legibilidade é uma das competências do programador, e nunca conheci uma linguagem que impossibilitasse a criação de códigos difíceis de compreender.

    Se incluirmos na discussão a competência do programador realmente não vamos chegar a lugar nenhum. Sem dúvida é possível encontrar piores exemplos em Python ou Ruby, mas a idéia que gostaria de passar em meu comentário inicial é que, ao contrário dessas duas linguagens, o Perl dificulta muito a tarefa de escrever códigos legíveis.

    Perl é uma linguagem fantástica e a ferramenta certa para determinadas tarefas. O mesmo vale para Ruby, Python, C#, Java ou seja lá o que estiver na moda.

    Concordo plenamente, Bash e Perl ainda são as mais linguagens mais práticas nas tarefas relacionadas a administração de sistema, além de terem a popularidade a seu favor, o que reflete na abundância de documentação. Python e Ruby, apesar de serem linguagens mais completas e para propósitos gerais, ainda encontram resistência quando o assunto é administração de sistemas.

    Daniel (usuário não registrado) em 20/10/2008 às 12:35 pm

    O Otávio disse td nesta frase : “vai exigir dos programadores conceitos e disciplina”. Programadores amadores ou usuários de frameworks não estão nem um pouco interessados nestas duas características; apontar e clicar é muito mais simples que Perl e por isto Perl é para poucos. Sou usuário da linguagem há dez anos e criei de soluções complexas a simples scripts administrativos usando Perl. Posso dizer categoricamente que é a mais produtiva linguagem que já utilizei.

    Frederico (usuário não registrado) em 20/10/2008 às 12:46 pm

    Heitor Augusto,

    Perl não dificulta escrever codigos legiveis, em geral sysadmins não são programadores “de fato”, alguns tem anos de experiencia sem ter feito uma cadeira de programação ou tentado aprender alguma linguagem profundamente.

    Assim como um programador não saberá configurar um servidor tão bem quando um sysadmin. Notem que eu não estou entrando no merito de outras linguagens, simplesmente estou defendendo perl da “fama”.

    Qualquer um que usou perl por mais de uma semana ia ler o codigo facil. Qualquer linguagem que eu não conheça, vou achar o codigo estranho ao bater os olhos.

    Otávio Fernandes (usuário não registrado) em 20/10/2008 às 3:55 pm

    Senhores,

    Fico feliz que a nossa discussão esteja sendo saudável. Quero lembrar: Perl é uma linguagem com mais de 20 anos de história, e, é padrão em todos os unix-like, tanto o interpretador quanto centenas de scripts para os mais diversos fins. Devemos pensar no seu mérito e o porque ela está há tanto tempo no mercado.

    Qualquer linguagem pode ser boa ou ruim, depende de quem escreve. Não é justo culpar a tecnologia pelos erros humanos!

    um abraço,

    Otávio Fernandes

    Luana (usuário não registrado) em 20/10/2008 às 7:00 pm

    Heitor Augusto,

    sua demonstração de “símbolos obscuros” em Perl é um exemplo clássico de código obscuro: sem documentação, com funções e variáveis usando nomes pouco significativos e sem estruturação. Também é um exemplo clássico de desinformação: o código mostrado, além do que já foi dito, é de 1991 e usando Perl 4 – linguagem completamente diferente do Perl 5 (cujo primeiro release foi em 1994 e hoje já se encontra na versão 5.10, lançada no fim do ano passado).

    É fácil encontrar exemplos semelhantemente obscuros em qualquer linguagem de programação, do Java ao Python.

    Perl é uma linguagem que dá liberdade e flexibilidade ao desenvolvedor. Essa liberdade pode ser usada com responsabilidade ou abusada – depende única e exclusivamente do programador.

    O seu exemplo, uma versão simplificada do comando ‘uid’, poderia ser escrito da seguinte forma (bem mais longa, porém bem mais legível):


    #!/usr/bin/perl
    # programa que simula o comportamento da ferramenta 'id',
    # exibindo informações sobre o processo que o executa.
    use strict;
    use warnings;
    use English;
     
    ### exibe informações de usuário
    print "uid=$UID" . get_username($UID);
     
    ### o mesmo usuário pode estar em mais de um
    ### grupo, então obtemos os ids de cada grupo
    my @groups = split / /, $GID;
     
    ### retiramos o primeiro grupo da lista,
    ### já que o comando 'id' o exibe separadamente
    my $main_gid = shift @groups;
     
    ### exibe informações de grupo
    print " gid=$main_gid" . get_groupname($main_gid);
    if ($UID != $EUID) {
       print " euid=$EUID" . get_username($EUID);
    }
    if ($GID != $EGID) {
       print " egid=$EGID" . get_groupname($EGID);
    }
     
    # exibe grupos adicionais, se existirem.
    if (@groups) {
       show_extra_groups(@groups);
    }
     
    print " "; # pula linha, e acabamos.
    exit;
     
    ### show_extra_groups() - recebe lista de "group ids"
    ### e exibe seus nomes ordenadamente
    sub show_extra_groups {
       my @groups = @_;
       @groups = sort by_number @groups;
       foreach my $gid (@groups) {
          $gid .= get_groupname($gid);
       }
       print " groups=" . join ',', @groups;
    }
     
    ### by_number() - associa comparação numérica
    ### ao comando 'sort'
    sub by_number { $a $b }
     
    ### get_username_from_id() - recebe um id de usuário e
    ### retorna seu nome, entre parêntesis.
    sub get_username {
       my $user_id = shift;
       return '(' . getpwuid($user_id) . ')';
    }
     
    ### get_groupname() - recebe um id de grupo e
    ### retorna seu nome, entre parêntesis.
    sub get_groupname {
       my $user = shift;
       return '(' . getgrgid($user) . ')';
    }

    Mesmo um programador que não sabe Perl sabe dizer o que está acontecendo nesse código, e não só pelos comentários como pela própria estrutura do mesmo. O código acima tem 63 linhas, incluindo comentários e linhas em branco. A título de comparação, o fonte em C atual do binário “id” possui 296 linhas, excluindo comentários e linhas em branco. E não é nem de longe tão legível. Gostaria de ver implementações em outras linguagens também, sem o uso de módulos auxiliares.

    Perl tem vários defeitos, mas também várias qualidades – assim como qualquer linguagem. Gostaria que tivesse mais cuidado ao comentar com preconceito ou dar opiniões sobre o que não conhece, baseando-se em velhos clichês que não se aplicam a realidade.

    Luanda,

    sua demonstração de “símbolos obscuros” em Perl é um exemplo clássico de código obscuro: sem documentação, com funções e variáveis usando nomes pouco significativos e sem estruturação. Também é um exemplo clássico de desinformação: o código mostrado, além do que já foi dito, é de 1991 e usando Perl 4 – linguagem completamente diferente do Perl 5 (cujo primeiro release foi em 1994 e hoje já se encontra na versão 5.10, lançada no fim do ano passado).

    Você tem razão, o exemplo citado é realmente antigo (1990). Também confesso que foi um exagero e que não é a melhor implementanção, mas é um exemplo perfeito de que o Perl, mesmo se considerarmos a versão atual, permite e facilita esse tipo de exagero. Reforça essa idéia o fato de que o código foi escrito por Randal Schwartz, programador indubitavelmente competente e referência quando o assunto é Perl. E melhor ainda é a versão desse código sugerida pelo próprio Larry Wall, criador da linguagem:

    #!/usr/bin/perl
    @n=('pwu','grg');sub n{local($n)=eval"get$n[$_[1]]id($_[0])";$n&&"($n)";}sub nm
    {$a-$b;}@gr=split(' ',$();$g=shift(@gr);$=" ";print"uid=$<",&n($".&n($>))x($),(" egid=".$)+0 .&n($),1))x($(!=$)),
    (" groups=".join(',',sort nm grep(($_.=&n($_,1))||1,@gr)))x($#gr>=0);

    A mensagem original pode ser vista neste link.

    É fácil encontrar exemplos semelhantemente obscuros em qualquer linguagem de programação, do Java ao Python.

    Concordo, no entanto vou continuar batendo na mesma tecla: é muito mais fácil encontrar esse tipo de exemplo em Perl. O esforço para escrever um código ilegível em Python ou em Ruby é muito maior.

    Quanto a sua versão do código, foi muito interessante e muito mais legível. Agora, compará-la com a versão em C não é a melhor forma de justificar essa legibilidade ou o tamanho do código.

    Perl tem vários defeitos, mas também várias qualidades – assim como qualquer linguagem. Gostaria que tivesse mais cuidado ao comentar com preconceito ou dar opiniões sobre o que não conhece, baseando-se em velhos clichês que não se aplicam a realidade.

    Perdão se lhe pareceu preconceito. Eu gosto do Perl, principalmente porque confio a ele muitas das tarefas de administração de sistemas. Sinceramente, minha intenção desde o início foi defender a idéia de que o Perl compromete a legibilidade do código com sua sintaxe complexa, grande quantidade de símbolos especiais e falta de suporte a orientação a objeto. É frustrante para qualquer programador encontrar um código como o do Larry para dar manutenção, e quando se trata do Perl, isso é uma situação corriqueira.

    Substitua em meu comentário anterior “falta de suporte a orientação a objeto” por “suporte precário a orientação objeto”.

    foobob (usuário não registrado) em 21/10/2008 às 12:29 am

    Caros, classes em bash foi uma brincadeira, mas o fato é que as classes de Perl 5 são um hack em cima de uma linguagem essencialmente de shell scripting. Ruby também tem os símbolos obscuros porque é uma espécie de descendente de Perl (e também de Smalltalk e Lisp)…

    O problema de Perl não são só os símbolos que é, dos males, o menor. O problema é contexto. Perl é uma linguagem insanamente sensível ao contexto, assim como C++. @foo pode ser um array, mas vc também pode ter uma referência escalar $ oo e acessar $ oo->[0] etc, se bem me lembro, dentre outras insanidades. E que tal todos os operadores críptcos? Tirar parâmetros de uma lista manualmente é um pé no saco. E o que é while(), ou foo if /^.*$/ para alguém lendo a linguagem pela primeira vez? Tudo depende de contexto e quem não conhece as manhas vai ficar boiando…

    É muito prática para shell scripting e processamento de textos, sim. Mas, mais do que isso, é pedir para sofrer. Fora que no meio tempo em que Perl 6 tem estado em desenvolvimento — o que, já uns 8 anos? — Ruby e Python tomaram a dianteira e não largaram mais. Linguagens não morrem realmente, mas acho que Perl é agora mero legado do passado com pouco uso, como AWK ou M4…

    Vá lá, aprender todas as ferramentas que vêm com uma distro Linux pode ser um desafio intelectual interessante, mas eu daria mais atenção a linguagens mais robustas… :)

    foobob (usuário não registrado) em 21/10/2008 às 12:31 am

    seria while( <> )… :P

    foobob (usuário não registrado) em 21/10/2008 às 12:37 am

    Luana:
    “Gostaria de ver implementações em outras linguagens também, sem o uso de módulos auxiliares.”

    Luana, minha cara, modularidade é uma coisa boa e, no mínimo, significa que não preciso ter 1000 operadores monossilábicos ocupando o mesmo namespace ao mesmo tempo. Pode não ser tão prático quanto ter tudo-ao-mesmo-tempo-agora, mas com certeza é muito mais manutenível.

    Reforça essa idéia o fato de que o código foi escrito por Randal Schwartz, programador indubitavelmente competente e referência quando o assunto é Perl. E melhor ainda é a versão desse código sugerida pelo próprio Larry Wall, criador da linguagem

    A thread menciona que o código é um desafio de Perl Golf, uma atividade recreativa bastante comum entre os mais habilidosos com a linguagem, e o Larry não recomenda o código, inclusive, comenta a respeito da legibilidade, no mesmo post. Ou houve uma falha na compreensão do inglês, e nesse caso, qualquer linguagem de programação vai ser “obscura”, ou então você está despejando a sua frustração pessoal com a linguagem, deturpando o post do Larry de propósito.

    Perdão se lhe pareceu preconceito. Eu gosto do Perl, principalmente porque confio a ele muitas das tarefas de administração de sistemas. Sinceramente, minha intenção desde o início foi defender a idéia de que o Perl compromete a legibilidade do código com sua sintaxe complexa, grande quantidade de símbolos especiais e falta de suporte a orientação a objeto. É frustrante para qualquer programador encontrar um código como o do Larry para dar manutenção, e quando se trata do Perl, isso é uma situação corriqueira.

    Qualquer pessoa iniciada em engenharia sabe que a deterioração de sistemas é um problema recorrente (vide Curva da Banheira) e se manifesta em qualquer sistema utilizando qualquer tecnologia. Python e Ruby ainda não tem sistemas legados tão bizarros quanto Perl ou C porque ainda são infantes, vamos ver como vão estar as coisas daqui a 20 anos, aliás, vamos ver quantos sistemas desenvolvidos nessas linguagens mais recentes ainda vão estar rodando em produção até lá.

    Substitua em meu comentário anterior “falta de suporte a orientação a objeto” por “suporte precário a orientação objeto”.

    Isso seria verdade na década de 90, porém você obviamente está desinformado e/ou desatualizado. Perl tem um sistema bastante moderno de Orientação a Objeto, baseado em CLOS e Smalltalk:

    Luana, minha cara, modularidade é uma coisa boa e, no mínimo, significa que não preciso ter 1000 operadores monossilábicos ocupando o mesmo namespace ao mesmo tempo. Pode não ser tão prático quanto ter tudo-ao-mesmo-tempo-agora, mas com certeza é muito mais manutenível.

    Modularidade é uma coisa bastante incentivada na comunidade Perl e é por isso que o CPAN é o maior e mais antigo repositório de módulos do planeta, e na verdade, é um dos poucos motivos pelo qual eu uso Perl. Inclusive, recentemente Ruby e Python imitaram a iniciativa.

    O problema de Perl não são só os símbolos que é, dos males, o menor. O problema é contexto. Perl é uma linguagem insanamente sensível ao contexto, assim como C++. @foo pode ser um array, mas vc também pode ter uma referência escalar $ oo e acessar $ oo->[0] etc, se bem me lembro, dentre outras insanidades.

    É, você não lembra, é assim:

    my @foo = (10, 20);my $bar = @foo;$bar->[0]; # 10$bar->[1]; # 20

    E isso não tem nada a ver com contexto.

    Olha um trecho de C mais ou menos equivalente em termos de sintaxe:

    int foo[] = {10, 20};int *bar = foo;bar[0]; # 10bar[1]; # 20

    E que tal todos os operadores críptcos?

    Cita um, por favor.

    Tirar parâmetros de uma lista manualmente é um pé no saco.

    Também vou ser subjetivo e arbitrário: Declarar protótipos também é.

    E o que é while(), ou foo if /^.*$/ para alguém lendo a linguagem pela primeira vez?

    “while” e “if”, são palavra-chaves padrão em linguagens procedurais.

    Quanto às expressões regulares, talvez você ache mais legível e conveniente utilizar a sintaxe acadêmica para expressar suas expressões regulares, ou então implementar um LALR(1) manualmente, ou talvez yacc/bison?

    Perl realmente tem um grande problema: se tornou popular a ponto de ter muita gente comentando, sem saber o que está falando. Essa thread toda tá me lembrando de quando eu recomendo linux pra alguém e eles respondem “ah, mas é feio e eu não sei nem quero ter que aprender a usar linha de comando”.

    argh, maldito wordpress

    my @foo = (10, 20);
    my $bar = @foo;
    $bar->[0]; # 10
    $bar->[1]; # 20

    int foo[] = {10, 20};
    int *bar = foo;
    bar[0]; # 10
    bar[1]; # 20

    Qualquer pessoa iniciada em engenharia sabe que a deterioração de sistemas é um problema recorrente (vide Curva da Banheira) e se manifesta em qualquer sistema utilizando qualquer tecnologia. Python e Ruby ainda não tem sistemas legados tão bizarros quanto Perl ou C porque ainda são infantes, vamos ver como vão estar as coisas daqui a 20 anos, aliás, vamos ver quantos sistemas desenvolvidos nessas linguagens mais recentes ainda vão estar rodando em produção até lá.

    Você não precisa de engenharia e nem esperar 20 anos para concluir que Python e Ruby são linguagens bem fundamentadas nos conceitos de OO, e que por serem mais recentes, tiveram a vantagem de aprender com os erros de linguagens como o próprio Perl.

    Isso seria verdade na década de 90, porém você obviamente está desinformado e/ou desatualizado. Perl tem um sistema bastante moderno de Orientação a Objeto, baseado em CLOS e Smalltalk:

    Diferente de Python e Ruby – que nasceram em cima desse conceito – a orientação a objeto no Perl, se me permite a metáfora, não passa de um remendo mal feito. Compará-las nesse quesito é realmente injusto.

    Márcio Vitor (usuário não registrado) em 21/10/2008 às 10:00 am

    Perl vai bem obrigado e é importante salientar que o mercado é quente não só por causa da utilização corporativa mas também pelo fato do profissional Perl ser reconhecidamente um profissional qualificado, Phyton e Ruby são sim atraentes e e estão nos holofotes atraindo a garotada com o seu bom marketing, mas quem conhece ou pode aprender a usar o potencial do Perl não perde em nada em comparação as outras linguagens citadas, vou listar três sources disponíves no cpan que utilizo e considero dos mais modernos:

    Moose – A postmodern object system for Perl 5
    The Elegant MVC Web Application Framework
    Extensible and flexible object relational mapper
    Impressionante, todo mundo fala que Perl é ilegível, obscuro e tal, mas quando consigo demonstrar o quão bem uso a linguagem e como fica o código, todo mundo fica impressionado e diz que é bacana, será que é só pra me agradar ?

    foobob (usuário não registrado) em 21/10/2008 às 4:52 pm

    “Olha um trecho de C mais ou menos equivalente em termos de sintaxe”

    Por que está comparando Perl com assembly portátil? Por que não comparar com uma linguagem de alto nível?

    “E que tal todos os operadores críptcos?

    Cita um, por favor.”

    $#, $` e companhia…

    “Tirar parâmetros de uma lista manualmente é um pé no saco.

    Também vou ser subjetivo e arbitrário: Declarar protótipos também é.”

    Você, mais uma vez, está comparando Perl com C, ou talvez Java. Em linguagens de alto nível, os parâmetros formais são simplesmente uma lista de nomes.

    Scheme: (define (soma-dos-quadrados a b) (+ (* a a) (* b b)))
    Python: def soma_dos_quadrados(a b): return a*a+b*b

    Perl: algo como manualmente decompor a lista de parâmetros (implicita!)
    sub soma_dos_quadrados {
    my ($a, $b) = split
    return $a*$a+$b*$b
    }

    Fala sério, $ é uma excelente sacada para “interpolar” variáveis em strings, mas utilizar toda hora é um porre…

    “E o que é while(), ou foo if /^.*$/ para alguém lendo a linguagem pela primeira vez?

    “while” e “if”, são palavra-chaves padrão em linguagens procedurais.”

    Eu falava de if regex e de while( <> )…

    “Quanto às expressões regulares, talvez você ache mais legível e conveniente”

    Não, as regexes Perl e sua sintaxe integrada são a grande força de Perl, uma perfeita linguagem para processamento de texto. Infelizmente, são também abusadas sem dó e não melhoram muito a (i)legibilidade da linguagem…

    foobob (usuário não registrado) em 21/10/2008 às 4:55 pm

    “Moose – A postmodern object system for Perl 5″

    Criação de sistemas OO são um passatempo favorito em diversas linguagens extensíveis, que Perl inegavelmente é.

    Você não precisa de engenharia e nem esperar 20 anos para concluir que Python e Ruby são linguagens bem fundamentadas nos conceitos de OO, e que por serem mais recentes, tiveram a vantagem de aprender com os erros de linguagens como o próprio Perl.

    Não interessa se a linguagem é “bem fundamentada em OO” (seja lá o que isso quer dizer) ou não, o que interessa é que você está atribuindo a uma linguagem específica e a um paradigma específico, um problema que se manifesta naturalmente, em qualquer sistema, com o passar do tempo. Leia com mais atenção o que eu falei e você vai ver que a argumentação a respeito de engenharia não teve nada a ver com OO.

    Diferente de Python e Ruby – que nasceram em cima desse conceito – a orientação a objeto no Perl, se me permite a metáfora, não passa de um remendo mal feito. Compará-las nesse quesito é realmente injusto.

    Não é um remendo mal feito e você não tem autoridade pra falar isso porque está óbvio que você não faz idéia de como Perl é implementado, se soubesse, estaria atacando o gerenciador de memória, que tem problemas bem mais graves que o sistema de OO. Estou curioso pra saber quais features de OO uma linguagem deveria ter e que você acha que está faltando em Perl, pode me citar uma?

    Por que está comparando Perl com assembly portátil?

    Assembly portátil? Indexação de arrays, manipulação e dereferenciação de referências/ponteiros é algo bastante comum em linguagens procedurais.

    Por que não comparar com uma linguagem de alto nível?

    Estou retificando a informação distorcida pela sua falta de conhecimento a respeito da sintaxe de Perl demonstrada no exemplo que você citou. Cite um exemplo de alto nível, de preferência implementado corretamente, que aí poderemos fazer uma comparação.

    “E que tal todos os operadores críptcos?
    Cita um, por favor.”
    $#, $` e companhia…

    $# e $` não são operadores, são variáveis escalares abreviadas que tem equivalentes em Inglês por extenso, como a Luana já demonstrou.

    foobob (usuário não registrado) em 21/10/2008 às 11:47 pm

    “Assembly portátil? Indexação de arrays, manipulação e dereferenciação de referências/ponteiros é algo bastante comum em linguagens procedurais.”

    Você fala como se o paradigma procedural fortemente imperativo fosse algo moderno e duca, morô bicho?

    “Estou retificando a informação distorcida pela sua falta de conhecimento a respeito da sintaxe de Perl demonstrada no exemplo que você citou. Cite um exemplo de alto nível, de preferência implementado corretamente, que aí poderemos fazer uma comparação.”

    É verdade, faz tempo que não pego no bichinho e sua sintaxe e semântica cabeludas não são algo que ficam na memória de bom grado. Bem, apt-get install perl-doc…

    Achei uma função mais interessante no próprio perlsub:

    sub mygrep (&@) {
    my $code = shift;
    my @result;
    foreach $_ (@_) {
    push(@result, $_) if &$code;
    }
    @result;
    }

    Fantástico, não? Com protótipos de parâmetros e tudo o mais…

    Aliás, imagino que &$code examine o item atual através de algum contexto implicito e global, tipo $_…

    Em uma linguagem mais moderna, digamos, python:

    def mygrep(code, *ls):
    return [x for x in ls if code(x)]

    Todo aquele malabarismo manual sumiu! Toda aquela mecânica cujo propósito nada tem com o que você está tentando fazer, mas com satisfazer um compilador/interpretador imbecil. De fato, acho que foi muito oportuna sua comparação com C: perl é o C das linguagens de script…

    O interessante é que no próprio documento diz:
    “Alphanumerics have been intentionally left out of prototypes for the express purpose of someday in the future adding named, formal parameters.”

    Vejam só, eles sabem que é uma coisa boa e “moderna”, digamos assim, e planejam um dia adicioná-las à linguagem. Quem sabe também não adicionem um sistema OO de verdade ao invés do rememdo fuleiro que igualmente exige tanto malabarismo manual hoje…

    “$# e $` não são operadores, são variáveis escalares abreviadas que tem equivalentes em Inglês por extenso, como a Luana já demonstrou.”

    ah, bem. Ainda bem que só vou me deparar com eles dentro de regexes, ou seja, apenas em 80% de código perl…

    Frederico (usuário não registrado) em 22/10/2008 às 1:19 am

    “Aliás, imagino que &$code examine o item atual através de algum contexto implicito e global, tipo $_…”

    Contexto implicito sim, mas não global. Alias o contexto implicito é uma das coisas que eu gosto. Afinal eu não falo explicitamente o tempo todo, nada melhor que programar assim :).

    A mecanica mostrada é para um exemplo de pagina de ajuda.

    sub mygrep ($@) {
    my $code = shift;
    return grep {&$code} @_;
    }

    Para quem conhece o minimo da linguagem, sabe que & esta executando o que vem no scalar em seguida e sobre o grep , perldoc -f grep.

    Na real eu tive dificuldade de pegar na primeira:

    def mygrep(code, *ls):
    return [x for x in ls if code(x)]

    Não vou entrar no merito de python. Eu não conheço python. Um amigo me explicou que o que vem entre [] retorna contexto de vetor, muito parecido com perl até. Depois preciso ver ainda o que é esse *ls. Para mim isso é um simbolo cryptico :P.

    Eu podia fazer a mesma coisa com map, e um monte de jeito a mais (…).

    “Quem sabe também não adicionem um sistema OO de verdade ao invés do rememdo fuleiro que igualmente exige tanto malabarismo manual hoje…”

    Esse argumento dava para rebater extensivamente, além de ser muito vago. Minha resposta vai ser tão boba quanto a afirmação, linguagem OO de verdade só smalltalk :P.

    O fato de eu poder fazer as coisas manuais, não significa que eu não tenha mecanismos bem melhores de OO, vide cpan e as paginas da perldoc. TIMTOWTDI.

    Sempre que sai uma noticia sobre Perl, o pessoal cai de pau falando em legibilidade, que 80% do codigo é regex (…). Isso é quase FUD. Chega a ser engraçado vindo de uma comunidade que sofre com isso.

    Quem fazia as coisas em bash, depois foi para perl, ou python, vai manter o mesmo jeitão do bash de fazer as coisas.

    Não interessa se a linguagem é “bem fundamentada em OO” (seja lá o que isso quer dizer) ou não, o que interessa é que você está atribuindo a uma linguagem específica e a um paradigma específico, um problema que se manifesta naturalmente, em qualquer sistema, com o passar do tempo. Leia com mais atenção o que eu falei e você vai ver que a argumentação a respeito de engenharia não teve nada a ver com OO.

    Tentarei ser mais óbvio. Python é uma linguagem verdadeiramente OO, com uma filosofia que enfatiza a produtividade e preza pela legibilidade do código. Portanto, se considerarmos um mesmo programa escrito tanto em Perl como em Python, daqui a 20 anos, qual deles você acredita que estará mais deteriorado?

    Não é um remendo mal feito e você não tem autoridade pra falar isso porque está óbvio que você não faz idéia de como Perl é implementado, se soubesse, estaria atacando o gerenciador de memória, que tem problemas bem mais graves que o sistema de OO. Estou curioso pra saber quais features de OO uma linguagem deveria ter e que você acha que está faltando em Perl, pode me citar uma?

    Se você voltar ao início da discussão, verá que defendi desde o início a idéia de que o Perl tende a gerar códigos difíceis de compreender, graças ao seu excesso de operadores e sintaxes especiais, combinado com a liberdade do programador de usar e abusar dos mais variados recursos obscuros. Então, mesmo se soubesse, por que atacaria o gerenciamento de memória do Perl?

    E peço desculpas pelo “remendo mal feito”.

    maluco (usuário não registrado) em 22/10/2008 às 1:06 pm

    “Verdadeiramente OO” Realmente, quem diz uma frase dessas não sabe o que diz… Já limitou a linguagem de cara. Na sua opnião em todos os casos devemos usar oo ?

    Não estou aqui defedendo uma linguagem ou outra, mas sim a inteligencia. Nós colocamos limitações em pessoas que não sabem o que fazem, pessoas que conseguem identificar o que estão fazendo não precisam disto para evoluir, não precisa a linguagem dizer “Amigão, você só pode programar em OO e com o codigo identado, por que senão não vou funcionar, por que não é bacana…”

    Eu ? Fico contente de ter pessoas assim no mercado de trabalho. :-). Não estou dizendo de todos que programam em Python, e sim quem protege ela com estes argumentos !!! Oras, quase toda linguagem tem suas vantagens, Python tem suas coisas boas também, mas não precisa defender tão porcamente assim. Se você entrar nestes meritos, vai ver que a cultura Perl é bem mais forte, justamente por tudo o que você disse. :-)

    Para terminar, não gaste teu tempo lendo o que todo mundo faz, por que é bonito, ou essa pratica funciona para maioria. Acredite, gaste tempo tentando entender o “por que das coisas”, *se preocupe* quando você estiver fazendo o mesmo que toda boiada do pasto estiver.

Este post é antigo (2008-10-19) e foi arquivado. O envio de novos comentários a este post já expirou.