Nada de errado com tipagem estática

Tipagem estática quer dizer que todos os tipos estão determinados em tempo de compilação e que não mudam durante a execução do programa. Não deve haver problema nenhum com o fato do compilador verificar todos os tipos do seu programa antes de gerar um executável, certo? Isso pode até ser bom. Não há substituto para uma estrutura bem projetada e boa cobertura de testes, mas ter verificação de tipo durante a compilação pode mesmo evitar erros.

Como muita coisa, tipagem estática é uma faca de dois gumes e este é apenas um lado da moeda. O outro lado são as linguagens que exigem que o programador ajude o compilador a descobrir os tipos. Tudo para que eles possam dizer ao programador ‘Não, você não parece ter errado o tipo de nenhuma expressão’. Na presença de uma dessas linguagens, deveriam ser disparados alguns alarmes e deveria haver uma brigada de forças especiais dedicada especificamente a alertar os mais desavisados. Afinal de contas, as máquinas deveriam ajudar a nós e não nós a elas.

A realidade é que, se isso acontecesse, seria um mundo cheio de alarmes porque esse tipo de linguagem está em toda parte. Mas essa onipresença não faz com que ser forçado a escrever Integer no início de uma declaração como Integer x = 3 deixe de ser quase um insulto à inteligência. Se x é igual a três e três é um inteiro, é óbvio que x também é um inteiro. A declaração de tipo é só repetição. Repetição é uma coisa em que computadores são bons e pessoas são extremamente ruins. Pessoas ficam entediadas e querem desafios, computadores não precisam disso.

O nome que os pesquisadores arrumaram para esse tipo de repetição é inferência de tipos e deveria ser feita por toda linguagem e compilador sempre que possível. Mais: elas deveriam ser projetadas para que sempre fosse possível inferir tipos. Poupar a paciência dos programadores é sempre uma boa idéia e compiladores que precisam de tudo mastigado não fazem isso.

O raciocínio pode até ser estendido para expressões mais complexas. Aqui há uma definição de função em uma linguagem fictícia (que muito provavelmente é sintaxe válida em alguma linguagem real):

fac(n) {
    if (n == 0) return 1;
    else return n * (fac( n - 1));
}

Temos uma função fac que recebe um n, que por sua vez é usado em duas expressões dentro da definição da função. Na primeira, ele é comparado com zero e, na segunda, é subtraído de um. Portanto, n é algo que pode ser comparado e subtraído: um número. Isso faz da nossa função uma função sobre números. Mas, para falar um pouco de matematiquês, qual é o contra-domínio da função? Eu sei que devo passar um número para ela, mas o que vou receber em troca?

Essa é fácil, é só ver o que ela retorna. Temos duas expressões que retornam valores, a primeira retorna o valor um (um número). Isso faz de fac uma função de número para número, mas o tipo da segunda expressão de retorno precisa coincidir com o da primeira para que o código esteja consistente. Como n é um número que está sendo multiplicado por outro número (o fatorial do número anterior a ele), os tipos batem.

Estes dois exemplos são bem simples, mas inferir tipos realmente não é muito complicado. Podemos continuar aumentando a complexidade das expressões que ainda será possível inferir tipos. Tudo isto pode ser feito sem que o programador precise prover informação de tipos e em tempo de compilação. Por isso inferência de tipos é diferente de duck typing. Não quer dizer somente que o programador não precisa declarar os tipos, mas que além disso ele não vai precisar esperar até executar o programa para detectar os erros.

3 Responses to “Nada de errado com tipagem estática”


  1. 1 yguaratã 19/dez/2006 às 17\0546

    Depois que comecei a programar em Python conclui que realmente não preciso ficar declarando tipos. Porém, como trabalho com java, ainda preciso me submeter a esse tipo de coisa. Em Java não basta só especificar o tipo mas também fazer anotações do tipo “@SuppressWarnings(“unchecked”)”.
    Veja só que irônico: você precisa declarar os tipos para ajudar o compilador a prever seus erros, e logo depois é preciso dizer que não é para se preocupar com os tipos. rsrsrsrsr
    Apesar disso, Java é uma boa linguagem (milhares de pessoas não podem estar erradas), porém sem IDEs como Eclipse, Netbeans e etc, não dá para trabalhar com toda aquela gama de termos sintáticos.

  2. 2 Marcos Silva Pereira 09/jan/2007 às 03\0326

    E o que acontece quando se tem sobrecarga de operadores? Em Java, por exemplo, a = b + c tem resultados diferentes para tipos diferentes. Especialmente, vc pode mesclar tipos em expressão dessa natureza e obter resultados diferentes o que tornaria a inferência de tipos um pouco mais complicada, não impossível, mas mais complicada. Quando a linguagem permitir sobrecarga de operadores, pode ser mais complicado ainda realizar a inferência e aí duck typing começa a fazer sentido.

    valeuz…

  3. 3 Thiago Arrais 09/jan/2007 às 12\1203

    Na definição do fatorial temos um exemplo disso. Veja que
    defini o parâmetro n como um número (devido à utilização
    interna da função de subtração). Não foi como um int,
    float, ou Byte. Mesmo assim a função deverá funcionar
    corretamente para qualquer um desses tipos.

    Em Haskell isso é resolvido com classes de tipos, que são grosseiramente uma interface Java turbinada. O ‘operador’
    de adição nada mais é que uma função que opera sobre dois
    argumentos (e que é normalmente utilizado na forma
    infixa). Os dois argumentos são objetos Summable. Isto não
    existe em Java, mas meio que existe em Haskell na forma da
    classe de tipos Num (que não abrange somente a adição).
    Olha o que o verificador de tipo me diz:

    Prelude> :t (+)
    (+) :: (Num a) => a -> a -> a

    Traduzindo: a soma é uma operação sobre dois números do
    mesmo tipo que resulta em um terceiro número do mesmo tipo.
    E “número” pode ser muitas coisas diferentes. Esta mesma
    função pode ser disponibilizada para números inteiros, de
    ponto flutuante, números complexos e matrizes. Mesmo assim
    o compilador consegue inferir os tipos.

    Isto não é por acaso, é porque Haskell é uma dessas
    linguagens feitas desde o início com inferência de tipos
    em mente.


Comments are currently closed.




%d blogueiros gostam disto: