Com tipagem estática suficientemente avançada, quais são as vantagens dos sistemas de tipo dinâmico? [fechadas]

5

Esta questão parece estar bem equilibrada, por exemplo:

No entanto, a maioria das perguntas e respostas parece comparar as linguagens tipificadas estatisticamente, como Java e C ++, com linguagens dinamicamente tipificadas, como Python e JavaScript. Esta parece ser uma comparação diferente - Java e C ++ são verbosos, não interativos e geralmente difíceis de se trabalhar por razões fora de seus sistemas de tipos.

Estou mais interessado em usar linguagens estáticas, como Swift ou Haskell, como base da comparação.

  • Esses idiomas têm REPLs, codificação interativa ou equivalentes
  • Esses idiomas têm inferência de tipos (assim como o C ++)
  • Esses idiomas têm "genéricos" fáceis de usar
  • Essas linguagens têm ADTs, o que resolve problemas como a análise JSON

Podemos imaginar uma variante do Swift com uma forma de Digitação estrutural , onde:

func foo(bar) { return bar.baz() }

É uma sintaxe válida para qualquer chamada na qual um objeto com um membro baz() é passado e o tipo de retorno é o do baz() do objeto - criando efetivamente um protocol Foo<T> anônimo com membro func baz() -> T .

Isso pode ser traduzido para JavaScript por s/func/function/g , mas todo o tipo de segurança seria perdido.

Qual é a vantagem da digitação dinâmica, comparando uma linguagem tipada estática com um bom sistema de tipos?

    
por charl 05.06.2015 / 17:59
fonte

1 resposta

3

Fundamentalmente, se o sistema de tipos estiver lá, o programador tem que lidar com isso. Ele pode ser bastante "flexível" (ou seja, fica fora do seu caminho em situações em que o sistema de tipos como o Java seria uma dor) e implícito (portanto, as anotações de tipo podem ser omitidas quando não agregam valor), mas o programador tem que lidar com isso. Mesmo que todo programa prático e correto não precise de nenhuma anotação de tipo e "simplesmente funcione" (IMHO), os programadores escrevem programas errados - pegar esses erros é o objetivo de um sistema de tipos, afinal.

Apresentado com um erro de tipo, o programador precisa entender o sistema de tipos para entender o erro. Em geral, os sistemas de tipos que permitem mais implícita e são mais flexíveis (no sentido acima mencionado) são mais complexos e difíceis de entender. É claro que, para um determinado grau de implícita e flexibilidade, um bom design e boas mensagens de erro podem fazer a diferença, mas há um limite. Isso não quer dizer que isso seja um mau negócio, mas é um compromisso.

Na prática, os sistemas de tipos que você nomeia não cumprem a condição acima de programas corretos "apenas funcionando". Você pode argumentar que eles impõem um estilo de programação melhor, e eu concordo, mas eles rejeitam programas válidos do estilo que as pessoas realmente escrevem. Isso causa atrito. Há muitos upsides, é claro, mas você parece sugerir que se pode simplesmente parar de escrever JavaScript e obter todas as garantias de correção de graça. Isso não é verdade, é preciso entender o sistema de tipos e se acostumar com os programas de fraseado de uma maneira que o sistema de tipos entenda. Por exemplo, em Haskell você não pode ter apenas subtipagem e herança. Este é um trade-off que compra certas vantagens a Haskell, e é uma escola de design perfeitamente válida, mas também dificulta a implementação de projetos diferentes.

    
por 05.06.2015 / 18:37
fonte