Diferencias arquitectónicas entre lenguajes dinámicos y estáticos.

¿Existen diferencias arquitectónicas importantes al diseñar aplicaciones que se construirán en lenguajes estáticos (como C # o Java) y lenguajes dinámicos (como Ruby o Python)?

¿Cuáles son las posibilidades de diseño que podrían ser una buena opción para un tipo que es malo para el otro? ¿Hay alguna característica útil que se pueda lograr con un tipo que no sea con el otro (en diseño y arquitectura, por supuesto)?

Además, ¿hay algún patrón de diseño dinámico específico?

Vamos a aclarar algunas cosas:

1. Los scripts interactivos y los lenguajes estáticos no son mutuamente excluyentes. F # y Haskell tienen interfaces REPL.
2. Los lenguajes dinámicos y el alto rendimiento no son mutuamente excluyentes, aunque algunas optimizaciones sí lo son. JavaScript se ejecuta bastante rápido en la mayoría de los navegadores hoy en día.
3. Incluso en lenguajes dinámicos, aún necesita documentar, recordar y pensar sobre los tipos.
4. Debido a la creciente popularidad de la inferencia de tipos, muchos lenguajes estáticos ya no tienen que anotar tipos muy a menudo. En lenguajes estáticos con una fuerte inferencia de tipos, el compilador determina cuáles son los tipos de su código de manera que la mayoría de las veces, y le dice si alguna vez hace algo que viola las definiciones de tipos. En lo que respecta a la sintaxis, esto proporciona lo mejor de ambos mundos.
5. OOP y lenguajes dinámicos no son mutuamente excluyentes. PHP ahora admite clases e incluso herencia.

Dejando a un lado todas esas sorprendentes similitudes, hay algunas diferencias prácticas que influyen en el proceso de desarrollo:

1. Los lenguajes dinámicos permiten formas interesantes de pasar datos en pequeños .
2. Los lenguajes estáticos le permiten reducir la cantidad de pruebas que tiene que hacer al hacer que muchos tipos de errores sean imposibles.
3. En ese mismo sentido, los lenguajes estáticos permiten funciones interesantes de validación y conversión automática, como unidades de medida en F # .
4. Llevado al extremo, los lenguajes estáticos permiten contratos de código y verificación formal, que pueden documentar y evitar completamente cosas como posibles divisiones por ceros, bucles infinitos, referencias nulas, índices o tamaños de lista no válidos, errores de rango y otros estados lógicamente inválidos que puedas definir.
5. Llevando ese extremo aún más lejos, las optimizaciones de la CPU se pueden hacer en base a estas restricciones estáticas, lo que produce un rendimiento aún mejor.

También hay un tipo de programa que nunca podría haberse hecho sin tipeo estático: Singularity , un sistema operativo sin límites de proceso de hardware. Está escrito en una pequeña cantidad de C, algo de C # y un dialecto de C # llamado Spec #, que admite contratos de código.

A pesar de estar escrito en un lenguaje recolectado como basura, el rendimiento de la comunicación multitarea y entre procesos en este sistema operativo es, de hecho, mejor que cualquier otra cosa, debido al hecho de que todos los procesos se ejecutan en un espacio de memoria y debido a las optimizaciones de verificación formales I mencionado anteriormente. No podría hacer esto sin tipeo estático, porque para que los programas no puedan comprometer el resto del sistema, los objetos de comunicación deben ser estáticamente verificables.

Sin embargo, la mayoría de las veces, las arquitecturas deberían ser muy similares. Los lenguajes estáticos pueden hacer que los programas sean más fáciles de razonar en muchos casos porque los tipos están bien definidos, pero un programa de lenguaje dinámico bien escrito también tendría tipos que, al menos, están bien definidos en la mente de los desarrolladores.

Hay una diferencia arquitectónica significativa. Actuación.

Dependiendo de su presupuesto de hardware, la carga de trabajo esperada y los acuerdos de nivel de servicio, es posible que no sea posible cumplir los requisitos con un lenguaje dinámico.

Con mayor frecuencia, la velocidad de desarrollo y la flexibilidad proporcionadas por los lenguajes dinámicos compensan los tiempos de respuesta más lentos y el consumo de memoria y CPU más elevado. Pero para sistemas más grandes con limitaciones de presupuesto o rendimiento, los gastos generales de un lenguaje dinámico pueden ser altos.

Nunca he pensado en este sentido. Entonces, cuando hizo un Google, el blog de Peter Norvig fue uno de los principales éxitos. Dice que algunos patrones de diseño son más fáciles de implementar en lenguajes dinámicos que los lenguajes orientados a objetos tradicionales como C ++. Creo que también debería haber diferencias en el diseño / arquitectura, ya que señala que la implementación es más fácil en lenguajes dinámicos. Intentaré agregar más a la respuesta a medida que estudie más.

¿Existen diferencias arquitectónicas importantes al diseñar aplicaciones que se construirán en lenguajes estáticos (como C # o Java) y lenguajes dinámicos (como Ruby o Python)?

No.

Es un poco más fácil escribir marcos sofisticados para lenguajes dinámicos. Pero eso no es una cosa de aplicación.

¿Cuáles son las posibilidades de diseño que podrían ser una buena opción para un tipo que es malo para el otro?

Ninguno, de verdad.

Puedes escribir cosas buenas en cualquier idioma amable.

¿Hay características útiles que se puedan lograr con un tipo que no sea con el otro (en diseño y arquitectura, por supuesto)?

No.

La diferencia es que los lenguajes dinámicos son "escribir, ejecutar, corregir". Puedes experimentar y arreglar rápidamente.

Los lenguajes estáticos son "escribir, compilar, construir, ejecutar, corregir". No puedes experimentar tan fácilmente.

Aparte de eso, son casi idénticos en sus capacidades.

¿Hay algún patrón de diseño dinámico específico?

Tal vez. Python eval()y sus execfile()funciones, en cierto modo, apuntan a una característica de lenguaje dinámico que es difícil (pero lejos de ser imposible) manejar en un lenguaje estático. Sería mucho más líneas de código para compilar y ejecutar código en el mismo espacio de proceso.

No es específico del lenguaje dinámico. Es mas facil.