Cansado de ensayos no semántica para compensar tipado dinámico - sugerencias?

Question

Yo solía hacer un montón de programación web en Rails (PHP antes de eso) antes de empezar a estudiar ingeniería informática.

Desde entonces, he hecho un montón de trabajo de la escuela en C, y algunas cosas personales en Objective-C (cosas Mac). Aprendí a mecanografiar amor estática.

Pero ahora estoy teniendo que hacer un poco de desarrollo web profesional (trabajo independiente) y han recogido los carriles una vez más. Me resulta muy molesto para escribir ensayos de comprobación no semánticas. Me estaba libre de aquellos para los compiladores C y Objective-C. Me encantó golpear Construir y el sistema verifica toda mi código para ver que A puede llamar a B, B puede llamar a alguna biblioteca C oscura, etc. Todo lo que tenía que hacer era prueba de la semántica. Pero con rieles, yo soy el compilador. :(

¿Alguien ha pisado este mismo camino? Son mis únicas opciones para el desarrollo web ASP.NET MVC con C # y Java + x marco? Buscando algunas sugerencias, o incluso algo de simpatía ...: P

Por cierto, me hace una referencia específica a los carriles en lugar de Rubí ya no me importa naturaleza dinámica de Ruby como cosas simples como secuencias de comandos o lo que no. Pero ya que los carriles depende de tantas gemas y puesto que por lo general se añade una serie de otras gemas, el tipado dinámico se convierte en un problema.

Gracias!

editar

he seguido la sugerencia de PST y mirado en Scala. Al leer el libro de programación en Scala, escrita por el creador de la lengua, Martin Odersky, me encontré con este fragmento de texto que de muchas maneras expresa mis preocupaciones y un poco más. lectura muy interesante.

Tomado de la página 52 de Programación de Martin Odersky en Scala:

Scala es estático de tipos

A de tipo estático clasifica sistema variables y expresiones según los tipos de valores que desempeñe y calcular. Scala se destaca como una con un lenguaje estático muy avanzada sistema de tipos. A partir de un sistema de tipos de clases anidadas tanto como Java, que le permite parametrizar tipos con los genéricos, para combinar tipos usando intersecciones, y para ocultar detalles de tipos utilizando tipos abstractos. estos dan una base sólida para la construcción y Creación de sus propios tipos, por lo que se puede diseñar interfaces que se encuentran en el mismo seguro tiempo y flexible para su uso.

Si como dinámica idiomas como Perl, Python, Ruby, o maravilloso, que podría encontrar un poco extraño que sistema de tipo estático de Scala está en la lista como uno de sus puntos fuertes. Después todo, la ausencia de un tipo estático sistema ha sido citado por algunos como una las principales ventajas de los lenguajes dinámicos. Los argumentos más comunes contra tipos estáticos son que hacen programas demasiado prolijo, impiden programadores de expresarse como lo deseen, y hacen imposible ciertos patrones de dinámica modificaciones de los sistemas de software.

Sin embargo, a menudo estos argumentos no hacen ir en contra de la idea de tipos estáticos en general, pero en contra de tipo específico sistemas, que son percibidos como demasiado verbosa o demasiado inflexible. por ejemplo, Alan Kay, el inventor de el lenguaje Smalltalk, una vez comentó: “No estoy en contra tipos, pero no lo hago saber de cualquier tipo systemsthat no son una completo del dolor, por lo que todavía me gusta dinámico escribir “.

Esperamos que convencer en este libro que el sistema de tipo de Scala está lejos de ser un “dolor total”. De hecho, se direcciones muy bien dos de los habituales preocupaciones acerca de tipos estáticos: verbosidad se evita a través de tipo inferencia y la flexibilidad se gana a través de coincidencia de patrones y varios nuevas formas de escribir y los tipos de composición. Con estos impedimentos fuera del camino, las ventajas clásicas de tipo estático sistemas pueden ser mejor apreciadas. Entre los más importantes de éstos beneficios son propiedades verificables de abstracciones del programa, salvo refactorizaciones, y una mejor documentación.

propiedades verificables

tipo estático sytallos pueden probar la ausencia de ciertos errores en tiempo de ejecución. Por ejemplo, pueden resultar propiedades como: booleanos no son nunca añadido a números enteros; variables privadas no se tiene acceso desde fuera de su clase; funciones se aplican a la número correcto de argumentos; solamente cadenas se añaden siempre a un conjunto de cuerdas.

Otros tipos de errores no se detectan por los sistemas de tipo estático de hoy en día. por ejemplo, que por lo general no detecta funciones no de terminación, array delimita violaciónes, o divisiones por cero. También no detectar que su programa no se ajusta a su especificación (suponiendo que hay una spec, que es!). sistemas de tipo estático por lo tanto, han sido despedidos por algunos como no ser muy útil. El argumento va que, dado que los sistemas de este tipo lata Sólo detectar errores simples, mientras pruebas de unidad proporcionan más extensa la cobertura, ¿por qué molestarse con tipos estáticos ¿en absoluto?

Creemos que estos argumentos pierden el punto. Aunque un tipo estático sistema ciertamente no puede sustituir a la unidad las pruebas, se puede reducir el número de pruebas de unidad que necesita el cuidado de algunas de las propiedades que de otro modo necesidad de ser probado. Del mismo modo, la unidad la prueba no puede sustituir a los tipos estáticos. Después de todo, como dijo Edsger Dijkstra, las pruebas sólo puede demostrar la presencia de errores, no su ausencia. Entonces el garantiza que los tipos estáticos da pueden ser simples, pero son reales garantías de una forma ninguna cantidad de pruebas puede ofrecer.

refactorizaciones seguras

sistema A de tipo estático proporciona una red de seguridad que le permite realizar cambios a una base de código con un alto grado de confianza. Considere, por ejemplo, una refactorización que agrega un adicional parámetro a un método. En una forma estática lengua escrita a máquina que puede hacer el cambio, volver a compilar el sistema y simplemente fix todas las líneas que causan un error de tipo. Una vez que haya terminado con esto, están seguros de haber encontrado todos los lugares que las necesitar ser cambiado. Lo mismo vale para muchos otros simples como refactorizaciones cambiar un nombre de método, o mover métodos de una clase a otra. En todos los casos una verificación de tipos estáticos proveer suficiente seguridad de que el nuevo sistema funciona igual que el antiguo.

Documentación

tipos estáticos son documentación del programa que está marcada por el compilador para exactitud. A diferencia de un comentario normal, un tipo de anotación nunca puede estar fuera de fecha (al menos no si el archivo de origen que lo contiene se ha aprobado recientemente una compilador). Además, los compiladores y entornos de desarrollo integrado puede hacer uso de anotaciones de tipo de proporcionar una mejor ayuda contextual. por ejemplo, un desarrollo integrado medio ambiente puede mostrar toda la miembros disponibles para una selección por determinar el tipo estático de la expresión en el que la selección es hecho y mirando hacia arriba todos los miembros de ese tipo.

Answer 1

Este es uno de mis "quejas" sobre los lenguajes dinámicos. Quiero poner a prueba para la semántica, no introduzca errores ;-) Una vez dicho esto, una buena prueba de marco / configuración es realmente una necesidad en todas las situaciones no triviales y buen código-cobertura y requisitos evaluados es / son importantes.

Si quieres ir por el camino de la electricidad estática que pulsa en la JVM (tengo), se lo recomendaría mirando Scala. Viniendo de Ruby, que es mucho menos doloroso (y en realidad un montón de diversión en diferentes formas) que va a Java. Tienes la oportunidad de "mantener" las cosas que damos por sentado - una sintaxis basada en la expresión, cierres, la capacidad de tipos Omitir en muchos lugares (no tan abierto como Ruby, pero se obtiene la comprobación de tipos en tiempo de compilación ;-), todo (*) - es-un-objeto OO y unificado métodos de acceso, capacidad de DSL construir fácilmente, y el azúcar - y obtener los beneficios de un lenguaje de tipos estáticos con inferencia de tipos locales, búsqueda de patrones, un marco de recogida relativamente rico, y la integración decente con Java (incluyendo los numerosos marcos web, hay algunos marcos Scala-específicas, así que aprovechan el lenguaje Scala).

C # 3.0 / 4.0 (y .NET3.5 +) no es demasiado mal o bien (pero evite C # 2.0, que ahora es de esperar que un vestigio), con la introducción de LINQ / cierres, la inferencia de tipo básico y otra buen lenguaje ofrece lo encuentro "aceptable" para la mayoría de tareas (tener una pista sobre la forma en que lo clasificaría Java como lenguaje ;-). Sin embargo, C # es un lenguaje CLR-objetivo (no es / era un puerto NET Scala, pero no estoy seguro de la situación - que no es la principal plataforma de destino sin embargo).

Desde que he mencionado Scala, que debería también mencionar F # (ahora un idioma "oficial" NET), que adopta el enfoque "funcional con OO" ser similar a OCaml - Scala es más bien al revés y lo describiría como "OO con funcional". He escuchado argumentos a favor / en contra F # C # en comparación con w.r.t el sistema de tipos, pero no tienen experiencia práctica con F #. Usted puede o no ser igual que el cambio de paradigma.

Happy codificación.

Answer 2

Como se menciona rieles, y considerando que se han interesado en Scala, sin duda debe Ascensor . He aquí una 2008 entrevista con su creador, y una 2009 la presentación (vídeo), que me enlace, ya que, aunque viejo, se comparan con Ascensor alternativas en otros idiomas.

Si Ascensor no es su cosa, sin embargo, puede estar seguro de que hay otra web Scala marcos .

Answer 3

Este tipo de pruebas no se realiza normalmente en Rails. En lugar de estar molesto por tener que hacerlo, no considerar la preocupación de ella. O tal vez hacer un mejor trabajo de explicar por qué piensa que es un problema, ya que la mayoría Rails programadores no lo hacen.

Actualizar

La persona que escribió test_include_with_order_works es asegurarse de que los carriles interpretará un símbolo de la misma como una cadena en este caso particular. Eso no parece como algo que tiene que probar, ya que los carriles ya ha proporcionado y probado esta funcionalidad para usted. Francamente, estoy un poco sorprendido de que cualquier persona incluso preocuparse de si o no un símbolo funcionará como una cuerda. Todos sabemos que se puede y con frecuencia lo hace.

En general, creo que el marco Rails tiene que asegurar que las cosas que no lo hace de manera que su aplicación se ajustará a su diseño. Creo que la filosofía de trabajo en lenguajes de tipado dinámico es que el código de cliente no va a pasar en los parámetros que rompan los métodos que están llamando. Si lo hacen, no consiguen ninguna utilización de llamar a los métodos. Usted no tiene que perder su tiempo asegurándose de que sus métodos lanzar excepciones cuando se proporciona demasiados parámetros, cuando su método puede tan fácilmente (y debe) hacer caso omiso de los parámetros adicionales.

Por lo tanto, no estoy seguro de si los ejemplos que nos has proporcionado realmente demuestran la necesidad de ensayos no semántica en Rails.