Fala aí pessoal,
Seguinte, acabei de colocar no ar um post interessante sobre linguagens dinâmicas. É o primeiro de uma série, pois o artigo começou a ficar muito grande, mas acho que vale a leitura.
Grande Abraço,
Gostgaria apenas de informar que Scala não é uma linaguem dinâmica.
Depois que você falou isso fui buscar na documentação e realmente, encontrei esse documento que diz que Scala tem tipagem estática.
Mas como não conheço a fundo a linguagem apenas imaginei que o fato de não declarar alguns tipos de variáveis e significava que era uma linguagem Dinamica. Pelo jeito errei mesmo. Valeu pelo comentário. Vou editar o post no blog agora mesmo. =)
Grande Abraço,
Uma linguagem dinâmica não precisa ter metaprogramação e nem Java é um bom exemplo de linguagem estática neste ponto. Scala, Haskell e F# fazem coisas incríveis e são estáticas, por exemplo.
Também não entendi a relação que você fez entre tipagem estática e contratos, são coisas bem diferentes. Nada impede que você use DBC em uma linguagem dinamica e nada garante que você use DBC em uma linguagem estática -Java, por exemplo, não possui DBC. A única linguagem com DBC de verdade que eu conheço é Eiffel. Em uma linguagem din6amica você ainda pode ter pré e pós condições verificadas, você so precisa do contrato e este não precisa ser um tipo.
A diferença entre tipagem din6amica ou estática está no compilador saber que tipos esperar em um lugar. Todo o resto citado são capacidade da linguagem em questão, não estão relacionadas à forma de tipagem (eu não chamaria de paradigma).
[quote=pcalcado]Uma linguagem dinâmica não precisa ter metaprogramação e nem Java é um bom exemplo de linguagem estática neste ponto. Scala, Haskell e F# fazem coisas incríveis e são estáticas, por exemplo.
Também não entendi a relação que você fez entre tipagem estática e contratos, são coisas bem diferentes. Nada impede que você use DBC em uma linguagem dinamica e nada garante que você use DBC em uma linguagem estática -Java, por exemplo, não possui DBC. A única linguagem com DBC de verdade que eu conheço é Eiffel. Em uma linguagem din6amica você ainda pode ter pré e pós condições verificadas, você so precisa do contrato e este não precisa ser um tipo.
A diferença entre tipagem din6amica ou estática está no compilador saber que tipos esperar em um lugar. Todo o resto citado são capacidade da linguagem em questão, não estão relacionadas à forma de tipagem (eu não chamaria de paradigma).[/quote]
Ué… não existe Design By Contract com Java? Não entendi esse link aqui então http://www.fragmental.com.br/wiki/index.php/Contratos_Nulos
Aliás, muito bom esse post sobre NullPointerException e DBC =).
Grande Abraço,
Provavelmente você não leu a última seção:
Resumindo: java não tem suporte DBC, você pode usar tecnicas de DBC.
É como aspectos ou ORM, Java não tem suporte à eles mas você pode usar suas técnicas. E isso nõ tem a ver com tipagem, não é difícil fazer a mesma coisa em Ruby.
No final das contas o ponto é que tipagem estática ou dinâmica por si só não importa tanto para o programador. O gap enorme entre ambas que vemos é porque comparamos linguagens com tipageme stática meia-boca (Java) com tipagem dinâmica, faça o mesmo com Haskell ou Scala e você vai ver bem menos diferenças.
Na verdade a relação de tipagem Dinâmica é muito mais com o Design By Capability. Isso sim é muito mais difícil de ser alcançado com Tipagem Estática. Pelo menos não é possível Design By Capability se o compilador verifica o tipo antes de compilar.
O importante é que em Java, quando se define uma interface para obrigar alguns metodos a seguirem um contrato de quais são os parâmetros a serem passados e qual é o tipo de retorno da operação chamada. Quando menciono Design By Contract estou puramente mencionando (no caso de Java) que a Interface define as pré-condições e o retorno, o a implementação do método deve obedecer essas especificações. Quando o compilador verifica se uma determinada chamada condiz com a interface, ele está verificando se aquela chamada atende ao contrato definido na Interface, caso contrário interrompe o processo.
Quanto à relação entre a Tipagem Dinâmica, como no caso de Groovy, o compilador não verifica se o objeto possui um contrato e muito menos se ele atende à esse contrato. Essa verificação ó ocorre em tempo de execução, no momento da chamada do método, o que caracteriza Design By Capability.
Tudo bem, podemos então dizer que Java não oferece suporte completo para o Design By Contract no detalhe máximo do conceito, mas daí a dizer que Java não possui DbC acho no mínimo radicalismo.
Grande Abraço,
Uma interface não possui pré-condições, de maneira alguma. Ela define apenas assinaturas de métodos.
Não existem contratos na linguagem Java. Não é porque eu sei que o objeto X tem uma método chamado X que recebeY e Z que ele tem um contrato. Contratos só existem e existirem pré e pós condições e Java não possui estes conceitos.
Um dos modos fáeis deverificar isso é criar uma classe como essa:
class Pai{
public void fazAlgo(int arg){
//checagem de pre condicao, arg tem que ser entre 1 e 5
if (arg <1 || arg > 5) throw RuntimeException("contrato quebrado");
//contina loica
}
}Como não existem pré-condições em Java nada impede que a classe filha defina um "contrato" completamente diferente do pai:
class Filho{
public void fazAlgo(int arg){
//checagem de pre condicao, arg TEM QUE SER 2
if (arg != 3) throw RuntimeException("contrato quebrado");
//contina logica
}
}Isso não 'feito em DBC, onde contratos são herdados.
Como falei antes você pode -e deve- usar técnicas de DBC em java, bem como ode usar técnicas de programação funcional e etc., mas você não tem DBC em Java.
[quote=feliperod]Na verdade a relação de tipagem Dinâmica é muito mais com o Design By Capability. Isso sim é muito mais difícil de ser alcançado com Tipagem Estática. Pelo menos não é possível Design By Capability se o compilador verifica o tipo antes de compilar.
[/quote]
Sim mas até hoje eu não cnsegui pensar em muitos casos práticos (de dia-a-dia) onde inferência de tipos não suprisse estas necessidades.