Entendendo o paradigma das linguagens dinamicas

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

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.

http://blog.fratech.net/

Grande Abraço,

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

Gostgaria apenas de informar que Scala não é uma linaguem dinâmica.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

cmoscoso wrote: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).

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

pcalcado wrote: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).

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,

feliperod wrote:
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

Provavelmente você não leu a última seção:

Contratos Nulos wrote:
Isso é Trabalhoso Demais!

Sim, eu sei. Infelizmente, Java não tem suporte nativo á design by contract, ao contrário de algumas outras linguagens (geralmente linguagens puramente OO). Existe o assert herdado do C, e existem abordagens em AOP, mas a linguagem por si só não tem esse recurso.

Uma linguagem com suporte à contratos vai te dar um modo fácil de definir e se referenciar a pré e pós-condições, invariantes e guardar valores antigos (o nosso antigoX e antigoY). Vai fazer um or automático com uma pré-condição e a pré-condição do método que você sobrescrever, e um and com a pós-condição. Ainda deveria gerar um documento como um JavaDoc com espaço reservado para a pré e pós-condições (que, afinal, são públicas). Também deve ter um mecanismo que permita ligar ou desligar as checagens, se quisermos mantê-las só para depuração.

Enquanto não vemos isso em java, nós temos que criar esses conceitos por nós mesmos. Isso geralmente implica num overhead enorme. de uma maneira geral:

* Se uma classe possui estados inválidos e estes são atingíveis, providencie uma invariante e faça a checagem dela.
* Se seus métodos realizam um processamento e retorne um valor, cheque este valor se no meio do caminho você precisou usar métodos não-confiáveis, como métodos de terceiros
* Sempre estabeleça e documente um contrato, mesmo que você não faça checagem.
* Se uma classe precisa de muitos objetos para não estar fora da invariante e você não quer passar estes objetos no construtor, use uma Factory.
* Tente utilizar o máximo possível de boas-práticas estabelecendo checagens, evite código duplicado ao máximo.
* Tenha testes unitários que testem todas as possibilidades que você consiga pensar de quebrar o contrato dos métodos.

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.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

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:

Como não existem pré-condições em Java nada impede que a classe filha defina um "contrato" completamente diferente do pai:

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.

feliperod wrote: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.

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.

Notícias, artigos e o maior fórum brasileiro sobre Java