Qual é a vantagem da inferência de tipo?

Parece que todas as novas linguagens de programação ou pelo menos as que se tornaram populares usam inferência de tipos. Até o Javascript obteve tipos e inferência de tipos através de várias implementações (Acscript, texto datilografado etc). Parece ótimo para mim, mas estou me perguntando se há algum trade-offs ou por que, digamos, Java ou as boas linguagens antigas não têm inferência de tipo

• Ao declarar uma variável em Go sem especificar seu tipo (usando var sem um tipo ou a sintaxe: =), o tipo da variável é deduzido do valor no lado direito.
• D permite escrever grandes fragmentos de código sem especificar tipos redundantes, como fazem as linguagens dinâmicas. Por outro lado, a inferência estática deduz tipos e outras propriedades de código, fornecendo o melhor dos mundos estático e dinâmico.
• O mecanismo de inferência de tipo no Rust é bastante inteligente. Ele faz mais do que olhar para o tipo de valor r durante uma inicialização. Também mostra como a variável é usada posteriormente para inferir seu tipo.
• O Swift usa a inferência de tipo para calcular o tipo apropriado. A inferência de tipo permite que um compilador deduza o tipo de uma expressão específica automaticamente quando compila seu código, simplesmente examinando os valores que você fornece.

O sistema de tipos de Haskell é totalmente inferível (deixando de lado a recursão polimórfica, certas extensões de linguagem e a temida restrição de monomorfismo ), mas os programadores ainda frequentemente fornecem anotações de tipo no código-fonte, mesmo quando não precisam. Por quê?

1. As anotações de tipo servem como documentação . Isto é especialmente verdade com tipos tão expressivos quanto os de Haskell. Dado o nome de uma função e seu tipo, geralmente você pode adivinhar o que a função faz, especialmente quando a função é parametricamente polimórfica.
2. As anotações de tipo podem impulsionar o desenvolvimento . Escrever uma assinatura de tipo antes de escrever o corpo de uma função é como um desenvolvimento orientado a teste. Na minha experiência, uma vez que você compila uma função Haskell, ela geralmente funciona na primeira vez. (Obviamente, isso não impede a necessidade de testes automatizados!)
3. Tipos explícitos podem ajudá-lo a verificar suas suposições . Quando estou tentando entender algum código que já funciona, frequentemente o uso com o que acredito serem as anotações de tipo corretas. Se o código ainda compilar, sei que o compreendi. Caso contrário, li a mensagem de erro.
4. As assinaturas de tipo permitem especializar funções polimórficas . Muito ocasionalmente, uma API é mais expressiva ou útil se determinadas funções não forem polimórficas. O compilador não irá reclamar se você der a uma função um tipo menos geral do que seria inferido. O exemplo clássico é map :: (a -> b) -> [a] -> [b]. Sua forma mais geral ( fmap :: Functor f => (a -> b) -> f a -> f b) se aplica a todos os Functors, não apenas às listas. Mas considerou-se que mapseria mais fácil de entender para iniciantes, por isso vive ao lado de seu irmão maior.

No geral, as desvantagens de um sistema estaticamente digitado, mas inferível, são as mesmas que as desvantagens da digitação estática em geral, uma discussão bastante desgastada neste site e em outras (Googling "desvantagens de digitação estática", você terá centenas de páginas de guerras de chamas). Obviamente, algumas dessas desvantagens são melhoradas pela menor quantidade de anotações de tipo em um sistema inferível. Além disso, a inferência de tipo tem suas próprias vantagens: o desenvolvimento acionado por orifício não seria possível sem a inferência de tipo.

O Java * prova que uma linguagem que exige muitas anotações de tipo fica irritante, mas com muito poucas você perde as vantagens que descrevi acima. Os idiomas com inferência do tipo opt-out atingem um equilíbrio agradável entre os dois extremos.

_{* Mesmo o Java, esse grande bode expiatório, realiza uma certa quantidade de inferência de tipo local . Em uma declaração como Map<String, Integer> = new HashMap<>();, você não precisa especificar o tipo genérico do construtor. Por outro lado, as linguagens no estilo ML são tipicamente globalmente inferíveis.}

Em C #, a inferência de tipo ocorre no tempo de compilação, portanto, o custo de tempo de execução é zero.

Por uma questão de estilo, varé usado para situações em que é inconveniente ou desnecessário especificar manualmente o tipo. Linq é uma dessas situações. Outro é:

var s = new SomeReallyLongTypeNameWith<Several, Type, Parameters>(andFormal, parameters);

sem o qual você repetiria seu nome de tipo realmente longo (e os parâmetros de tipo) em vez de simplesmente dizer var.

Use o nome real do tipo ao ser explícito para melhorar a clareza do código.

Existem algumas situações em que a inferência de tipo não pode ser usada, como declarações de variáveis ​​de membros cujos valores são definidos no momento da construção ou onde você realmente deseja que o intellisense funcione corretamente (o IDE de Hackerrank não fará o sentido de inteligência dos membros da variável, a menos que você declare o tipo explicitamente) .

Boa pergunta!

1. Como o tipo não é explicitamente anotado, às vezes pode dificultar a leitura do código - levando a mais erros. Corretamente usado que, obviamente, torna o código mais limpo e mais legível. Se você é pessimista e pensa que a maioria dos programadores é ruim (ou trabalha onde a maioria dos programadores é ruim), isso será uma perda líquida.
2. Embora o algoritmo de inferência de tipo seja relativamente simples, ele não é gratuito . Esse tipo de coisa aumenta um pouco o tempo de compilação.
3. Como o tipo não é explicitamente anotado, seu IDE também não consegue adivinhar o que você está tentando fazer, prejudicando o preenchimento automático e auxiliares similares durante o processo de declaração.
4. Combinado com sobrecargas de função, você pode ocasionalmente entrar em situações em que o algoritmo de inferência de tipo não pode decidir qual caminho seguir, levando a anotações mais feias do estilo de conversão. (Isso acontece bastante com a sintaxe da função anônima do C #, por exemplo).

E há mais linguagens esotéricas que não podem fazer suas estranhezas sem anotação explícita de tipo. Até agora, não há nenhum que eu saiba que seja comum / popular / promissor o suficiente para mencionar, exceto de passagem.

Parece ótimo para mim, mas estou me perguntando se há algum trade-offs ou por que, digamos, Java ou as boas linguagens antigas não têm inferência de tipo

O Java passa a ser a exceção e não a regra aqui. Até o C ++ (que eu acredito qualificar como uma "boa e antiga linguagem" :)) suporta inferência de tipo com a autopalavra - chave desde o padrão C ++ 11. Ele não funciona apenas com declaração de variável, mas também como tipo de retorno de função, o que é especialmente útil em algumas funções complexas de modelo.

Digitação implícita e inferência de tipo têm muitos casos de uso bons e também existem alguns casos de uso em que você realmente não deve fazê-lo. Às vezes, isso é questão de gosto e também assunto de debate.

Mas, sem dúvida, há casos de uso bons, é por si só uma razão legítima para qualquer linguagem implementá-lo. Também não é um recurso difícil de implementar, sem penalidade no tempo de execução e não afeta o tempo de compilação significativamente.

Não vejo uma desvantagem real em dar uma oportunidade ao desenvolvedor de usar inferência de tipo.

Algumas pessoas que responderam dizem que a digitação explícita é boa às vezes e certamente estão certas. Mas não oferecer suporte à digitação implícita significaria que um idioma impõe a digitação explícita o tempo todo.

Portanto, a verdadeira desvantagem é quando uma linguagem não suporta digitação implícita, porque com isso afirma que não há razão legítima para o desenvolvedor usá-la, o que não é verdade.

A principal distinção entre um sistema de inferência do tipo Hindley-Milner e inferência do tipo Go é a direção do fluxo de informações. No HM, as informações de tipo fluem para frente e para trás via unificação; no Go, as informações de tipo fluem apenas para frente: calcula apenas substituições para frente.

A inferência de tipo HM é uma inovação esplêndida que funciona bem com linguagens funcionais de tipo polimórfico, mas os autores de Go provavelmente argumentam que ela tenta fazer muito:

1. O fato de a informação fluir para frente e para trás significa que a inferência do tipo HM é um assunto muito não-local; na ausência de anotações de tipo, todas as linhas de código do seu programa podem estar contribuindo para a digitação de uma única linha de código. Se você tiver apenas substituição direta, você sabe que a fonte de um erro de tipo deve estar no código que precede seu erro; não o código que vem depois.

2. Com a inferência do tipo HM, você tende a pensar em restrições: ao usar um tipo, você restringe os possíveis tipos que ele pode ter. No final do dia, pode haver algumas variáveis ​​de tipo que são deixadas totalmente sem restrições. O insight da inferência de tipo HM é que, esses tipos realmente não importam e, portanto, são transformados em variáveis ​​polimórficas. No entanto, esse polimorfismo extra pode ser indesejável por várias razões. Primeiro, como algumas pessoas apontaram, esse polimorfismo extra pode ser indesejável: HM concluindo um tipo falso e polimórfico para algum código falso e levar a erros estranhos mais tarde. Segundo, quando um tipo é deixado polimórfico, isso pode ter consequências para o comportamento em tempo de execução. Por exemplo, um resultado intermediário excessivamente polimórfico é a razão pela qual 'mostra. read 'é considerado ambíguo em Haskell; como outro exemplo,

Dói a legibilidade.

Comparar

var stuff = someComplexFunction()

vs

List<BusinessObject> stuff = someComplexFunction()

É especialmente um problema ao ler fora de um IDE, como no github.