fuerte tipos estáticos / y refactorización

Question

Me parece que lo más invalorable acerca de un lenguaje de programación estática / inflexible de tipos es que ayuda a la refactorización:. Si / cuando se cambia cualquier API, entonces el compilador le dirá lo que el cambio se ha roto

Me puedo imaginar la escritura de código en un lenguaje de ejecución / tipos débiles-... pero no puedo imaginar refactorización sin la ayuda del compilador, y no puedo imaginar escribir decenas de miles de líneas de código sin refactorización.

¿Es esto cierto?

Answer 1

Creo que estás confundir cuando los tipos se comprueban con la forma en que están marcadas. la tipificación de tiempo de ejecución no es necesariamente débil.

La principal ventaja de tipos estáticos es exactamente lo que dice: son exhaustivas. Puede estar seguro de todos los sitios de llamadas conformes con el modelo con sólo dejar que el compilador lo hace la cosa.

La principal limitación de los tipos estáticos es que están limitados en las restricciones que pueden expresar. Esto varía según el idioma, la mayoría de los idiomas tienen sistemas relativamente simples de tipo (C, Java), y otros con sistemas muy potentes de tipo (Haskell, cayena).

Debido a esto los tipos de limitación por sí mismas no son suficientes. Por ejemplo, en tipos de Java son más o menos restringido a la comprobación de nombres de tipo partido. Esto significa que el significado de cualquier restricción que desee comprobar tiene que ser codificado en un esquema de nombres de algún tipo, por lo tanto, la gran cantidad de indirecciones y placa de la caldera común de código java. C ++ es un poco mejor en que las plantillas permiten un poco más expresividad, pero no se acercan a lo que puede hacer con tipos dependientes. No estoy seguro de lo que los inconvenientes de los sistemas de tipo son más potentes, aunque es evidente que debe haber algunas o más personas estarían utilizando en la industria.

Incluso si usted está utilizando tipos estáticos, lo más probable es que no es lo suficientemente expresiva para comprobar todo lo que te importa, por lo que tendrá que escribir pruebas también. Ya sea tipos estáticos le ahorra más esfuerzo que se requiere en el texto modelo es un debate que se extendió durante siglos y que no creo que tiene una respuesta sencilla para todas las situaciones.

En cuanto a su segunda pregunta:

¿Cómo podemos re-factor de forma segura en un lenguaje escrito en tiempo de ejecución?

La respuesta es pruebas. Sus pruebas tienen que cubrir todos los casos que importan. Herramientas que pueden ayudar a calibrar la forma exhaustiva sus pruebas son. herramientas de cobertura de comprobación permiten saber líneas de código wether están cubiertos por las pruebas o no. herramientas de prueba de mutación (bufón, Heckle) le permite saber si sus pruebas son lógicamente incompleta. Las pruebas de aceptación permiten saber lo que ha escrito los requisitos de los partidos, y las pruebas de regresión y de rendimiento, por último, asegúrese de que cada nueva versión del producto mantiene la calidad de la última.

Una de las mejores cosas de tener las pruebas adecuadas en su lugar frente a depender de indirecciones tipo elaborados es que la depuración se convierte en mucho más simple. Al ejecutar las pruebas se obtiene aserciones fallen específicas dentro de las pruebas que expresan claramente lo que están haciendo, en lugar de los estados de error del compilador obtusos (piensan c ++ errores de plantilla).

No importa qué herramientas se utiliza: la escritura de código que esté seguro en requerirá esfuerzo. Es muy probable que requieren un texto de una gran cantidad de pruebas. Si la pena para los insectos es muy alta, tales como la industria aeroespacial o el software de control médico, puede que tenga que utilizar métodos matemáticos formales para probar el comportamiento de su software, lo que hace que este desarrollo extremadamente caro.

Answer 2

Estoy totalmente de acuerdo con su sentimiento. La misma flexibilidad que los lenguajes de tipado dinámico se supone que son buenos en realidad, es lo que hace el código muy difícil de mantener. Realmente, ¿existe tal cosa como un programa que continúa trabajando si los tipos de datos se cambian de una forma no trivial sin cambiar el código?

Por el momento, se puede comprobar el tipo de variable que se pasa, y de alguna manera fallar si no es el tipo esperado. Usted aún tiene que ejecutar su código de erradicar esos casos, pero al menos algo lo diría.

Creo que las herramientas internas de Google en realidad hacen una compilación y, probablemente, la verificación de tipos a su Javascript. Me gustaría tener esas herramientas.

Answer 3

Para empezar, yo soy un programador de Perl nativo de modo, por un lado que nunca he programado con la red de tipos estáticos. Otoh nunca he programado con ellos, así que no puedo hablar de sus beneficios. Lo que yo puedo hablar de lo que su gusto es refactorizar.

No encuentro la falta de tipos estáticos a ser un problema refactorización WRT. Lo que me parece un problema es la falta de una refactorización navegador . lenguajes dinámicos tienen el problema de que no se sabe muy bien lo que el código es realmente va a hacer hasta que realmente se ejecute. Perl tiene esto más que la mayoría. Perl tiene el problema adicional de tener un campo muy complicado, casi no se puede analizar, la sintaxis. Resultado: no hay herramientas de refactorización (aunque que están trabajando muy rápidamente en ese ). El resultado final es que tengo que refactorizar a mano. Y eso es lo que introduce errores.

Tengo pruebas para atraparlos ... normalmente. Yo encuentro a menudo frente a un humeante montón de código no comprobable no probado y casi con el problema de pollo / huevo de tener que refactorizar el código con el fin de probarlo, pero tener que probarlo con el fin de refactorizar. Ick. En este punto tengo que escribir algo muy tonto, alto nivel "hace la salida del programa lo mismo que antes" tipo de pruebas sólo para asegurarse de que no se rompió algo.

tipos estáticos, como se prevé en Java o C ++ o C #, en realidad sólo resolver una pequeña clase de problemas de programación. Garantizan sus interfaces se pasaron bits de datos con la etiqueta correcta. Pero sólo porque se obtiene una colección no significa que la colección contiene los datos que piensa que lo hace. Debido a que recibe un entero no significa que tienes el entero derecho. Su toma un objeto de usuario, pero se registra que el usuario en?

ejemplo Classic: public static double sqrt(double a) es la firma para la función raíz cuadrada de Java . raíz cuadrada no funciona en números negativos. ¿Dónde dice que en la firma? No lo hace. Peor aún, ¿dónde dice lo que incluso hace que la función? La firma Sólo dice qué tipos que se necesita y lo que devuelve. No dice nada acerca de lo que sucede en el medio y ahí es donde vive el código interesante. Algunas personas han tratado de captar la API completa mediante el uso de diseño de contrato, el cual en términos generales se puede describir como la incorporación de las pruebas de tiempo de ejecución de las entradas de su función, los resultados y efectos secundarios (o su ausencia) ... pero eso es otro espectáculo.

Una API es mucho más que sólo las firmas de función (si no fuera, no sería necesario que todos los prosa descriptiva en el Javadocs) y refactorización es mucho más incluso que simplemente cambiar la API.

La mayor ventaja refactorización un lenguaje compilado estáticamente tipado estático, no dinámico que da es la capacidad de escribir herramientas de refactorización hacer refactorizaciones bastante complejos para usted porque sabe donde todas las llamadas a sus métodos son. Estoy muy envidioso de IntelliJ IDEA .

Answer 4

Yo diría refactorización va más allá de lo que el compilador puede comprobar, incluso en lenguajes de tipo estático. Refactorización sólo está cambiando a programas estructura interna sin afectar el comportamiento externo. Incluso en los lenguajes dinámicos, todavía hay cosas que usted puede esperar que suceda y prueba para, que acaba de perder un poco de ayuda del compilador.

Answer 5

Una de las ventajas de utilizar var en C # 3.0 es que puede a menudo cambiar el tipo sin romper ningún código. El tipo tiene que todavía se ven las mismas propiedades - con los mismos nombres debe existir, todavía deben existir métodos con el mismo o similar firma. Pero realmente se puede cambiar a un tipo muy diferente, incluso sin utilizar algo así como ReSharper.