Constraints versus responsabilidade
Ronaldo Ferraz
Eu, que sou um fã de linguagens como Lisp, Smalltalk e Ruby,
obviamente para da premissa que liberdade com disciplina é o melhor
caminho.
Aliás, ligando com aquela discussão inicial sobre o gap, duvido muito
que sistemas tipados sejam escaláveis o suficiente para o que se
precisa fazer (escaláveis não em performance, mas em esforço de
desenvolvimento). Uma coisa interessante em cima disso, claro, e
também ligando com o que falamos, é compilação para baixo nível para
deixar a liberdade e manter performance e segurança.
http://www.infoq.com/news/2009/07/Constraints-or-Responsibility
Abraços,
R.
guaracy
> Eu, que sou um fã de linguagens como Lisp, Smalltalk e Ruby,
> obviamente para da premissa que liberdade com disciplina é o melhor
> caminho.
digitação do programa. Ou é obrigado a endentar o código como já se
fazia algo COBOL, ou tem que colocar vírgulas onde um espaço seria
suficiente, ou tem que colocar parênteses (não estou falando de Lisp)
ou mais um monte de coisas. Depois as coisas podem ficar diferentes e
ser necessário ou não declarar o tipo das variáveis. Aqui as coisas
vão desde ter que utilizar três linhas para declarar uma variável 'i'
até não ter que declarar nada e o programa pode fazer uma inferência
lógica do tipo de variável 'automaticamente' apenas verificando se foi
utilizado '+.' no código (não declaro o tipo da variável mas, se
necessitar trocar tenho que alterar o programa; argh).
Não interessa o conjunto de 'normas' utilizados. Sempre terão
programas fazendo coisas erradas ou abortando no meio. Então, que
sejamos mais livres.
> Aliás, ligando com aquela discussão inicial sobre o gap, duvido muito
> que sistemas tipados sejam escaláveis o suficiente para o que se
> precisa fazer (escaláveis não em performance, mas em esforço de
> desenvolvimento). Uma coisa interessante em cima disso, claro, e
> também ligando com o que falamos, é compilação para baixo nível para
> deixar a liberdade e manter performance e segurança.
sistema. Mas é certo que definir o tipo de variável não é sinônimo de
segurança. É mais ou menos com um DbC. É possível definir o que entra
e o que sai mas é possível que algo saia errado no meio do caminho.
Compilar um programa pode ser garantia de melhor performance como pode
ser garantia de segurança. Pelo menos a segurança no sentido do
usuário não ver/alterar o código.
> http://www.infoq.com/news/2009/07/Constraints-or-Responsibility
Depois eu vou dar uma olhadinha lá. Mas já imagino que os dois lados
tenham se manifestado, como é o normal já que todos os lados possuem
suas vantagens e desvantagens.
Guaracy
Rodrigo Kumpera
Eu penso o oposto, acho linguagens dinâmicas um enorme retrocesso.
E a prova disso é que sempre citam as mesmas 3 linguagens (Java, C++ e C)
como exemplos de porque tipagem latente é bom.
Java é uma grande porcaria em parte porque o time do Oak foi obrigado a
acelerar o projeto em mais de um ano. Existem vários relatos de como gente
como Bill Joy, Guy Steele e Gilad Brancha tentaram introduzir conceitos "modernos"[1]
na linguagem mas foram barrados por exigências de executivos da empresa.
Grande parte do problemas do C++ é resultado de complexidade acidental, decisões
ruins [2] ou mesmo pressão dos vários vendors na convergência para um padrão.
Quanto a linguagens serem escaláveis em termos de desenvolvimento, a batata quente
continua na mão de linguagens dinâmicas, pois até hoje a enorme maioria dos grandes
sistemas continuam não sendo feitos com elas.
Porém, o que mais me desagrada em linguagens dinâmicas é que toda propriedade de
softwares escritos nelas é probabilística - tudo em função do tamanho da suite de testes.
E isso simplesmente não escala, não dá para querer que todo aspecto do sistema seja
verificado através de testes escritos manualmente.
[1] Modernos para os padrões dos anos 80, como polimorfismo paramétrico e variância.
[2] Ruins para quem vê hoje, não sei como era no começo dos anos 90.
Ronaldo Ferraz
2009/7/17 guaracy <guara...@gmail.com>:
> Acho que qualquer linguagem impõe restrições. Começa na hora da
> digitação do programa. Ou é obrigado a endentar o código como já se
> fazia algo COBOL, ou tem que colocar vírgulas onde um espaço seria
> suficiente, ou tem que colocar parênteses (não estou falando de Lisp)
> ou mais um monte de coisas.
Sem dúvida. Isso toca no ponto das gramáticas formais que discutimos
antes. Mas, o artigo fala em um tipo de restrição diferente que é o de
construir em cima da linguagem, algo que mesmo Ruby--com toda sua
flexibilidade e meta-programação, ainda é bem carente. É algo mais na
linha do Smalltalk, Io e Lisp onde uma VM mínima dá balização para
essencialmente a criação de qualquer linguagem, seja de domínio ou
não.
> Não interessa o conjunto de 'normas' utilizados. Sempre terão
> programas fazendo coisas erradas ou abortando no meio. Então, que
> sejamos mais livres.
Certamente. :)
> Não sei se concordo totalmente, já que vai depender do tipo de
> sistema. Mas é certo que definir o tipo de variável não é sinônimo de
> segurança. É mais ou menos com um DbC. É possível definir o que entra
> e o que sai mas é possível que algo saia errado no meio do caminho.
> Compilar um programa pode ser garantia de melhor performance como pode
> ser garantia de segurança. Pelo menos a segurança no sentido do
> usuário não ver/alterar o código.
Por compilação, eu estava falando mais no sentido de conversão de uma
representação para outra e não de interpretado versus compilado como
normalmente usamos os termos hoje.
Concordo, em absoluto, que definir o tipo de uma variável não resolve
nada. E acho mais, que é bem contra-intuitivo pensar em tipo. Uma das
coisas pouco exploradas--e acho que o OMeta e similares estão indo um
pouco nesse linha--é de deixar para tipos somente as definições mais
basais mesmo e construir gramáticas/sistemas formais sobre isso (como
o Haskell faz, por exemplo).
>> http://www.infoq.com/news/2009/07/Constraints-or-Responsibility
>
> Depois eu vou dar uma olhadinha lá. Mas já imagino que os dois lados
> tenham se manifestado, como é o normal já que todos os lados possuem
> suas vantagens e desvantagens.
Sim, com certeza. :)
Abraços,
R.
Ronaldo Ferraz
2009/7/17 Rodrigo Kumpera <kum...@gmail.com>:
> Eu penso o oposto, acho linguagens dinâmicas um enorme retrocesso.
> E a prova disso é que sempre citam as mesmas 3 linguagens (Java, C++ e C)
> como exemplos de porque tipagem latente é bom.
Please, clarify. Não entendi a relação entre a "prova" oferecida e o argumento.
> Java é uma grande porcaria em parte <snip>
> Grande parte do problemas do C++ é resultado <snip>
O que é absolutamente irrelevante para a questão de estática versus
dinâmicas. Toda linguagem é uma porcaria. Ruby tem enormes
inconsistências como o tem Lisp, Smalltalk, Haskell, etc, até por
causa da impossibilidade de formalizar 100% e ter algo programável
(veja Prolog).
> Quanto a linguagens serem escaláveis em termos de desenvolvimento, a batata
> quente
> continua na mão de linguagens dinâmicas, pois até hoje a enorme maioria dos
> grandes
> sistemas continuam não sendo feitos com elas.
Discordo. Há sistemas enormes escritos em ambas as variantes e mesmo
que estáticas sejam mais representativas, é mais uma questão de
mercado do que do resto. Vide Windows versus qualquer outra coisa. O
argumento não procede. :)
> Porém, o que mais me desagrada em linguagens dinâmicas é que toda
> propriedade de
> softwares escritos nelas é probabilística - tudo em função do tamanho da
> suite de testes.
> E isso simplesmente não escala, não dá para querer que todo aspecto do
> sistema seja
> verificado através de testes escritos manualmente.
Também não entendi a relevância do argumento aqui. Verificação via
testes é ortogonal à tipagem. Ainda estou para ver algum estudo
conclusivo de que tipagem reduz bugs em geral ou garante a
provabilidade da inexistências dos mesmos. Pode reduzir certas classes
de bugs, mas sistemas estáticos carecem dos mesmos testes que outros.
Só por que há um modismo atual em cima da coisa não quer dizer muito.
Além disso, sistemas estáticos tendem a implementar roteamento de suas
próprias fraquezas via estratégias como AOP, reflexão imediata, etc.
Again, não resolve nada.
Enfim, a dinamicidade a que eu me referia está mais na linha de
crescer a gramática (a la Scala, por exemplo, uma linguagem muito
interessante e extensível sobre a mesma JVM da porcaria do Java) do
que tipagem em si. Strongtalk é outro exemplo, uma Smalltalk com
tipagem opcional mas com inferência de tipos e performance suficiente.
Abraços,
R.
le-silva
> antes. Mas, o artigo fala em um tipo de restrição diferente que é o de
> construir em cima da linguagem, algo que mesmo Ruby--com toda sua
> flexibilidade e meta-programação, ainda é bem carente. É algo mais na
> linha do Smalltalk, Io e Lisp onde uma VM mínima dá balização para
> essencialmente a criação de qualquer linguagem, seja de domínio ou
> não.
linguagem flexível, com uma balização mínima por parte de sua VM.
Talvez seja nessa linha que Ola Bini tem caminhado com Ioke -- ou pelo
meno, acho que esse é seu sonho.
Isso abriria uma leque de possibilidades em termos de -- digamos --
DSLs, que tendem a ser bem produtivas e intuitivas. Mas por outro
lado, acho que seria bem fácil encontrar uma "linguagem diferente" em
cada projeto que você fosse trabalhar.
Já pensou? Vixi! Cruz, credo!
> Concordo, em absoluto, que definir o tipo de uma variável não resolve
> nada. E acho mais, que é bem contra-intuitivo pensar em tipo. Uma das
> coisas pouco exploradas--e acho que o OMeta e similares estão indo um
> pouco nesse linha--é de deixar para tipos somente as definições mais
> basais mesmo e construir gramáticas/sistemas formais sobre isso (como
> o Haskell faz, por exemplo).
declaração de tipo. Acho que um sistema de inferência de tipos
sofisticado, inteligênte, seja o caminho para linguagens de tipagem
latente. Algo mais ou menos na linha do que Scala tem feito, e que C#
também tem buscado incorporar (C# 4.0?).
> Porém, o que mais me desagrada em linguagens dinâmicas é que toda
> propriedade de
> softwares escritos nelas é probabilística - tudo em função do tamanho da
> suite de testes.
> E isso simplesmente não escala, não dá para querer que todo aspecto do
> sistema seja
> verificado através de testes escritos manualmente.
pensamento: "Tenho que escrever testes para garantir cada aspecto do
sistema?"
Esse é um questionamento que adeptos de linguagens dinâmicas não
gostam muito de sofrer, mas... Se ele existe... =)
Rodrigo Kumpera
Opa!
2009/7/17 Rodrigo Kumpera <kum...@gmail.com>:
> Eu penso o oposto, acho linguagens dinâmicas um enorme retrocesso.Please, clarify. Não entendi a relação entre a "prova" oferecida e o argumento.
> E a prova disso é que sempre citam as mesmas 3 linguagens (Java, C++ e C)
> como exemplos de porque tipagem latente é bom.
Foi uma crítica ao artigo. Falar dos problemas de tipagem estática discutindo
Java e C++ é o mesmo que falar dos problemas de linguagens dinâmicas em termos
de VB e php 3.
Dá para por no mesmo saco Ruby e php 3? Se der, então Java da na mesma que Haskell.
> Java é uma grande porcaria em parte <snip>
> Grande parte do problemas do C++ é resultado <snip>
O que é absolutamente irrelevante para a questão de estática versus
dinâmicas. Toda linguagem é uma porcaria. Ruby tem enormes
inconsistências como o tem Lisp, Smalltalk, Haskell, etc, até por
causa da impossibilidade de formalizar 100% e ter algo programável
(veja Prolog).
História nunca é irrelevante, discutir qualquer decisão sem a ótica da
época pela qual ela foi tomada é tolice.
SML é uma linguagem 100% formalizada e é bem complicado argumentar
que ela possui inconsistências. Existem várias críticas as escolhas que
formam feitas, desde a estratificação do sistema de tipos a forma como
módulos funcionam. Mas a consistência é sensivelmente maior que em
relação as linguagens dinâmicas.
Agora se você quer apenas argumentar que todas linguages são ruins, matemática
também é dificil e eu acho que devemos ir fazer compras!
Discordo. Há sistemas enormes escritos em ambas as variantes e mesmo
> Quanto a linguagens serem escaláveis em termos de desenvolvimento, a batata
> quente
> continua na mão de linguagens dinâmicas, pois até hoje a enorme maioria dos
> grandes
> sistemas continuam não sendo feitos com elas.
que estáticas sejam mais representativas, é mais uma questão de
mercado do que do resto. Vide Windows versus qualquer outra coisa. O
argumento não procede. :)
Se existem sistemas enormes escritos em linguagens dinâmicas, eu sinceramente
desconheço. Eu ainda não passei por saber de nenhum com alguns milhões de linhas
de smalltalk, ruby ou python. Sei apenas de alguns projetos grandes com linguagens
dinâmicas que fracassaram.
Sistemas grandes servem para verificar quao fácil uma linguagem é modular e como
linguagens como Ruby são um fracasso nesse sentido.
Também não entendi a relevância do argumento aqui. Verificação via
> Porém, o que mais me desagrada em linguagens dinâmicas é que toda
> propriedade de
> softwares escritos nelas é probabilística - tudo em função do tamanho da
> suite de testes.
> E isso simplesmente não escala, não dá para querer que todo aspecto do
> sistema seja
> verificado através de testes escritos manualmente.
testes é ortogonal à tipagem. Ainda estou para ver algum estudo
conclusivo de que tipagem reduz bugs em geral ou garante a
provabilidade da inexistências dos mesmos. Pode reduzir certas classes
de bugs, mas sistemas estáticos carecem dos mesmos testes que outros.
Só por que há um modismo atual em cima da coisa não quer dizer muito.
Eu recomendo você pesquisar por artigos no citeseer. Existe uma farta literatura
sobre como é possível embutir uma série propriedades em um sistema de tipos,
desde garantir que o código é race-free a sua execução ser time-bound.
Além disso, linguagens com tipagem estática permitem a construção de ferramentas
de análise tão ricas quanto o sistema de tipos. Basta ver ferramentas como findbugs
ou os sistemas de prova automática que usam com MishraC.
Porém te dou um exemplo real, dado que você possui um sistema multi-threaded
que possui um completo protocolo de locking. Como você verifica que ele é livre de
deadlocks? Escreve uma tonelada de testes ou escreve um programa que analisa
se o outro viola alguma das regras?
A primeira forma tem um custo proporcional ao tamanho do programa, a segunda
ao tamanho do conjunto de regras.
Rescentemente eu fiz isso usando sparse para verificar isso em um programa
de tamanho não trivial (quase 300mil linhas de C) e não usou mais que um dia
de trabalho.
As vantagens de um bom sistema de tipos vai muito além dos fontes em si, o
ferramental é infinitamente superior.
Além disso, sistemas estáticos tendem a implementar roteamento de suas
próprias fraquezas via estratégias como AOP, reflexão imediata, etc.
Again, não resolve nada.
Sério? Em linguagens como Haskell ou F# isso é tão problema quanto em
smalltalk.
Enfim, a dinamicidade a que eu me referia está mais na linha de
crescer a gramática (a la Scala, por exemplo, uma linguagem muito
interessante e extensível sobre a mesma JVM da porcaria do Java) do
que tipagem em si. Strongtalk é outro exemplo, uma Smalltalk com
tipagem opcional mas com inferência de tipos e performance suficiente.
Oque scala tem de especial? Sobrecarga de operadores e mônadas tem
em tudo quanto é canto. Porém eu realmente não vejo valor em flexibilidade
sintática quando o resultado disso é um modelo semântico pobre.
Philipe Farias
de testes me parece que está tudo ótimo então.
Mas não acredito que os testes necessariamente devam garantir cada
aspecto do sistema (Pareto).
E como Ronaldo falou, linguagens estáticas também carecem de testes
(frameworks de teste se proliferaram pra esse lado também).
Tem ainda os outros argumentos pro testes defendidos pelos praticantes
de TDD/BDD (eu!) que acredito já tenham lido em algum lugar. Não quero
dizer que eles resolvem todos os problemas apenas que não os vejo como
um.
Ronaldo Ferraz
2009/7/17 Rodrigo Kumpera <kum...@gmail.com>:
> Foi uma crítica ao artigo. Falar dos problemas de tipagem estática
> discutindo
> Java e C++ é o mesmo que falar dos problemas de linguagens dinâmicas em
> termos
> de VB e php 3.
Ainda não consigo ver o argumento. Existem, obviamente, linguagens
melhores em formalização ou qualquer outro critério. Mas uso também é
um critério. Eu acho complicado dissociar as duas coisas em uma
discussão sobre qual é o melhor caminho a seguir. Sejam quais forem as
falhas de Java, C++ & cia, estáticas ou não, o argumento é válido para
elas também.
> Dá para por no mesmo saco Ruby e php 3? Se der, então Java da na mesma que
> Haskell.
Why not? :)
> História nunca é irrelevante, discutir qualquer decisão sem a ótica da
> época pela qual ela foi tomada é tolice.
Claro que não, e eu não cheguei nem perto de afirmar isso. Mas C/C++ e
Java estão tão tarde no desenvolvimento de linguagens que não faz
diferença alguma. Esse é o meu ponto.
> SML é uma linguagem 100% formalizada e é bem complicado argumentar
> que ela possui inconsistências. Existem várias críticas as escolhas que
> formam feitas, desde a estratificação do sistema de tipos a forma como
> módulos funcionam. Mas a consistência é sensivelmente maior que em
> relação as linguagens dinâmicas.
Point granted. Pergunta: há sistemas de grande porte em SML?
Curiosidade mesmo, não provocação.
> Agora se você quer apenas argumentar que todas linguages são ruins,
> matemática
> também é dificil e eu acho que devemos ir fazer compras!
Sim, sim e sim. :) Se existisse alguma linguagem perfeita/completa/etc
não estaríamos tendo essa discussão; se matemática fosse trivial todo
mundo saberia; e compras sempre são interessantes.
> Se existem sistemas enormes escritos em linguagens dinâmicas, eu
> sinceramente
> desconheço. Eu ainda não passei por saber de nenhum com alguns milhões de
> linhas
> de smalltalk, ruby ou python. Sei apenas de alguns projetos grandes com
> linguagens
> dinâmicas que fracassaram.
Então, seu conhecimento é limitado.
Um exemplo de sistema enorme em linguagens dinâmicas é o Kapital da JP
Morgan. Desenvolvimento em Smalltalk, teve seu início no começo da
década de 90. A última informação que tive é que o mesmo tinha cerca
de 3 milhões de linhas de código em Smalltalk no core, mais uma boa
quantidade no app server (GemStone/S).
A menos que algo tenha mudado no último ano, ainda está em produção.
De fato, no começo do ano passado havia vagas disponíveis no time.
Existem também vários sistemas científicos de escala enorme usando
Python e similares.
> Sistemas grandes servem para verificar quao fácil uma linguagem é modular e
> como
> linguagens como Ruby são um fracasso nesse sentido.
Considerando o exemplo acima, é óbvio que a sua afirmação não se sustenta.
> Eu recomendo você pesquisar por artigos no citeseer. Existe uma farta
> literatura
> sobre como é possível embutir uma série propriedades em um sistema de tipos,
> desde garantir que o código é race-free a sua execução ser time-bound.
> Além disso, linguagens com tipagem estática permitem a construção de
> ferramentas
> de análise tão ricas quanto o sistema de tipos. Basta ver ferramentas como
> findbugs
> ou os sistemas de prova automática que usam com MishraC.
MishraC ou Misra C? Até onde eu sei, o Misra C é um conjunto de
_guidelines_ que dificilmente se qualificam como um sistema de prova
automática. Facilitam reliability sim, mas não dá para dizer que
oferecem o tipo de consistência que estamos discutindo.
Sobre o findbugs, mesma coisa.
Além do mais, volto a mencionar o Strongtalk. Concebivelmente, é
possível escrever o mesmo tipo de sistema para uma linguagem dinâmica.
De fato, o próprio Squeak e outras implementações Smalltalk já possuem
versões (admito, rudimentares) disso. É uma questão apenas de
evolução, que é justamente onde a discussão começou em meu primeiro
e-mail.
> Porém te dou um exemplo real, dado que você possui um sistema multi-threaded
> que possui um completo protocolo de locking. Como você verifica que ele é
> livre de
> deadlocks? Escreve uma tonelada de testes ou escreve um programa que analisa
> se o outro viola alguma das regras?
Há várias asserções das quais depende o programa para analisar:
1) A implementação do OS sobre o qual o sistema está rodando também
foi verificada;
2) Não há bugs na implementação do hardware (que, em última instância
é uma transcrição física de software);
3) Todas as regras são conhecidas para a verificação.
Seja qual for o caso, é difícil argumentar que uma linguagem estática
ofereceria algum nível de superioridade aqui.
> A primeira forma tem um custo proporcional ao tamanho do programa, a segunda
> ao tamanho do conjunto de regras.
Se as regras são completamente conhecidas, não há diferença entre uma
linguagem dinâmica e uma estática nesse sentido.
> As vantagens de um bom sistema de tipos vai muito além dos fontes em si, o
> ferramental é infinitamente superior.
Ainda não vi exemplos disso em sua argumentação.
>> Além disso, sistemas estáticos tendem a implementar roteamento de suas
>> próprias fraquezas via estratégias como AOP, reflexão imediata, etc.
>> Again, não resolve nada.
>
> Sério? Em linguagens como Haskell ou F# isso é tão problema quanto em
> smalltalk.
Isso não é óbvio? Eu não estou argumentando que linguagens dinâmicas
sejam perfeitas; antes, estou argumentando que linguagens estáticas
são igualmente imperfeitas. :)
> Oque scala tem de especial? Sobrecarga de operadores e mônadas tem
> em tudo quanto é canto. Porém eu realmente não vejo valor em flexibilidade
> sintática quando o resultado disso é um modelo semântico pobre.
Scala é apenas um exemplo. Mas, mesmo usando Scala, eu não diria que o
modelo semântico é pobre. Ao contrário, pela flexibilidade sintática,
o modelo semântico é tornado melhor.
Aliás, mais uma vez, isso volta justamente ao ponto que me motivou à
discussão: é justamente a flexibilidade que eu acho interessante
porque é nela que eu vejo as maiores possibilidades de coisas
interessantes sendo geradas para o mundo da programação em geral e não
somente para os ares rarefeitos dos projetos que nunca vêem o mundo
darwiniano das implementações efetivas, que é o que realmente importa
para mim.
Em última instância, eu acredito que, se falta mais verificação em
linguagens dinâmicas, isso não reflete uma falha inerente das mesmas e
sim uma visão particular histórica que, felizmente, está mudando
agora.
Abraços,
R.
Leandro
coisas que com Java, por exemplo, o proprio eclipse já me ajuda a
fazer. Sim, o tal ferramental que o Kumpera citou, e que concordo
bastante.
Hoje, é fato, certo ou errado -- acredito que mais errado do que certo
--, às vezes eu ainda penso nisso, principalmente, quando se trata de
fazer refactoring. E qual a minha solução? Uma boa suite de testes.
Afinal, testes não podem faltar; e erros de programação podem (e
vão) surgir em qualquer lugar. Então, testar não é opção.
E pra ser bem sincero e racional, poucas vezes tive problemas com
tipagem dinâmica, coisa que eu diria "ah, se fosse estática não
aconteceria isso". Acho que é mais uma pontinha de medo de quem
programou muitos anos em linguagem de tipagem estática e declaração
formal (nada de inferencia).
Então, acho no final das contas, a questão é: Quantas ferramentas eu
tenho que me ajudam a automatizar minhas verificações, garantir meus
refactorings, garantir que regras estabelecidas de design não estão
sendo feridas, etc???
Há muitas para linguagens de tipagem estática, porque com o Ronaldo
disse, é uma questão de mercado -- as gigantes atualmente são as de
tipagem estática. Mas é bem verdade também que isso tem mudado, e
uma prova disso são as IDEs NetBeans e RubyMine, que trazem
ferramentas bem interessantes. (Sei que há quem discorde, mas quando
se trata de debug, refactoring, etc, eu as acho bem interessante.) E
há também outras ferramentas, mais na linha de "maxucar o código",
por exemplo, como as que o Kung apresentou no evento do Guru-SP esse
ano.
Agora, um pouco mais voltado ao início da thread, será que com uma
maior flexibilidade e possibilidade de estender/criar a gramática,
não sofreremos com a falta de ferrentas? O quão rápido será que as
ferramentas acompanhariam essa "evolução"?
Leandro
Em 17/07/2009, às 18:55, Philipe Farias <philip...@gmail.com>
escreveu:
Guaracy Monteiro
> Eu penso o oposto, acho linguagens dinâmicas um enorme retrocesso.
> E a prova disso é que sempre citam as mesmas 3 linguagens (Java, C++ e C)
> como exemplos de porque tipagem latente é bom.
dois tipos existiam antes de muitos daqui nascerem. A única diferença
é que os processadores estão mais rápidos, existe mais memoria. O
resto são variações do mesmo tema.
--
Guaracy Monteiro
http://fotomix.wordpress.com/
Guaracy Monteiro
> Se existem sistemas enormes escritos em linguagens dinâmicas, eu
> sinceramente
> desconheço. Eu ainda não passei por saber de nenhum com alguns milhões
> de linhas
> de smalltalk, ruby ou python. Sei apenas de alguns projetos grandes
> com linguagens
> dinâmicas que fracassaram.
não atendia
as necessidades ou se quem assumiu não era capacitado para dar
continuidade. Aí
fica aquele negócio de maria vai com as outras, o que é bastante comum.
Para mim, milhões de linhas não dizem muita coisa a respeito de um
projeto. LOC é
um indicador para dizer se o cara escreveu muito ou pouco. O Emacs, por
exemplo,
tem uma boa quantidade de linhas em elisp (nem me interessa quanto) e quase
consigo trocar ele pelo SO. Quando estou nele, nem saio para quase nada.
Pode
ser um exemplo ou teríamos que contar quantas linhas de código ele tem?
O JazzScheme está sendo desenvolvido, na realidade convertido de C para
Scheme
utilizando o Gambit (é necessário contar quantas linhas de código?). É
claro que a
comunidade influi diretamente no desenvolvimento. Por questões de mercado, é
mais fácil seguir o mestre. Se deu certo para eles, vai dar certo para
nós. Não vou
deixar o meu na reta e escolher Lisp, Smalltalk ou etc, mesmo sabendo
(não sei
quantos sabem) que Lisp já controlou hardware de 100 milhões de dólares a
100 milhões de milhas de distância.
Adianta eu citar que diversas companhias ainda trablham com Lisp? Certamente
não. O que interessa é Ruby, Python, Java, etc. Mas se alguém tiver
curiosidade...
http://www.pchristensen.com/blog/lisp-companies/
> As vantagens de um bom sistema de tipos vai muito além dos fontes em si, o
> ferramental é infinitamente superior.
Provavelmente por existir mais gente trabalhando.
Guaracy Monteiro
> Um exemplo de sistema enorme em linguagens dinâmicas é o Kapital da JP
> Morgan. Desenvolvimento em Smalltalk, teve seu início no começo da
> década de 90. A última informação que tive é que o mesmo tinha cerca
> de 3 milhões de linhas de código em Smalltalk no core, mais uma boa
> quantidade no app server (GemStone/S).
>
> A menos que algo tenha mudado no último ano, ainda está em produção.
> De fato, no começo do ano passado havia vagas disponíveis no time.
>
da linguagem. É muito mais fácil conseguir um programador Java do
que um para Lisp ou Smalltalk. Como a comunidade é menor (ou será
que eu estou vendo os llocais errados?), tudo fica mais difícil. O Jecel
estava falando no 10 FISL que está sendo complicando incluir o
Squeak na Debian (quem conhece não se interessa e quem se interessa
não conhece).
O Croquet seria outro projeto interessante (não sei quantas linhas de
código) que estava sendo feita. Como fizeram muita gambiarra para
tudo funcionar como queriam, parece que estão refazendo. Pessoalmente
não gosto do Squeak pela interface muito lúdica e acho que faltam
algumas coisas que um VisualWorks possui. Bom para ser utilizado
para o ensino com crianças. Factor tem uma interface mais séria
mas não sei quem vai usar. :-)
> Além do mais, volto a mencionar o Strongtalk. Concebivelmente, é
> possível escrever o mesmo tipo de sistema para uma linguagem dinâmica.
> De fato, o próprio Squeak e outras implementações Smalltalk já possuem
> versões (admito, rudimentares) disso. É uma questão apenas de
> evolução, que é justamente onde a discussão começou em meu primeiro
> e-mail.
>
Recentemente vi o Doctest do Python. Achei bem legal a forma como foi
concebido. Fiz uma versão rudimentar (apenas para prova de conceito)
para Scheme em 25 linhas (e nem conheço bem a linguagem). Mas quem
precisa de tanto teste se a linguagem permite que seja alterada mesmo
com o programa sendo executado? Em Lisp ou Smalltalk, após o erro basta
efetuar as correções e continuar de onde estava. :-)
Rodrigo Kumpera
Point granted. Pergunta: há sistemas de grande porte em SML?
> SML é uma linguagem 100% formalizada e é bem complicado argumentar
> que ela possui inconsistências. Existem várias críticas as escolhas que
> formam feitas, desde a estratificação do sistema de tipos a forma como
> módulos funcionam. Mas a consistência é sensivelmente maior que em
> relação as linguagens dinâmicas.
Curiosidade mesmo, não provocação.
SML é muito mais um projeto de pesquisa que uma linguagem que se encontra
por ai. Apesar disso existem alguns projetos usando, curiosamente boa parte
é na indústria aeroespacial.
Porém se considerarmos linguagens da sua linhagem, F# e OCaml, você encontrará
muitos e muitos sistemas na área financeira usando.
Um exemplo de sistema enorme em linguagens dinâmicas é o Kapital da JP
Morgan. Desenvolvimento em Smalltalk, teve seu início no começo da
década de 90. A última informação que tive é que o mesmo tinha cerca
de 3 milhões de linhas de código em Smalltalk no core, mais uma boa
quantidade no app server (GemStone/S).
Alguém chegou a estudar o projeto?
Existem também vários sistemas científicos de escala enorme usando
Python e similares.
Sistemas grandes é diferente de um software grande. Perl foi muito usado pelo
projeto genoma, mas se você olhar a complexidade do software escrito em perl,
não é significativo.
> Eu recomendo você pesquisar por artigos no citeseer. Existe uma farta
> Além disso, linguagens com tipagem estática permitem a construção de
> ferramentas
> de análise tão ricas quanto o sistema de tipos. Basta ver ferramentas como
> findbugs
> ou os sistemas de prova automática que usam com MishraC.
MishraC ou Misra C? Até onde eu sei, o Misra C é um conjunto de
_guidelines_ que dificilmente se qualificam como um sistema de prova
automática. Facilitam reliability sim, mas não dá para dizer que
oferecem o tipo de consistência que estamos discutindo.
Sim, MisraC, typo. Eu não disse que MisraC era um sistema de prova automática,
mas me referia a toda pesquisa sobre verificação automática e autonomous reasoning
sobre esse subset do C, incluindo varios produtos.
Além do mais, volto a mencionar o Strongtalk. Concebivelmente, é
possível escrever o mesmo tipo de sistema para uma linguagem dinâmica.
De fato, o próprio Squeak e outras implementações Smalltalk já possuem
versões (admito, rudimentares) disso. É uma questão apenas de
evolução, que é justamente onde a discussão começou em meu primeiro
e-mail.
O sistema de tipos do StrongTalk não é muito avançado, tanto que por isso ele é
opcional e ignorado pela VM durante execução.
Há várias asserções das quais depende o programa para analisar:
> Porém te dou um exemplo real, dado que você possui um sistema multi-threaded
> que possui um completo protocolo de locking. Como você verifica que ele é
> livre de
> deadlocks? Escreve uma tonelada de testes ou escreve um programa que analisa
> se o outro viola alguma das regras?
1) A implementação do OS sobre o qual o sistema está rodando também
foi verificada;
2) Não há bugs na implementação do hardware (que, em última instância
é uma transcrição física de software);
3) Todas as regras são conhecidas para a verificação.
Seja qual for o caso, é difícil argumentar que uma linguagem estática
ofereceria algum nível de superioridade aqui.
Non sequitur. Por esse argumento não é possivel provar absolutamente nada sobre
coisa alguma, oque não é verdade e tão pouco útil. Poder verificar tal propriedade
para um software é incrivelmente útil, bug no SO ou hardware são ortogonais.
Se as regras são completamente conhecidas, não há diferença entre uma
> A primeira forma tem um custo proporcional ao tamanho do programa, a segunda
> ao tamanho do conjunto de regras.
linguagem dinâmica e uma estática nesse sentido.
A diferença é gritante. Com uma linguagem dinâmica você não tem como codificar
essas regras de forma a serem provadas de forma autônoma, em algumas linguagens
com tipagens estáticas isso é possivel.
Scala é apenas um exemplo. Mas, mesmo usando Scala, eu não diria que o
> Oque scala tem de especial? Sobrecarga de operadores e mônadas tem
> em tudo quanto é canto. Porém eu realmente não vejo valor em flexibilidade
> sintática quando o resultado disso é um modelo semântico pobre.
modelo semântico é pobre. Ao contrário, pela flexibilidade sintática,
o modelo semântico é tornado melhor.
Como uma coisa pode influir na outra me falha à razão. Você pode estar falando da
legibilidade do código, nesse ponto sim, flexibilidade sintática faz uma grande diferença.
Porém tudo no final, no caso de Scala, será convertido para o sistema de tipos da linguagem.
Por sinal, você sabe que Scala tem um sistema de tipos quase tão avançado quanto Haskell,
não só é mais por deficiencias da JVM.
Ronaldo Ferraz
2009/7/18 Guaracy Monteiro <guara...@gmail.com>:
> Acredito que a questão mercadológica também influencia na escolha
> da linguagem. É muito mais fácil conseguir um programador Java do
> que um para Lisp ou Smalltalk. Como a comunidade é menor (ou será
> que eu estou vendo os llocais errados?), tudo fica mais difícil. O Jecel
> estava falando no 10 FISL que está sendo complicando incluir o
> Squeak na Debian (quem conhece não se interessa e quem se interessa
> não conhece).
Com certeza. O mercado detém certas crenças e elas passam como
qualquer fad. Por anos, Java, C++ e seus equivalentes dominariam
simplesmente porque, para os powers that be, era a forma de provar que
alguém entendia pelo menos algo do que estava sendo feito. É a
repetição do argumento que "ninguém jamais foi demitido por usar
produtos IBM".
A comunidade Ruby era ridiculamente pequena até alguém provar que se
podia ganhar alguns milhões de dólares com um linguagem dinâmica no
dito "mundo real". O resto é história. Talvez Seaside faça o mesmo por
Smalltalk, talvez não. Mas eu gosto do caminho que se abriu. :)
> Recentemente vi o Doctest do Python. Achei bem legal a forma como foi
> concebido. Fiz uma versão rudimentar (apenas para prova de conceito)
> para Scheme em 25 linhas (e nem conheço bem a linguagem). Mas quem
> precisa de tanto teste se a linguagem permite que seja alterada mesmo
> com o programa sendo executado? Em Lisp ou Smalltalk, após o erro basta
> efetuar as correções e continuar de onde estava. :-)
Ah, eu adoro isso. Toda vez que eu mostro o debugger Smalltalk para
alguém, a pessoa fica de boca aberta.
E isso vai bem na linha do que eu penso mesmo. Eu estou co-liderando
uma equipe de 40 pessoas em um projeto relativamente complexo onde
trabalho. Minha preocupação primária é time-to-market. Provabilidade
está tão longe da minha mente quanto poderia estar. No momento,
qualquer coisa que permita que um desenvolvedor mantenha na sua cabeça
uma quantidade maior e mais compreensível de informações é que vai
satisfazer meus requisitos.
Abraços,
R.
Ronaldo Ferraz
Antes de responder, eu tenho que confessar que não consigo me furtar à
sensação de que estou respondendo todos os seus pontos mas o contrário
não é verdadeiro. Also, como o tom da thread está ficando um pouco
esquentado demais para o meu gosto--meu objetivo ao criar a lista era
justamente evitar flames--eu prefiro simplesmente dar alguns
argumentos e deixar o direito de resposta final para você. Talvez
consigamos conversar razoavelmente, talvez não. :)
2009/7/18 Rodrigo Kumpera <kum...@gmail.com>:
> SML é muito mais um projeto de pesquisa que uma linguagem que se encontra
> por ai. Apesar disso existem alguns projetos usando, curiosamente boa parte
> é na indústria aeroespacial.
>
> Porém se considerarmos linguagens da sua linhagem, F# e OCaml, você
> encontrará
> muitos e muitos sistemas na área financeira usando.
Exemplos concretos, por favor? Você me pediu um sistema de grande
porte em linguagens dinâmicas, eu citei alguns. Não consegui encontrar
diretamente informação sobre os exemplos acima.
> Alguém chegou a estudar o projeto?
Yep. Se você procurar pelo nome do projeto no Google e demais
mecanismos de busca, vai encontrar informação abundante sobre o mesmo.
> Sistemas grandes é diferente de um software grande. Perl foi muito usado
> pelo
> projeto genoma, mas se você olhar a complexidade do software escrito em
> perl,
> não é significativo.
A distinção me escapa, principalmente porque você é que colocou a
questão em termos de LoC.
O sistema que eu citei, Kapital, atende os critérios das duas formas:
é um sistema de grande porte tanto no sentido de ser volumoso em
termos de código quanto ser grande no sentido de escalabilidade por
rodar em centenas de CPU com milhões de transações sendo processadas
continuamente.
> Sim, MisraC, typo. Eu não disse que MisraC era um sistema de prova
> automática,
> mas me referia a toda pesquisa sobre verificação automática e autonomous
> reasoning
> sobre esse subset do C, incluindo varios produtos.
Color me confused, você mesmo disse sistemas de prova automática usando MisraC.
> O sistema de tipos do StrongTalk não é muito avançado, tanto que por isso
> ele é
> opcional e ignorado pela VM durante execução.
Mas esse é o ponto exato. Antes, porém uma distinção: o sistema de
tipos do StrongTalk é tão rico quanto o de qualquer linguagem com
tipagem estática. Já o sistema de anotação de tipos é fraco justamente
porque a decisão de ignorá-la é deliberada: a VM simplesmente não
precisa do mesmo para gerar código eficiente e adequado.
> Non sequitur. Por esse argumento não é possivel provar absolutamente nada
> sobre
> coisa alguma, oque não é verdade e tão pouco útil. Poder verificar tal
> propriedade
> para um software é incrivelmente útil, bug no SO ou hardware são ortogonais.
Continuo não entendendo. É fácil soltar um "non sequitur" sem
responder o argumento. Principalmente porque o ponto 3 responde
justamente a objeção acima.
> A diferença é gritante. Com uma linguagem dinâmica você não tem como
> codificar
> essas regras de forma a serem provadas de forma autônoma, em algumas
> linguagens
> com tipagens estáticas isso é possivel.
Evidências disso? Eu ainda estou esperando alguma concreta desde a
nossa primeira interação nessa thread?
> Como uma coisa pode influir na outra me falha à razão. Você pode estar
> falando da
> legibilidade do código, nesse ponto sim, flexibilidade sintática faz uma
> grande diferença.
> Porém tudo no final, no caso de Scala, será convertido para o sistema de
> tipos da linguagem.
É óbvio que influi porque, no final das contas, estamos falando de
seres humanos. Se o sistema semântico não é facilmente mapeável para o
domínio semântico do sistema sendo desenvolvido, alguma coisa está
faltando. Um dos grandes sucessos das linguagens dinâmicas é
justamente o fato de que elas permitem isso com mais facilidade. Vide
a aplicação que se fez disse em Seaside, por exemplo. Eu estou falando
de sistemas reais, em produção.
Não importa se no final há uma conversão para o sistema de tipos. Isso
é o equivalente a dizer que tudo no final vai ser convertido para
assembler ou microcode ou whatever. Esse é o ponto inteiro de
abstrações.
> Por sinal, você sabe que Scala tem um sistema de tipos quase tão avançado
> quanto Haskell,
> não só é mais por deficiencias da JVM.
Claro que sim. Deficiências são boas. É por isso que escala existe, e
tudo não ficou só no Java.
Abraços,
R.
Rodrigo Kumpera
2009/7/18 Rodrigo Kumpera <kum...@gmail.com>:
> SML é muito mais um projeto de pesquisa que uma linguagem que se encontraExemplos concretos, por favor? Você me pediu um sistema de grande
> por ai. Apesar disso existem alguns projetos usando, curiosamente boa parte
> é na indústria aeroespacial.
>
> Porém se considerarmos linguagens da sua linhagem, F# e OCaml, você
> encontrará
> muitos e muitos sistemas na área financeira usando.
porte em linguagens dinâmicas, eu citei alguns. Não consegui encontrar
diretamente informação sobre os exemplos acima.
Página de projetos usando ocaml: http://caml.inria.fr/about/successes.en.html
Porém, mais interessante é ler os proceedings da CUFP: http://cufp.galois.com/
A distinção me escapa, principalmente porque você é que colocou a
> Sistemas grandes é diferente de um software grande. Perl foi muito usado
> pelo
> projeto genoma, mas se você olhar a complexidade do software escrito em
> perl,
> não é significativo.
questão em termos de LoC.
LoC é apenas uma forma de medir o tamanho do software. Não é nada
exata ou científica, mas considerando apenas a ordens de grandeza tem
sua utilidade para comparar tamanhos.
O sistema que eu citei, Kapital, atende os critérios das duas formas:
é um sistema de grande porte tanto no sentido de ser volumoso em
termos de código quanto ser grande no sentido de escalabilidade por
rodar em centenas de CPU com milhões de transações sendo processadas
continuamente.
Sim, ele atende. Uma pena que smalltalk "morreu" no começo dos anos 90, senão
existiria uma boa base de projetos para comparar ele com.
Color me confused, você mesmo disse sistemas de prova automática usando MisraC.
> Sim, MisraC, typo. Eu não disse que MisraC era um sistema de prova
> automática,
> mas me referia a toda pesquisa sobre verificação automática e autonomous
> reasoning
> sobre esse subset do C, incluindo varios produtos.
Pois então, eles existem e já conseguem provar várias propriedades úteis de sistemas
escritos em MisraC. Não tem muita utilidade prática nisso porém, não existe muita
coisa útil que dá para se escrever dessa forma. O valor está em se notar que mesmo para
um linguagem tosca como C é possível produzir esse tipo de resultado e como isso vem
sendo lentando sendo transferido para outras linguagens.
Mas esse é o ponto exato. Antes, porém uma distinção: o sistema de
> O sistema de tipos do StrongTalk não é muito avançado, tanto que por isso
> ele é
> opcional e ignorado pela VM durante execução.
tipos do StrongTalk é tão rico quanto o de qualquer linguagem com
tipagem estática. Já o sistema de anotação de tipos é fraco justamente
porque a decisão de ignorá-la é deliberada: a VM simplesmente não
precisa do mesmo para gerar código eficiente e adequado.
A única coisa que eu li sobre o assunto foi um paper do Bracha e do Griswold sobre o
assunto e isso faz tempo. Se lembro bem, o ST usava tipagem estrutural e suporta
bounded parametric types, além de um esquema de tagging semelhante aos protocols
do ObjC.
Porém ST não suporta coisas como tipos dependentes, variancia paramétrica, classes
de tipos ou tipos de alta ordem/funtors. Coisas que linguagens naquela época (começo dos anos 90)
já suportavam.
Apesar de ser razoavelmente avançado, dificilmente podemos dizer que é tão rico quando o de
qualquer linguagem com tipagem estática.
> Non sequitur. Por esse argumento não é possivel provar absolutamente nada
> sobre
> coisa alguma, oque não é verdade e tão pouco útil. Poder verificar tal
> propriedade
> para um software é incrivelmente útil, bug no SO ou hardware são ortogonais.
Continuo não entendendo. É fácil soltar um "non sequitur" sem
responder o argumento. Principalmente porque o ponto 3 responde
justamente a objeção acima.
Vamos lá, primeiro o fato de possivelmente existirem bugs no hardware ou em outras
partes do sistema não é diretamente irrelevante. Ter a garantia que um software é livre
de deadlocks, por exemplo, é por si só uma enorme vantagem.
Quanto ao ponto (3), de que todas regras precisam ser conhecidas para se escrever uma
prova não é ponto algum. Você está implicando que isso é suficiente para garantir que
os programadores não irão introduzir tais bugs.
Uma boa forma de entender a útilidade de provas automáticas é olhar para o nosso dia a dia.
Quando eu encontro um bug no meu software, escrevo testes de regressão para
garantir que ele não voltará a acontecer. Porém, tais testes não provam que o software
está livre de bugs similares.
Se o teste em vez disso for codificado como um conjunto de regras as quais o software
deve seguir é possivel garantir que todas instancias similares não irão ocorrer.
Provas automáticas sob um programa é realidade em linguagens com tipagem estática
enquanto simplesmente não é possivel com as dinâmicas.
Evidências disso? Eu ainda estou esperando alguma concreta desde a
> A diferença é gritante. Com uma linguagem dinâmica você não tem como
> codificar
> essas regras de forma a serem provadas de forma autônoma, em algumas
> linguagens
> com tipagens estáticas isso é possivel.
nossa primeira interação nessa thread?
Que tal a ausência de softwares ou resultados científicos nesse sentido? Basta
olhar que enquanto existem um zilhão de ferramentas de refatoração para Java
e C# até hoje as melhores para linguagens dinâmicas funcionam tão bem quanto
a suite de testes que você tiver.
É óbvio que influi porque, no final das contas, estamos falando de
> Como uma coisa pode influir na outra me falha à razão. Você pode estar
> falando da
> legibilidade do código, nesse ponto sim, flexibilidade sintática faz uma
> grande diferença.
> Porém tudo no final, no caso de Scala, será convertido para o sistema de
> tipos da linguagem.
seres humanos. Se o sistema semântico não é facilmente mapeável para o
domínio semântico do sistema sendo desenvolvido, alguma coisa está
faltando. Um dos grandes sucessos das linguagens dinâmicas é
justamente o fato de que elas permitem isso com mais facilidade. Vide
a aplicação que se fez disse em Seaside, por exemplo. Eu estou falando
de sistemas reais, em produção.
Bom, isso eu não discuto. Entendo o valor em ter uma sintaxe mais próxima
do problema, mas eu me dou satisfeito com toneladas de parênteses.
Ronaldo Ferraz
http://www.pphsg.org/cdsmith/types.html
Boa discussão sobre o tópico e um texto que codifica várias das coisas
que eu acho interessantes/valiosas, especialmente quanto à verificação
formal e testes.
Abraços,
R.
2009/7/17 Ronaldo Ferraz <ronald...@gmail.com>:
Leonel Togniolli
Há várias asserções das quais depende o programa para analisar:
1) A implementação do OS sobre o qual o sistema está rodando também
foi verificada;
2) Não há bugs na implementação do hardware (que, em última instância
é uma transcrição física de software);
3) Todas as regras são conhecidas para a verificação.
Ronaldo Ferraz
2009/7/20 Leonel Togniolli <togn...@gmail.com>:
> Não se deve deixar a impossibilidade de analisar a completa ausência de
> erros em um programa nos impedir de usar ferramentas ou recursos que expõe
> determinadas categorias de erros.
Claro que não. E não creio ter dito isso; quando falei sobre
conhecimento das regras, estou falando do conhecimento completo
pertinente ao domínio específico (i. e, multi-tasking, etc).
> É claro que quanto mais cedo a presença de uma falha é exposta, mais barata
> é a correção.
Em termos. Como programador profissional, eu estou muitas vezes
disposto a voluntariamente assumir débitos técnicos para otimizar o
time-to-market.
Por outro lado, concordo, sim, que, se o interesse é eliminar
determinada categoria de bugs a priori, conhecer os bugs mais cedo é
mais barato.
> Se a tipagem pode ou não expor falhas mais cedo pode é
> discutível, mas acho que o valor de análises estáticas é mais fácil de
> argumentar. Afinal, seus testes são tão valiosos quanto a cobertura que eles
> oferecem.
E aí que eu discordo. Eu acho que erros de tipagem são pequenos face
ao tipo de problemas que uma cobertura de testes ajuda a pegar. Não
adianta nada eu saber que a função fatorial retorna um inteiro de
precisão arbitrária se eu coloquei um sinal de mais no lugar de um
sinal de menos.
Obviamente, tipagem é só uma parte do problema inteiro mas foi o que
acabamos dando foco na discussão.
> A questão passa a ser se constraints (não necessariamente tipagem, que acaba
> sendo um red herring na discussão) tornam a análise estática mais
> possível/poderosa. Também acho que é fácil ver que sim.
> Temos então, em um extremo, grandes restrições e alta "verificalidade"
> (existe um termo melhor?), e em outro, grande poder de expressão e menor
> verificalidade. Acho que existe lugar para linguagens nos dois lados do
> espectro, dependendo das suas necessidades.
Sim, sem dúvida. Nunca coloquei em discussão o ponto de que mais
opções são mais interessantes. Tanto é que uma das linguagens que
elogiei na thread, Scala, possui tipagem estática. Ironicamente, ela
acabou sendo criticada pelos mesmos motivos que eu acho interessantes.
Discussão por discussão, ficaríamos nisso para sempre.
> Sobre o artigo original, acho que está cheio de red herrings, também. É
> fácil argumentar contra constraints que são úteis mas podem ser mal usadas,
> cujo ponto negativo geralmente é "alguém malicioso poderia causar bugs
> extremamente difíceis de serem encontrados" (a possiblidade de
> adicionar/alterar métodos de classes da biblioteca padrão, por exemplo).
> Constraints que são um tradeoff de expressabilidade/verificalidade são
> mais difíceis de serem avaliados.
Sem dúvida, concordo também. Aliás, à sua resposta é exatamente para
onde eu queria encaminhar a discussão. Acabou indo para um lado
totalmente diferente, mas, enfim. :)
Abraços,
R.
Rodrigo Kumpera
E aí que eu discordo. Eu acho que erros de tipagem são pequenos face
> Se a tipagem pode ou não expor falhas mais cedo pode é
> discutível, mas acho que o valor de análises estáticas é mais fácil de
> argumentar. Afinal, seus testes são tão valiosos quanto a cobertura que eles
> oferecem.
ao tipo de problemas que uma cobertura de testes ajuda a pegar. Não
adianta nada eu saber que a função fatorial retorna um inteiro de
precisão arbitrária se eu coloquei um sinal de mais no lugar de um
sinal de menos.
São tipos de bugs diferentes. Tipagem forte garante que o programa não irá
assumir que um dado pedaço de memória é do tipo errado, esse tipo de erro
é razoavelmente difícil de se construir testes para.
Um sistema de tipos avançados consegue garantir que um programa é race-free,
outra característica incrivelmente difícil de se verificar com testes.
Um sistema de tipos não vai garantir que você usou as condições certas em uma
clausula where assim como outros tantos erros triviais de se verificar com testes.
Construir ou estender um sistema de tipos para isso seria no mínimo estranho.
Porém esse fato é apenas uma restrição das atuais ferramentas, já que que um teste
é isomórfico a um lemma de um sistema de tipos.
Ronaldo Ferraz
2009/7/20 Rodrigo Kumpera <kum...@gmail.com>:
>> E aí que eu discordo. Eu acho que erros de tipagem são pequenos face
>> ao tipo de problemas que uma cobertura de testes ajuda a pegar. Não
>> adianta nada eu saber que a função fatorial retorna um inteiro de
>> precisão arbitrária se eu coloquei um sinal de mais no lugar de um
>> sinal de menos.
>
> São tipos de bugs diferentes. Tipagem forte garante que o programa não irá
> assumir que um dado pedaço de memória é do tipo errado, esse tipo de erro
> é razoavelmente difícil de se construir testes para.
Das duas uma: ou eu me comunico extremamente mal, ou você está
deliberadamente ignorando o que eu estou dizendo. É óbvio que os tipos
de bugs são diferente. Isso até um não-programador que nem sabe o que
é uma variável entende. Eu simplesmente coloquei uma diferença de
valor para mim.
> Um sistema de tipos não vai garantir que você usou as condições certas em
> uma
> clausula where assim como outros tantos erros triviais de se verificar com
> testes.
É claro que não. Mas que dizer serem triviais é você. Do meu ponto de
vista, não adianta absolutamente nada saber se um sistemas qualquer é
race-free se as demais funções não-triviais do mesmo--que são
potencialmente indecidíveis e não podem ser provadas, seja com um
sistema de tipos, seja por verificação ou qualquer outra propriedade
similar--não estão apropriadamente testadas, seja qual for o
mecanismo.
Se a flexibilidade de um Smalltalk--mesmo com um sistema de tipos
inferior--me permite chegar mais rápido ao resultado, eu prefiro isso
a um OCaml que não pode me dizer se minha função fatorial computa
apropriadamente. Pelo menos no caso do Smalltalk ou Ruby, fatorial de
1.000.000 dá um resultado preciso em um tempo razoável.
http://img269.imageshack.us/img269/8119/ocamlfact.png
Kumpera, honestamente, suas contribuições são muito bem-vindas. Mas se
for para ficarmos na discussão pela discussão, sem evolução ou
benefício do argumento, eu devo confessar que não tenho paciência ou
tempo para isso. Já estou respondendo novamente a algo que não
gostaria e, quando criei a lista, foi justamente por ter horror a isto
em outros contextos. Podemos perfeitamente não concordas, mas se o
argumento ficar mudando a todo momento só para continuar uma discussão
pointless, não vai rolar.
Abraços,
R.