Algo similar acontece com programação Java para celular.
Dependendo do aparelho e das versões, um mesmo programa pode:
- Funcionar 100% e lhe garantir um contrato de ouro.
- Funcionar 90%, e lhe garantir bugs lists. (Por exemplo, o
programa não permite acessar 1 das telas).
- Ele funciona 50%, e detonar sua reputação. (O programa
funciona a primeira vez, depois precisa reiniciar o aparelho).
- Funciona 0%... ai meu caro, é sentar e chorar, porque muito
provavelmente não apareceu mensagem de erro...
Isso aconteceu comigo, no meu casos foi muito desconfortável, porque
não aparecia erro algum na hora de gerar o Jar... mas, em alguns
aparelhos Nokia (não todos), recebia a mensagem Segmentation Fault.
O motivo?
Eu precisava declarar e preencher previamente todos os espaços dos
arrays, não bastava simplesmente declarar, precisava setar $birosca
= array(0=>"buh", 1=>"buh", etc...).
Meus queridos, que negócio idiota, mas que nervoso eu passei... até
hoje não tenho a explicação exata para esse comportamento... e para
chegar nesse resultado, demorou viu... eu cheguei a reescrever 100%
o programa.
Nunca vi isso ocorrer com qualquer outra linguagem.
Isso resultou em uma máxima que levarei para todo o sempre, rs.
Testar programas para celular = testar no dispositivo.
On 14-02-2011 15:40, Blabos de Blebe wrote:
No gcc alguns undefined behaviors resultam em segmentation fault, como
é o caso da divisão por zero. Já outros podem ou não emitir warnings
conforme você especificar durante a compilação.
Os compiladores normalmente fazem um bom trabalho ao escolher o que
fazer com um undefined behavior.
Mas o ponto é:
Uma coisa é você desconhecer como funciona a feature, outra é a
linguagem especificar que ela não faz idéia do que pode acontecer.
Isso sim é bizarro, na minha opinião.
Abraços
2011/2/14 Tiago Peczenyj <[email protected]>:
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
=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
|
