E se o compilador jogasse um warning quando estamos usando algo que claramente tem undefined behavior (como alguns casos tabelados) ?
Seria o melhor dos dois mundos: ou o programador sabe com certeza o que esta fazendo ou o compilador/interpretador/etc avisa "hum... danadinho..." 2011/2/14 Blabos de Blebe <[email protected]> > >> Enfim, o que quero dizer é que o Perl tem um imenso potencial de > produzir > >> código cheio de Pseudo-undefined Behavior; por que ninguém tem obrigação > de > >> saber todas as faces de todos os operadores; isso sem contar as > L<perlvar>. > > Este email também tem potencial pra produzir undefined behavior. > Deveríamos parar de escrever emails por causa disso? > > Opa, espere um momento. Como assim um programador não deve saber > exatamente o que ele está usando? > > É claro que o programador *tem* sim que conhecer exatamente como > funciona cada token que ele está usando, senão é melhor ir vender água > de coco na praia. > > É por isso que certas empresas abrem certas falhas de segurança em > certos servidores de produção. > > O problema é que Perl é uma linguagem muito abrangente e concordo com > vc que é praticamente impossível memorizar todos os operadores. Mas se > vc *usa*, vc é obrigado a saber. > > O ponto aliás nem é esse. Desconhecer, não implica em undefined > behavior. Implica em não obter o resultado que era esperado, logo a > falha está em não ser competente o suficiente para usar esta > ferramenta da linguagem. > > Já em C por exemplo, existem construções que *produzem* undefined > behavior, ou seja fica a cargo de quem implementou o compilador > resolver. Se ele quiser formatar seu disco ao atingir um ponto desses, > ele é livre pra isso. > > Por exemplo, o padrão C não define se variáveis automáticas (alocadas > na pilha) são ou não inicializadas automaticamente. Daí, num > compilador do Solaris (o Fernando pode confirmar), todas as variáveis > automáticas são inicializadas automaticamente (zero para inteiros). Já > no gcc não (mantém-se o valor que já estava na memória). Então, você > escreve um código no Solaris, compila, testa, homologa e ok. Aí você > leva esse código, que está dentro do padrão, para compilar no gcc e ao > rodar na nova plataforma ele quebra. > > Isso sim é um problema. O mesmo código, estritamente dentro do padrão, > apresentando comportamentos diferentes dependendo da situação. > > Oras, o programador experiente tem que conhecer bem a linguagem pra > não cair nessas armadilhas. Se não conhece, não deveria codificar > *profissionalmente*. > > É como se eu pegasse uma faca e saísse dizendo que sou cirurgião, só > porque sei cortar carne. E aí, posso fazer uma neurocirugia em você? > Eu tenho potencial pra ser um ótimo cirurgião :) > > As pessoas tem que ter mais responsabilidade. Hoje qualquer mané que > mal consegue encadear uma idéia, aprende um if e um for, copia e cola > Perl 3 do forum ultra hacker e sai falando que é Analista Programador. > É foda viu! > > De qualquer forma eu acho ótimo esse debate com pontos de vistas > diferentes. Ninguém é dono da verdade. > > Abraços > > 2011/2/14 Stanislaw Pusep <[email protected]>: > > Aliás, o que explode o meu cérebro é a frase "These rules look > complicated, > > but usually they will do what you want.", a respeito do "given/when", > também > > em L<perlsyn> ;) > > > > ABS() > > > > > > > > 2011/2/14 Stanislaw Pusep <[email protected]> > >> > >> Ehehe, vou tentar contextualizar a minha lembrança... Tomo como exemplo > a > >> "tabela-verdade" do operador ~~ ("smart matching", L<perlsyn>): > >> > >> $a $b Type of Match Implied Matching Code > >> ====== ===== ===================== ============= > >> Any undef undefined !defined $a > >> > >> Any Object invokes ~~ overloading on $object, or dies > >> > >> Hash CodeRef sub truth for each key[1] !grep { !$b->($_) > } > >> keys %$a > >> Array CodeRef sub truth for each elt[1] !grep { !$b->($_) > } > >> @$a > >> Any CodeRef scalar sub truth $b->($a) > >> > >> Hash Hash hash keys identical (every key is found in > >> both hashes) > >> Array Hash hash slice existence grep { exists > >> $b->{$_} } @$a > >> Regex Hash hash key grep grep /$a/, keys > %$b > >> undef Hash always false (undef can't be a key) > >> Any Hash hash entry existence exists $b->{$a} > >> > >> Hash Array hash slice existence grep { exists > >> $a->{$_} } @$b > >> Array Array arrays are comparable[2] > >> Regex Array array grep grep /$a/, @$b > >> undef Array array contains undef grep !defined, @$b > >> Any Array match against an array element[3] > >> grep $a ~~ $_, @$b > >> > >> Hash Regex hash key grep grep /$b/, keys > %$a > >> Array Regex array grep grep /$b/, @$a > >> Any Regex pattern match $a =~ /$b/ > >> > >> Object Any invokes ~~ overloading on $object, or falls > >> back: > >> Any Num numeric equality $a == $b > >> Num numish[4] numeric equality $a == $b > >> undef Any undefined !defined($b) > >> Any Any string equality $a eq $b > >> > >> 1 - empty hashes or arrays will match. > >> 2 - that is, each element smart-matches the element of same > index > >> in the > >> other array. [3] > >> 3 - If a circular reference is found, we fall back to > referential > >> equality. > >> 4 - either a real number, or a string that looks like a number > >> > >> Olha, não sei quanto aos outros participantes da lista, mas eu > >> simplesmente não consigo me ater a todos esses detalhes > >> :( > >> Então nunca uso esse operador que me confunde (PARA MIM, é um "Undefined > >> Behavior"), preferindo fazer "à moda antiga" (última coluna). Enfim, sou > >> desses caras que enchem qqer operação de ()'s, tipo: ((($x / $y) - $z) > > 0). > >> Enfim, o que quero dizer é que o Perl tem um imenso potencial de > produzir > >> código cheio de Pseudo-undefined Behavior; por que ninguém tem obrigação > de > >> saber todas as faces de todos os operadores; isso sem contar as > L<perlvar>. > >> > >> ABS() > >> > >> > >> > >> 2011/2/14 Blabos de Blebe <[email protected]> > >>> > >>> Oras, isso me lembra > >>> > >>> http://www.ioccc.org/1987/wall.c > >>> > >>> Uma coisa é você usar isso em um golf, outra é usar em código de > >>> produção. > >>> > >>> Tem gente que empeteca o código com meia dúzia de regexp e se ahca 'O > >>> Hackerzão'. > >>> > >>> A maior parte dos bugs (com os quais estou lidando agora, por > >>> exemplo), teria sido evitada se fossem respeitados os padrões mínimos > >>> de boas práticas. Coisa que qualquer estagiário *deveria* sair da > >>> escolinha sabendo. > >>> > >>> Abraços > >>> > >>> 2011/2/14 Stanislaw Pusep <[email protected]>: > >>> > Não sei pq, mas lembrei da seguinte sintaxe, compilável em Perl: > >>> > > >>> > -f>@+?*<.-&'_:$#/%! > >>> > > >>> > ABS() > >>> > > >>> > > >>> > > >>> > 2011/2/14 Blabos de Blebe <[email protected]> > >>> >> > >>> >> Bom dia, > >>> >> > >>> >> Sem querer entrar em flames, ou no mérito da discussão, que tomo > >>> >> apenas como exemplo. > >>> >> > >>> >> A thread abaixo é uma discussão que está acontecendo na principal > >>> >> lista de C++ brasileira, sobre undefined behavior. > >>> >> > >>> >> > >>> >> > >>> >> > http://groups.google.com/group/ccppbrasil/browse_thread/thread/9b9a7be45917095e# > >>> >> > >>> >> Notem como o Undefined behavior deste exemplo em particular pode ser > >>> >> resolvido com 'codificação elegante'. Ok, o assunto era outro e foi > só > >>> >> um exemplo rápido, mas levantou a discussão que está acontecendo até > >>> >> agora. > >>> >> > >>> >> A maioria dos 'Undefined Behaviors' das linguagens de programação > que > >>> >> conheço (não são muitos) são casos específicos, incomuns, bem > >>> >> documentados, bem avisados, normalmente abertos por 'depender da > >>> >> implementação' e invocados por código porco de programadores > meia-boca > >>> >> (não que este caso de *exemplo* seja um). > >>> >> > >>> >> É claro, nenhuma linguagem é perfeita (exceto lisp), mas elas > possuem > >>> >> especificações, mais abrangentes ou menos abrangentes. Por isso, não > >>> >> importa a linguagem, ou você se aprofunda e aprende, ou mais cedo ou > >>> >> mais tarte, vai acabar caindo em alguma dessas asrmadilhas. > >>> >> > >>> >> Na minha opinião, C tem mais armadilhas e/ou hacks que precisam de > um > >>> >> pouco mais de conhecimento de arquitetura de computadores para > escapar > >>> >> do que Perl, enquanto Perl tem outros tipos de armadilhas. > >>> >> > >>> >> Entenda armadilha aqui como "algo que eu imaginava de um jeito, mas > >>> >> aconteceu de outro", independente da expectativa ser razoável ou > não. > >>> >> > >>> >> O negócio é que como Perl é mais fácil de lidar do que C, você > alcança > >>> >> as armadilhas de Perl mais cedo do que conseguiria caminhar em C > para > >>> >> alcançar as suas, logo, Perl parece mais imprevisível. > >>> >> > >>> >> Abraços > >>> >> =begin disclaimer > >>> >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>> >> SaoPaulo-pm mailing list: [email protected] > >>> >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >>> >> =end disclaimer > >>> > > >>> > > >>> > =begin disclaimer > >>> > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>> > SaoPaulo-pm mailing list: [email protected] > >>> > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >>> > =end disclaimer > >>> > > >>> > > >>> =begin disclaimer > >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>> SaoPaulo-pm mailing list: [email protected] > >>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >>> =end disclaimer > >> > > > > > > =begin disclaimer > > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > > SaoPaulo-pm mailing list: [email protected] > > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > > =end disclaimer > > > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > -- Tiago B. Peczenyj Linux User #405772 http://pacman.blog.br
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
