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

69

¿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.

Winston Ewert
fuente
8
@bigown, no me parece que los problemas de productividad y defectos se relacionen con la teoría de la informática
Winston Ewert
2
@ Winston: Estudiar este tipo de problemas es el trabajo de los informáticos, no de los programadores.
Maniero
9
@bigown, sí, es un problema informático, pero no es un problema de teoría informática. La teoría de CS trata esencialmente de lo que podemos probar matemáticamente acerca de los programas y la informática. Los problemas de productividad del programador no son preguntas de teoría cs. Ha habido discusiones sobre tipeo dinámico tanto aquí como en stackoverflow. No ha habido ninguno en teoría.
Winston Ewert
8
La pregunta es perfectamente sobre el tema. Esta pregunta analiza una de las propiedades más importantes de las herramientas que utilizamos para programar.
Frank Shearar
44
@ Winston: Los sistemas de mecanografía pertenecen a la teoría de CS, pero los estudios prácticos no.
David Thornley

Respuestas:

42

Algunas lecturas sugeridas:

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

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

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

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.

haylem
fuente
Ese hallazgo de error, ¿se debe principalmente a nombres de variables mal escritos, o nombres de métodos, o en algún punto intermedio? ( Odio la declaración de variables implícitas precisamente por esta razón: en Smalltalk, declara todas sus variables en la parte superior, por lo que inmediatamente sabe cuándo ha escrito mal el nombre de una variable. (Los errores tipográficos del nombre del método a veces también se detectan, si el nombre del método nunca es sido utilizado en la imagen antes.))
Frank Shearar
Re herramientas, tengo que decir que depende de su idioma: Smalltalk tiene excelentes herramientas, incluido un navegador de refactorización que Eclipse tiene (según me dicen) aún para ponerse al día.
Frank Shearar
@Frank Shearar, desde que comencé con Ruby (proveniente de Java), me di cuenta de que lo que dice @ haylem probablemente no se aplica a Smalltalk. Tampoco mi mantra sobre la refactorización automática es imposible en langs de tipo dinámico. Estoy completamente de acuerdo con la sección "personalmente" de Haylem ... ignorando SmallTalk, por supuesto :) Esto es justo, hasta cierto punto, ya que SmallTalk, aunque no está muerto, definitivamente no disfruta de la popularidad que Python o Ruby tienen (ahora en octubre de 2010 )
Dan Rosenstark el
3
@haylem, personalmente te agradezco por hacerme sentir que no soy la única persona en el mundo que trabaja en lenguajes dinámicos pero, cuando se me da la opción, muchas veces ELIGE lenguajes de tipo estático (el mismo caso, Java vs. JRuby o Groovy).
Dan Rosenstark
44
Es interesante porque mi preferencia por la escritura dinámica es por razones bastante diferentes. Quiero decir que las compilaciones rápidas y el intérprete interactivo son útiles, pero no es por eso que me gusta la escritura dinámica. Me gusta la escritura dinámica porque encuentro muchas situaciones en las que los lenguajes de escritura estática hacen que sea difícil o imposible describir un concepto en particular.
Winston Ewert
19

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.

PBrando
fuente
44
La verdad incómoda de la tipificación dinámica.
Den el
66
"La traducción a Haskell reveló una serie de errores relacionados con el tipo de las variables: los errores no fueron descubiertos por las unidades de prueba". tipo de lenguaje son verificados automáticamente por el compilador. Esto es más lento y propenso a errores. +1
Giorgio
44
Respondí a una publicación en este enlace en Reddit. No creo que las conclusiones extraídas del documento sean razonables.
Veedrac
Ambos sistemas de mecanografía tienen pro / contras y sus usos. Es como discutir sobre llevar una ametralladora a una pelea mano a mano. Esa es una guerra de religiones lejos de terminar. Dicho esto, estoy de acuerdo con Veedrac. Los lenguajes no estáticos necesitan más casos de prueba para detectar errores causados ​​por tipos. Esa es su naturaleza y estafa. Pero, un programador necesita escribir una prueba que detecte un error en el código causado por un estado inesperado de entrada, no necesariamente pruebas exhaustivas para el tipo de entrada.
Andre Figueiredo
10
  • 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.
ahoffer
fuente
6

Aquí hay un punto de partida:

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.

Piet Delport
fuente
55
Para las personas que no son IEEE, ¿cuál es el resumen básico?
Frank Shearar
1
@ Frank Shearar, la conclusión que extraen es que el lenguaje de programación sí afecta la productividad. Están midiendo líneas de código por programador por idioma por año, no estoy seguro de que sea una buena medida de productividad.
Winston Ewert
3
@ Winston: Esa es definitivamente una métrica defectuosa. Encontraría que COBOL es un lenguaje muy productivo: requiere muchas líneas para hacer algo útil, pero son bastante fáciles de escribir.
David Thornley
Winston, David: Estoy bastante seguro de que los autores no sugieren que la productividad de las líneas de código sea una medida de la productividad funcional . Más bien, 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 debería 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.
Pi Delport
Estoy de acuerdo con eso. Pero no sirve para responder mi pregunta original.
Winston Ewert
1

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.

Mr.WorshipMe
fuente
0

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.

Matthieu M.
fuente
2
Si esta es una contrapregunta, ¿dónde está la pregunta? :) Estoy de acuerdo en que otros factores son más importantes que la escritura estática frente a la dinámica. Sin embargo, los defensores de la escritura dinámica afirman una mejor productividad y los defensores de la escritura estática afirman una mejor calidad de código. Me preguntaba si alguien tenía evidencia real para respaldar sus afirmaciones.
Winston Ewert
@ Winston: eliminé el bit de contador: p Como mencionaste, en su mayoría son reclamos. Creo que la mayoría de los defensores de la escritura dinámica mezclan la facilidad de uso con la escritura dinámica, mientras que la facilidad de uso se trata principalmente de herramientas. Estoy de acuerdo en que la posibilidad de escribir prototipos de descarte rápido y experimentar comandos cortos con un intérprete es un impulso de productividad, pero incluso Haskell (quizás el lenguaje con el sistema de tipos más impresionante del momento) tiene un intérprete para la experimentación rápida: )
Matthieu M.
Pero hasta que alguien realmente haga un estudio que considere esta pregunta: si la metodología, las herramientas tienen un impacto mayor que el lenguaje en las tasas de defectos y la productividad, terminamos comparando anécdotas.
Frank Shearar
0

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

Lorin Hochstein
fuente