Estudos de idiomas dinamicamente x estaticamente tipados [fechado]

69

Existem estudos feitos sobre a eficácia de linguagens estaticamente versus dinâmicas?

Em particular:

  • Medições da produtividade do programador
  • Taxa de defeito

Incluindo também os efeitos de se ou não o teste de unidade é empregado.

Eu já vi muita discussão sobre os méritos de ambos os lados, mas estou me perguntando se alguém fez um estudo sobre isso.

productivity comparison type-systems dynamic-typing static-typing Winston Ewert
fonte
8
@bigown, não me parece que as questões de produtividade e defeitos relacionar com a teoria de ciência da computação
Winston Ewert
2
@Winston: Estudar esse tipo de problema é trabalho dos cientistas da computação, não dos programadores.
Maniero
9
@ Bigown, sim, é uma questão de ciência da computação, mas não é uma questão de teoria da ciência da computação. A teoria do CS lida essencialmente com o que podemos provar matematicamente sobre programas e computação. Questões de produtividade do programador não são questões da teoria cs. Houve discussões sobre digitação dinâmica aqui e no stackoverflow. Não houve nenhuma história.
Winston Ewert
8
A pergunta está perfeitamente no tópico. Esta pergunta discute uma das propriedades mais importantes das ferramentas que usamos para programar.
Frank Shearar
4
@Winston: Os sistemas de digitação pertencem à teoria da CS, mas os estudos práticos não.
David Thornley

Respostas:

42

Algumas sugestões de leitura:

Não exatamente na digitação estática, mas relacionada:

Alguns artigos ou ensaios interessantes sobre o assunto ou sobre a análise estática de programas em geral:

E para aqueles que se perguntariam do que se trata:

No entanto, duvido que qualquer uma dessas respostas lhe dê uma resposta direta, pois elas não fazem exatamente o estudo que você está procurando. Eles serão leituras interessantes embora.

Pessoalmente, Considero firmemente que a digitação estática sobre a digitação dinâmica facilita a detecção de erros. Eu gasto muito tipo procurando erros de digitação e pequenos erros como esses em JavaScript ou mesmo código Ruby. E quando se trata de entender que a Digitação dinâmica oferece um aumento na produtividade, acho que isso se resume principalmente às ferramentas. Se linguagens de tipo estaticamente tiverem as ferramentas certas para permitir a recompilação em segundo plano e fornecer uma interface REPL, você obterá os benefícios dos dois mundos. O Scala fornece isso, por exemplo, o que facilita muito a aprendizagem e o protótipo no console interativo, mas oferece os benefícios da digitação estática (e de um sistema de tipos mais forte do que muitos outros idiomas, exceto os idiomas ML). Da mesma forma, acho que não tenho perda de produtividade usando Java ou C ++ (por causa da digitação estática), desde que eu use um IDE que me ajude. Quando eu reverto para a codificação apenas com configurações simples (editor + compilador / intérprete), parece que linguagens mais complexas e dinâmicas parecem mais fáceis de usar. Mas você ainda procura por bugs. Eu acho que as pessoas diriam que a questão das ferramentas é um argumento reversível, como se as ferramentas fossem melhores para linguagens dinâmicas, então a maioria dos erros e erros de digitação seriam apontados no tempo de codificação, mas isso reflete a falha no sistema na minha opinião. Ainda assim, eu normalmente protótipo no JRuby e codificarei em Java mais tarde na maioria das coisas que faço. como se as ferramentas fossem melhores para linguagens dinâmicas, a maioria dos erros e erros de digitação seriam apontados no tempo de codificação, mas isso reflete a falha no sistema na minha opinião. Ainda assim, eu normalmente protótipo no JRuby e codificarei em Java mais tarde na maioria das coisas que faço. como se as ferramentas fossem melhores para linguagens dinâmicas, a maioria dos erros e erros de digitação seriam apontados no tempo de codificação, mas isso reflete a falha no sistema na minha opinião. Ainda assim, eu normalmente protótipo no JRuby e codificarei em Java mais tarde na maioria das coisas que faço.

AVISO: Alguns desses links não são confiáveis ​​e alguns passam por portais de várias sociedades de computação usando acessos com taxas para os membros. Desculpe por isso, tentei encontrar vários links para cada um deles, mas não é tão bom quanto gostaria.

haylem
fonte
Essa descoberta de bug - é principalmente por causa de nomes de variáveis ​​com erros de ortografia, ou nomes de métodos, ou em algum lugar no meio? ( Detesto a declaração implícita de variável exatamente por esse motivo: no Smalltalk, você declara todas as suas variáveis ​​no topo, para saber imediatamente quando digitou incorretamente o nome de uma variável. (Às vezes, erros de digitação do nome do método também são detectados, se o nome do método nunca for (foi usado na imagem antes.))
Frank Shearar 16/10/10
Para reutilizar as ferramentas, devo dizer que isso depende do seu idioma - o Smalltalk possui excelentes ferramentas, incluindo um navegador de refatoração que o Eclipse possui (disseram-me) ainda a alcançar.
Frank Shearar
@ Frank Shearar, desde que comecei com Ruby (vindo de Java), percebi que o que o @ haylem está dizendo provavelmente não se aplica ao Smalltalk. Meu mantra também sobre a refatoração automática não é impossível em linguagens dinamicamente tipadas. Concordo plenamente com a seção "pessoalmente" de haylem .... ignorando o SmallTalk, é claro :) Isso é justo, até certo ponto, já que o SmallTalk, embora não esteja morto, definitivamente não está desfrutando da popularidade que o Python ou o Ruby têm (agora em outubro de 2010 )
Dan Rosenstark 16/10/10
3
@haylem, pessoalmente, obrigado por me fazer sentir que não sou a única pessoa no mundo que trabalha em linguagens dinâmicas, mas, quando é dada uma escolha, muitas vezes ESCOLHA linguagens de tipo estatístico (no mesmo caso, Java vs. JRuby ou Groovy).
Dan Rosenstark 16/10/10
4
É interessante porque minha própria preferência pela digitação dinâmica é por razões bastante diferentes. Quero dizer, compilações rápidas e intérpretes interativos são úteis, mas não são por isso que gosto de digitação dinâmica. Eu gosto da digitação dinâmica porque encontro muitas situações nas quais as linguagens estáticas de digitação dificultam a descrição de um conceito em particular.
Winston Ewert
19

Ainda ontem encontrei este estudo: o teste de unidade não é suficiente. Você precisa de digitação estática também.

Basicamente, o autor usou uma ferramenta capaz de converter automaticamente um projeto de uma linguagem de digitação não estática em uma linguagem de digitação estática (python para haskell)

Em seguida, ele selecionou vários projetos Python de código aberto que também incluíam uma quantidade razoável de unidades de teste e os converteu automaticamente em haskell.

A tradução para Haskell revelou uma série de erros relacionados ao tipo das variáveis: os erros não foram descobertos pelas unidades de teste.

PBrando
fonte
4
Verdade desconfortável da digitação dinâmica.
Den
6
"A tradução para Haskell revelou uma série de erros relacionados ao tipo de variáveis: os erros não foram descobertos pelas unidades de teste.": Com uma linguagem de tipo dinâmico, você deve testar manualmente as propriedades do seu código que, estaticamente, idioma de tipo são verificados automaticamente pelo compilador. Isso é mais demorado e propenso a erros. +1
Giorgio
4
Eu respondi a uma postagem neste link no Reddit. Não acho que as conclusões tiradas do artigo sejam razoáveis.
Veedrac
Ambos os sistemas de digitação têm vantagens / desvantagens e seus usos. É como discutir sobre levar uma metralhadora para uma luta corpo a corpo. Essa é uma guerra religiosa longe do fim. Dito isto, eu concordo com Veedrac. Linguagens não estáticas precisam de mais casos de teste para detectar erros causados ​​por tipos. Essa é a sua natureza e con. Porém, um programador precisa escrever um teste que identifique um erro no código causado por um estado inesperado de entrada, não necessariamente um teste exaustivo para o tipo de entrada.
Andre Figueiredo
10
  • Link para discussão do artigo da ACM " Uma experiência sobre sistemas de tipo estático e dinâmico " (2010) pelo artigo de Stephan Hanenberg (referenciado por Lorin Hochstein em um post anterior).
  • Conclusão: A produtividade para qualidade semelhante foi maior em linguagem dinâmica.
  • Possíveis vieses / questões de validade: os sujeitos experimentais foram todos estudantes. Além disso, variedade limitada de tarefas de programação (os indivíduos foram solicitados a implementar um scanner e analisador).
  • Artigo da ACM " As linguagens de programação afetam a produtividade? " (2007) de Delorey, Knudson e Chun.
  • Conclusão: JavaScript, Tcl, Perl mais produtivo que C # C ++ e Java. Python e PHP ficam no meio.
  • Possíveis enviesamentos / problemas de validade: Nenhuma medida de qualidade (como erros descobertos após o lançamento). Nenhuma medida de confiabilidade (o software escrito em linguagens estaticamente tipificadas é mais confiável?). Viés de amostra - todos os projetos foram abertos em repositórios CVS de código aberto. Além disso, não há distinção entre linguagens fracamente e fortemente tipadas (ou seja, ponteiros).
  • Tese " Estudo empírico de produtividade e qualidade de software " (2008) por Michael F. Siok
  • Conclusão: A escolha da linguagem de programação não influencia significativamente a produtividade ou a qualidade. No entanto, isso afeta os custos de mão-de-obra e a "qualidade no portfólio geral de projetos de software".
  • Potenciais viéses / problemas de validade: Restrito ao domínio aviônico. Todas as linguagens de programação podem ter sido digitadas estaticamente. Como não li a tese, não posso avaliar seu rigor.
    Minha opinião. Embora haja pouca evidência de que as linguagens dinamicamente digitadas sejam mais produtivas, isso não é conclusivo. (1) Existem muitos fatores que não foram controlados; (2) existem poucos estudos; (3) houve pouca ou nenhuma discussão sobre o que constitui um método de teste apropriado.
ahoffer
fonte
6

Aqui está um ponto de partida:

O artigo está desafiando a sabedoria comum de que, sendo todos os demais iguais, os programadores escrevem o mesmo número de linhas de código por tempo, independentemente da linguagem. Em outras palavras, o artigo deve servir como evidência empírica de apoio de que a produtividade mecânica (linhas de código escritas) não é uma boa medida da produtividade funcional e deve, pelo menos, ser normalizada pela linguagem.

Piet Delport
fonte
5
Para as pessoas que não são do IEEE, qual é o resumo básico?
Frank Shearar
11
@ Frank Shearar, a conclusão que eles tiram é que a linguagem de programação afeta a produtividade. Eles estão medindo linhas de código por programador por idioma por ano, não tenho certeza de que seja uma boa medida de produtividade.
Winston Ewert
3
@Winston: Essa é definitivamente uma métrica imperfeita. Você consideraria o COBOL uma linguagem muito produtiva: são necessárias muitas linhas para fazer qualquer coisa útil, mas são fáceis de escrever.
precisa
Winston, David: Tenho certeza de que os autores não estão sugerindo que a produtividade das linhas de código seja uma medida da produtividade funcional . Em vez disso, o artigo está desafiando a sabedoria comum de que, sendo todos os demais iguais, os programadores escrevem o mesmo número de linhas de código por tempo, independentemente da linguagem. Em outras palavras, o artigo deve servir como evidência empírica de apoio de que a produtividade mecânica (linhas de código escritas) não é uma boa medida da produtividade funcional e deve, pelo menos, ser normalizada pela linguagem.
Delport Pi
Eu concordo com isso. Mas não serve para responder à minha pergunta original.
Winston Ewert
1

Eu encontrei uma linguagem estática versus dinâmica: uma revisão de literatura , que lista alguns estudos sobre o assunto e fornece um bom resumo de cada estudo.

Aqui está o resumo executivo:

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.

Mr.WorshipMe
fonte
0

Sinceramente, não acho que a digitação estática vs dinâmica seja a verdadeira questão.

Eu acho que existem dois parâmetros que devem vir primeiro:

  • o nível de conhecimento no idioma: quanto mais experiente você for, mais saberá sobre as "dicas" e maior será a probabilidade de evitá-las / rastreá-las facilmente. Isso também se aplica ao aplicativo / programa específico em que você está trabalhando
  • testing: Adoro digitar estática (diabos, eu gosto de programar em C ++: p), mas há tanto que um compilador / analisador estático pode fazer por você. É impossível confiar em um programa sem testá-lo. E sou a favor de testes difusos (quando aplicável), porque você simplesmente não consegue pensar em todas as combinações de entradas possíveis.

Se você se sentir confortável no idioma, escreverá código e rastreará os erros com facilidade.

Se você escrever código dissociado e testar cada funcionalidade extensivamente, produzirá um código bem aprimorado e, portanto, será produtivo (porque não pode ser qualificado como produtivo se não avaliar a qualidade do produto, pode? )

Eu consideraria, portanto, que o debate estático versus dinâmico em relação à produtividade é bastante discutível, ou pelo menos amplamente substituído por outras considerações.

Matthieu M.
fonte
2
Se essa é uma contra-pergunta, onde está a pergunta? :) Concordo que outros fatores são mais importantes que a digitação estática vs dinâmica. No entanto, advogados de digitação dinâmica reivindicam melhor produtividade e advogados de digitação estática reivindicam melhor qualidade de código. Fiquei me perguntando se alguém tinha evidências reais para apoiar suas reivindicações.
Winston Ewert
@ Winston: removi o bit do contador: p Como você mencionou, são principalmente reivindicações. Eu acho que a maioria dos defensores da digitação dinâmica está misturando facilidade de uso com digitação dinâmica, enquanto a facilidade de uso é principalmente sobre ferramentas. Concordo que a possibilidade de escrever protótipos de descarte rápidos e experimentar comandos curtos usando um intérprete é um aumento de produtividade, mas mesmo Haskell (talvez a linguagem com o sistema de tipos mais impressionante do momento) tem um intérprete para experimentação rápida: )
Matthieu M.
Mas até que alguém realmente faça um estudo que considere essa questão - se a metodologia, as ferramentas têm um impacto maior que a linguagem nas taxas de defeitos, na produtividade -, acabamos comparando as anedotas.
Frank Shearar
0

Aqui estão alguns:

  • Stefan Hanenberg. 2010. Um experimento sobre sistemas do tipo estático e dinâmico: dúvidas sobre o impacto positivo dos sistemas do tipo estático no tempo de desenvolvimento. Em Anais da conferência internacional ACM sobre linguagens e aplicativos de sistemas de programação orientada a objetos (OOPSLA '10). ACM, Nova York, NY, EUA, 22-35. DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Daniel P. Delorey, Charles D. Knutson, Scott Chun, "As linguagens de programação afetam a produtividade? Um estudo de caso usando dados de projetos de código aberto", floss, pp.8, Primeiro Workshop Internacional sobre Tendências Emergentes na Pesquisa e Desenvolvimento do FLOSS (FLOSS '07: Workshops ICSE 2007), 2007

  • Daly, M .; Sazawal, V., Foster, J .: Trabalho em Progresso: um Estudo Empírico de Digitação Estática em Ruby, Workshop sobre Avaliação e Usabilidade de Linguagens e Ferramentas de Programação (PLATEAU) no ON-WARD 2009.

  • Lutz Prechelt e Walter F. Tichy. 1998. Uma experiência controlada para avaliar os benefícios da verificação de tipo de argumento de procedimento. IEEE Trans. Softw. Eng. 24, 4 (abril de 1998), 302-312. DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186

Lorin Hochstein
fonte