Das experiências controladas, apenas três mostram um efeito grande o suficiente para ter algum significado prático. O estudo de Prechelt comparando C, C ++, Java, Perl, Python, Rexx e Tcl; o estudo Endrikat comparando Java e Dart; e o experimento de Cooley com VHDL e Verilog. Infelizmente, todos eles têm problemas que dificultam a conclusão realmente forte.
No estudo de Prechelt, as populações eram diferentes entre linguagens dinâmicas e tipadas, e as condições para as tarefas também eram diferentes. Houve um estudo de acompanhamento que ilustrou a questão, convidando Lispers a apresentar suas próprias soluções para o problema, que envolvia comparar pessoas como Darius Bacon a graduandos aleatórios. Um acompanhamento para o acompanhamento envolve, literalmente, a comparação do código de Peter Norvig com o código de estudantes universitários aleatórios.
No estudo da Endrikat, eles escolheram especificamente uma tarefa em que achavam que a digitação estática faria diferença e selecionaram seus sujeitos de uma população em que todos haviam frequentado aulas usando a linguagem tipicamente estática. Eles não comentam se os alunos tiveram ou não experiência no idioma digitado dinamicamente, mas parece seguro assumir que a maioria ou todos tiveram menos experiência no idioma digitado dinamicamente.
O experimento de Cooley foi um dos poucos que atraiu pessoas de uma população não estudantil, o que é ótimo. Mas, como em todos os outros experimentos, a tarefa era uma tarefa trivial de brinquedo. Embora pareça lamentável que nenhum dos participantes do VHDL (linguagem estática) tenha conseguido concluir a tarefa a tempo, é extremamente incomum querer concluir um design de hardware em 1,5 horas em qualquer lugar fora de um projeto da escola. Você pode argumentar que uma tarefa grande pode ser dividida em muitas tarefas menores, mas um contra-argumento plausível é que existem custos fixos usando VHDL que podem ser amortizados em muitas tarefas.
Quanto ao restante dos experimentos, o principal argumento que tenho deles é que, sob o conjunto específico de circunstâncias descritas nos estudos, qualquer efeito, se é que existe, é pequeno.
Passando para os estudos de caso, os dois estudos de caso para encontrar bugs são uma leitura interessante, mas na verdade não são a favor ou contra tipos. Um mostra que a transcrição de programas Python para Haskell encontrará um número diferente de zero de erros de gravidade desconhecida que podem não ser encontrados através de testes de unidade orientados para a cobertura de linha. O par de artigos de Erlang mostra que você pode encontrar alguns erros que seriam difíceis de encontrar em qualquer tipo de teste, alguns dos quais são graves, usando análise estática.
Como usuário, acho conveniente quando meu compilador me dá um erro antes de executar ferramentas de análise estática separadas, mas isso é menor, talvez até menor que o tamanho do efeito dos estudos controlados listados acima.
Eu achei o estudo de caso do 0install (que comparou várias linguagens ao Python e eventualmente se baseou no Ocaml) como uma das coisas mais interessantes que encontrei, mas é o tipo de coisa subjetiva que todos interpretam de maneira diferente, que você pode ver olhando .
Isso se encaixa com a impressão que tenho (no meu cantinho do mundo, ACL2, Isabelle / HOL e PVS são os provadores mais usados, e faz sentido que as pessoas prefiram mais automação na solução de problemas na indústria), mas isso é também subjetivo.
E há os estudos que extraem dados de projetos existentes. Infelizmente, não consegui encontrar alguém que fizesse alguma coisa para determinar a causa (por exemplo, encontre uma variável instrumental apropriada), então eles apenas medem correlações. Algumas das correlações são inesperadas, mas não há informações suficientes para determinar o porquê.
O único estudo de mineração de dados que apresenta dados potencialmente interessantes sem exploração adicional é a revisão de Smallshire sobre os erros do Python, mas não há informações suficientes sobre a metodologia para descobrir o que seu estudo realmente significa, e não está claro por que ele sugeriu olhar para dados para outros idiomas sem apresentar os dados3.
Algumas omissões notáveis dos estudos são estudos abrangentes, com programadores experientes, e muito menos estudos com grandes populações de programadores “bons” ou “ruins”, observando qualquer coisa que se aproxime de um projeto significativo (em locais onde trabalhei, um projeto de três meses seria ser considerado pequeno, mas com várias ordens de magnitude maiores que qualquer projeto usado em um estudo controlado), usando linguagens estaticamente "modernas", usando tipografia gradual / opcional, usando IDEs convencionais modernos (como VS e Eclipse), usando IDEs radicais modernos (como LightTable), usando editores da velha escola (como Emacs e vim), fazendo manutenção em uma base de código não trivial, fazendo manutenção com qualquer coisa semelhante a um ambiente realista, fazendo manutenção em uma base de código que você já conhece, etc.
Se você olhar os comentários da Internet sobre esses estudos, a maioria deles é repassada para justificar um ponto de vista ou outro. O estudo de Prechelt sobre dinâmico versus estático, juntamente com os acompanhamentos no Lisp, são eternos favoritos dos defensores da linguagem dinâmica, e o estudo de mineração do github recentemente se tornou popular entre os programadores funcionais.