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.