Estudios de idiomas dinámicamente vs estáticamente escritos [cerrado]

¿Existen estudios realizados sobre la efectividad de los idiomas tipados estáticamente vs dinámicamente?

En particular:

• Mediciones de productividad del programador.
• Tasa de defectos

También se incluyen los efectos de si se emplean o no pruebas unitarias.

He visto mucha discusión sobre los méritos de ambos lados, pero me pregunto si alguien ha hecho un estudio al respecto.

Algunas lecturas sugeridas:

• Los desarrolladores cambian a lenguajes dinámicos ( PDF )
• Sobre el renacimiento de los lenguajes dinámicos ( PDF )
• Escritura estática siempre que sea posible, escritura dinámica cuando sea necesario: el fin de la guerra fría entre lenguajes de programación ( PDF )
• La seguridad de la escritura estática con enlaces dinámicos ( PDF )
• Combinando el razonamiento estático y dinámico para la detección de errores ( PDF )
• Escritura dinámica en un lenguaje de escritura estática ( PDF )
• Convertir la escritura dinámica en escritura estática por especialización de programa ( PDF )
• Verificación de tipo híbrido ( PDF )

No exactamente sobre la escritura estática, pero relacionado:

• Asegurar el código de la aplicación web mediante análisis estático y protección de tiempo de ejecución ( PDF )

Algunos artículos o ensayos interesantes sobre el tema o sobre análisis estático de programas en general:

• Sistemas de tipo enchufable ( PDF )
• Tipeo fuerte versus pruebas fuertes
• Linux Kernel Developer Responses to Static Analysis Bug Reports ( PDF )
• ¿Es débil escribir lo suficientemente fuerte?
• Explotación de correlación en la clasificación de errores
• Mejora de la calidad del software con análisis estático

Y para aquellos que se estarían preguntando de qué se trata todo esto:

• Introducción a la escritura estática y dinámica

Sin embargo, dudo que alguno de estos le dé una respuesta directa, ya que no hacen exactamente el estudio que está buscando. Sin embargo, serán lecturas interesantes.

Personalmente, Considero firmemente que la escritura estática sobre la escritura dinámica facilita la detección de errores. Paso demasiado tiempo buscando errores tipográficos y errores menores como estos en JavaScript o incluso en el código Ruby. Y cuando se trata de la opinión de que Dynamic Typing le da un impulso en la productividad, creo que todo se reduce a herramientas. Si los idiomas escritos estáticamente tienen las herramientas adecuadas para permitir la compilación en segundo plano y proporcionar una interfaz REPL, entonces obtendrá los beneficios de ambos mundos. Scala proporciona esto, por ejemplo, lo que hace que sea muy fácil de aprender y crear prototipos en la consola interactiva, pero le brinda los beneficios de la escritura estática (y de un sistema de tipos más fuerte que muchos otros idiomas, aparte de los idiomas ML). Del mismo modo, no creo que tenga una pérdida de productividad al usar Java o C ++ (debido a la escritura estática), siempre y cuando use un IDE que me ayude. Cuando vuelvo a la codificación solo con configuraciones simples (editor + compilador / intérprete), me parece más engorroso y los lenguajes dinámicos parecen más fáciles de usar. Pero aún buscas insectos. Supongo que la gente diría que el problema de las herramientas es un argumento reversible, como si las herramientas fueran mejores para los lenguajes dinámicos, entonces la mayoría de los errores y errores tipográficos se señalarían en el momento de la codificación, pero eso refleja la falla en el sistema en mi opinión. Aún así, usualmente prototipo en JRuby y codificaré en Java más tarde la mayoría de las cosas que hago. Como si las herramientas fueran mejores para los lenguajes dinámicos, entonces la mayoría de los errores y errores tipográficos se señalarían en el tiempo de codificación, pero eso refleja la falla en el sistema en mi opinión. Aún así, usualmente prototipo en JRuby y codificaré en Java más tarde la mayoría de las cosas que hago. Como si las herramientas fueran mejores para los lenguajes dinámicos, entonces la mayoría de los errores y errores tipográficos se señalarían en el tiempo de codificación, pero eso refleja la falla en el sistema en mi opinión. Aún así, usualmente prototipo en JRuby y codificaré en Java más tarde la mayoría de las cosas que hago.

ADVERTENCIA: Algunos de estos enlaces no son confiables, y algunos pasan por portales de varias sociedades de computación que utilizan accesos de pago para los miembros. Lo siento, intenté encontrar varios enlaces para cada uno de estos, pero no es tan bueno como me gustaría que fuera.

Ayer mismo encontré este estudio: las pruebas unitarias no son suficientes. También necesitas escribir estática.

Básicamente, el autor utilizó una herramienta capaz de convertir automáticamente un proyecto de un lenguaje de escritura no estático en uno de escritura estática (python a haskell)

Luego seleccionó una serie de proyectos de Python de código abierto que también incluían una cantidad razonable de unidades de prueba, y los convirtió automáticamente en haskell.

La traducción a Haskell reveló una serie de errores relacionados con el tipo de variables: los errores no fueron descubiertos por las unidades de prueba.

• Enlace a la discusión del documento de ACM " Un experimento sobre sistemas de tipo estático y dinámico " (2010) por el artículo de Stephan Hanenberg (referenciado por Lorin Hochstein en una publicación anterior).
• Conclusión: la productividad para una calidad similar fue mayor en un lenguaje dinámico.
• Posibles sesgos / problemas de validez: sujetos experimentales eran todos estudiantes. Además, una variedad limitada de las tareas de programación (se pidió a los sujetos que implementaran un escáner y un analizador).

  ---

• Documento de ACM " ¿Los lenguajes de programación afectan la productividad? " (2007) por Delorey, Knudson y Chun.
• Conclusión: JavaScript, Tcl, Perl son más productivos que C # C ++ y Java. Python y PHP caen en el medio.
• Posibles sesgos / problemas de validez: No se mide la calidad (como los errores descubiertos después del lanzamiento). No hay medida de confiabilidad (¿el software escrito en idiomas estáticamente tipados es más confiable?). Sesgo de muestra: todos los proyectos fueron abiertos tomados de repositorios CVS de código abierto. Además, no hay distinción entre lenguajes débilmente y fuertemente tipados (es decir, punteros).

  ---

• Tesis " Estudio empírico de productividad y calidad del software " (2008) por Michael F. Siok
• Conclusión: la elección del lenguaje de programación no influye significativamente en la productividad o la calidad. Sin embargo, sí afecta los costos laborales y la "calidad dentro de la cartera general de proyectos de software".
• Posibles sesgos / problemas de validez: Restringido al dominio de aviónica. Los lenguajes de programación podrían haber sido tipados estáticamente. No leí la tesis, así que no puedo evaluar su rigor.

  ---

  Mi opinión. Aunque existe evidencia débil de que los lenguajes escritos dinámicamente son más productivos, no es concluyente. (1) Hay muchos factores que no fueron controlados, (2) hay muy pocos estudios, (3) ha habido poca o ninguna discusión sobre lo que constituye un método de prueba apropiado.

Aquí hay un punto de partida:

• ¿Los lenguajes de programación afectan la productividad? Un estudio de caso que utiliza datos de proyectos de código abierto (Delorey, Knutson, Chun, 2007)

El documento desafía la sabiduría comúnmente recibida de que, siendo todo lo demás igual, los programadores escriben la misma cantidad de líneas de código por vez, independientemente del idioma. En otras palabras, el documento debe servir como evidencia empírica de apoyo de que la productividad mecánica (líneas de código escritas) no es una buena medida de la productividad funcional, y al menos debe ser normalizada por el lenguaje.

He encontrado un lenguaje estático frente a un lenguaje dinámico: una revisión de la literatura , que enumera algunos estudios sobre el tema y ofrece un buen resumen de cada estudio.

Aquí está el resumen ejecutivo:

De los experimentos controlados, solo tres muestran un efecto lo suficientemente grande como para tener algún significado práctico. El estudio Prechelt comparó C, C ++, Java, Perl, Python, Rexx y Tcl; el estudio Endrikat que compara Java y Dart; y el experimento de Cooley con VHDL y Verilog. Desafortunadamente, todos tienen problemas que dificultan llegar a una conclusión realmente sólida.

En el estudio de Prechelt, las poblaciones eran diferentes entre lenguajes dinámicos y mecanografiados, y las condiciones para las tareas también eran diferentes. Hubo un estudio de seguimiento que ilustró el problema al invitar a Lispers a encontrar sus propias soluciones al problema, lo que implicó comparar personas como Darius Bacon con estudiantes universitarios aleatorios. Un seguimiento del seguimiento literalmente implica comparar el código de Peter Norvig con el código de estudiantes universitarios al azar.

En el estudio de Endrikat, escogieron específicamente una tarea en la que pensaban que la escritura estática marcaría la diferencia, y sacaron a sus sujetos de una población en la que todos habían tomado clases usando el lenguaje estáticamente escrito. No comentan si los estudiantes tenían o no experiencia en el lenguaje escrito dinámicamente, pero parece seguro asumir que la mayoría o todos tenían menos experiencia en el lenguaje escrito dinámicamente.

El experimento de Cooley fue uno de los pocos que atrajo a personas de una población no estudiantil, lo cual es genial. Pero, como con todos los otros experimentos, la tarea era una tarea trivial de juguete. Si bien parece condenatorio que ninguno de los participantes de VHDL (lenguaje estático) haya podido completar la tarea a tiempo, es extremadamente inusual querer terminar un diseño de hardware en 1.5 horas en cualquier lugar fuera del proyecto escolar. Podría argumentar que una tarea grande se puede dividir en muchas tareas más pequeñas, pero un argumento en contra plausible es que hay costos fijos usando VHDL que se pueden amortizar en muchas tareas.

En cuanto al resto de los experimentos, la conclusión principal que tengo de ellos es que, bajo el conjunto específico de circunstancias descritas en los estudios, cualquier efecto, si es que existe, es pequeño.

Pasando a los estudios de casos, los dos estudios de casos de búsqueda de errores son una lectura interesante, pero en realidad no hacen un caso a favor o en contra de los tipos. Uno muestra que la transcripción de programas Python a Haskell encontrará un número distinto de cero de errores de gravedad desconocida que podrían no encontrarse a través de pruebas unitarias orientadas a la cobertura de línea. El par de documentos de Erlang muestra que puede encontrar algunos errores que serían difíciles de encontrar a través de cualquier tipo de prueba, algunos de los cuales son graves, utilizando análisis estático.

Como usuario, me parece conveniente cuando mi compilador me da un error antes de ejecutar herramientas de análisis estático separadas, pero eso es menor, tal vez incluso más pequeño que el tamaño del efecto de los estudios controlados enumerados anteriormente.

Encontré el estudio de caso de 0install (que comparó varios lenguajes con Python y finalmente se instaló en Ocaml) como una de las cosas más interesantes que encontré, pero es el tipo de cosa subjetiva que todos interpretarán de manera diferente, lo que puedes ver al mirar .

Esto encaja con la impresión que tengo (en mi pequeño rincón del mundo, ACL2, Isabelle / HOL y PVS son los probadores más utilizados, y tiene sentido que la gente prefiera más automatización al resolver problemas en la industria), pero eso es También subjetivo.

Y luego están los estudios que extraen datos de proyectos existentes. Desafortunadamente, no pude encontrar a nadie que hiciera algo para determinar la causalidad (por ejemplo, encontrar una variable instrumental adecuada), por lo que solo miden las correlaciones. Algunas de las correlaciones son inesperadas, pero no hay suficiente información para determinar por qué.

El único estudio de minería de datos que presenta datos que son potencialmente interesantes sin una mayor exploración es la revisión de Smallshire de los errores de Python, pero no hay suficiente información sobre la metodología para entender lo que realmente significa su estudio, y no está claro por qué insinuó mirar datos para otros idiomas sin presentar los datos 3.

Algunas omisiones notables de los estudios son estudios exhaustivos que utilizan programadores experimentados, y mucho menos estudios que tienen grandes poblaciones de programadores "buenos" o "malos", que analizan cualquier cosa que se aproxime a un proyecto significativo (en lugares donde he trabajado, un proyecto de tres meses ser considerado pequeño, pero eso es múltiples órdenes de magnitud más grandes que cualquier proyecto usado en un estudio controlado), usando lenguajes "modernos" con escritura estática, usando escritura gradual / opcional, usando IDEs convencionales modernos (como VS y Eclipse), usando IDEs radicales modernos (como LightTable), usar editores de la vieja escuela (como Emacs y vim), realizar tareas de mantenimiento en una base de código no trivial, realizar tareas de mantenimiento con algo parecido a un entorno realista, realizar tareas de mantenimiento en una base de códigos con la que ya está familiarizado, etc.

Si observa los comentarios de Internet sobre estos estudios, la mayoría de ellos se pasan para justificar un punto de vista u otro. El estudio Prechelt sobre dinámico frente a estático, junto con los seguimientos en Lisp son los favoritos de los defensores del lenguaje dinámico, y el estudio de minería de github se ha puesto de moda recientemente entre los programadores funcionales.

Sinceramente, no creo que la tipificación estática vs dinámica sea la verdadera pregunta.

Creo que hay dos parámetros que deberían venir primero:

• el nivel de experiencia en el idioma: cuanto más experiencia tenga, más sabe acerca de las "trampas" y es más probable que las evite / rastree fácilmente. Esto también es cierto sobre la aplicación / programa particular en el que está trabajando
• pruebas: me encanta la escritura estática (demonios, me gusta programar en C ++: p) pero hay tantas cosas que un compilador / analizador estático puede hacer por usted. Es simplemente imposible confiar en un programa sin haberlo probado. Y estoy a favor de las pruebas difusas (cuando corresponde), porque simplemente no puede pensar en todas las combinaciones de entrada posibles.

Si se siente cómodo con el idioma, escribirá el código y localizará los errores con facilidad.

Si escribe código desacoplado y prueba cada funcionalidad exhaustivamente, producirá un código bien perfeccionado y, por lo tanto, será productivo (porque no puede calificar como productivo si no evalúa la calidad del producto, ¿verdad? )

Por lo tanto, consideraría que el debate estático vs dinámico con respecto a la productividad es bastante discutible, o al menos ampliamente reemplazado por otras consideraciones.

Aquí hay algunos:

• Stefan Hanenberg. 2010. Un experimento sobre sistemas de tipos estáticos y dinámicos: dudas sobre el impacto positivo de los sistemas de tipos estáticos en el tiempo de desarrollo. En Actas de la conferencia internacional de ACM sobre lenguajes y aplicaciones de sistemas de programación orientados a objetos (OOPSLA '10). ACM, Nueva York, NY, EE. UU., 22-35. DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

• Daniel P. Delorey, Charles D. Knutson, Scott Chun, "¿Los lenguajes de programación afectan la productividad? Un estudio de caso que utiliza datos de proyectos de código abierto", hilo dental, pp.8, primer taller internacional sobre tendencias emergentes en investigación y desarrollo de software libre (FLOSS) '07: Talleres ICSE 2007), 2007

• Daly, M .; Sazawal, V., Foster, J .: Work in Progress: an Empirical Study of Static Typing in Ruby, Workshop on Evaluation and Usabilidad of Programming Language and Tools (PLATEAU) en ON-WARD 2009.

• Lutz Prechelt y Walter F. Tichy. 1998. Un experimento controlado para evaluar los beneficios de la verificación del tipo de argumento del procedimiento. IEEE Trans. Softw. Ing. 24, 4 (abril de 1998), 302-312. DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186