[SP-pm] [OFF-TOPIC] Masturbações Mentais sobre Undefined Behavior

[Blabos de Blebe]

>> 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 <creaktive em gmail.com>:
> 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 <creaktive em gmail.com>
>>
>> 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 <blabos em gmail.com>
>>>
>>> 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 <creaktive em gmail.com>:
>>> > Não sei pq, mas lembrei da seguinte sintaxe, compilável em Perl:
>>> >
>>> > -f>@+?*<.-&'_:$#/%!
>>> >
>>> > ABS()
>>> >
>>> >
>>> >
>>> > 2011/2/14 Blabos de Blebe <blabos em gmail.com>
>>> >>
>>> >> 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: SaoPaulo-pm em pm.org
>>> >>  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: SaoPaulo-pm em pm.org
>>> >  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: SaoPaulo-pm em pm.org
>>>  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: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>