dynamic - programing - functional programming vs oop
¿Por qué se tipea dinámicamente Clojure? (5)
Una cosa que me gusta mucho es leer sobre diferentes lenguajes de programación. Actualmente estoy aprendiendo sobre Scala, pero eso no significa que no esté interesado en Groovy, Clojure, Python y muchos otros. Todos estos idiomas tienen una apariencia única y algunas características. En el caso de Clojure, no entiendo una de estas decisiones de diseño. Por lo que yo sé, Clojure pone gran énfasis en su paradigma funcional y prácticamente te obliga a usar "variables" inmutables siempre que sea posible. Entonces, si la mitad de sus valores son inmutables, ¿por qué el lenguaje está tipeado dinámicamente? El sitio web de clojure dice:
En primer lugar, Clojure es dinámico. Eso significa que un programa Clojure no es solo algo que usted compila y ejecuta, sino algo con lo que puede interactuar.
Bueno, eso suena completamente extraño. Si se compila un programa, ya no puede cambiarlo. Seguro que puedes "interactuar" con él, para eso se usan las IU pero el sitio web ciertamente no significa una GUI "dinámica" ordenada.
¿Cómo se beneficia Clojure de la tipificación dinámica?
Me refiero al caso especial de Clojure y no a las ventajas generales del tipado dinámico.
¿Cómo ayuda el sistema de tipo dinámico a mejorar la programación funcional?
Una vez más, sé el placer de no derramar "int a"; todo el código fuente, pero la inferencia tipo puede aliviar mucho el dolor. Por lo tanto, me gustaría saber cómo la tipificación dinámica admite los conceptos de un lenguaje funcional.
Si se compila un programa, ya no puede cambiarlo.
Esto está mal. En los sistemas basados en imágenes, como Lisp (Clojure se puede ver como un dialecto Lisp) y Smalltalk, puede cambiar el entorno compilado. El desarrollo en un lenguaje así normalmente significa trabajar en un sistema en ejecución, agregar y cambiar definiciones de funciones, definiciones de macro, parámetros, etc. (agregar significa compilar y cargar en la imagen).
Esto tiene muchos beneficios. Por un lado, todas las herramientas pueden interactuar directamente con el programa y no necesitan adivinar el comportamiento del sistema. Tampoco tiene largas pausas de compilación, porque cada unidad compilada es muy pequeña (es muy raro que recompile todo). El JPL de la NASA corrigió una vez un sistema Lisp en ejecución en una sonda a cientos de miles de kilómetros de distancia en el espacio.
Para dicho sistema, es muy natural tener información de tipo disponible en tiempo de ejecución (eso es lo que significa tipado dinámico). Por supuesto, nada le impide realizar inferencias de tipo y verificaciones de tipos en tiempo de compilación. Estos conceptos son ortogonales. Las implementaciones modernas de Lisp generalmente pueden hacer ambas cosas.
Bueno, antes que nada, Clojure es un Lisp y los Lisps tradicionalmente siempre han sido tipificados dinámicamente.
En segundo lugar, como el extracto que citó, dijo que Clojure es un lenguaje dinámico. Esto significa, entre otras cosas, que puede definir nuevas funciones en tiempo de ejecución, evaluar código arbitrario en tiempo de ejecución, etc. Todas estas cosas son difíciles o imposibles de hacer en lenguajes tipados estáticamente (sin yesos enyesados por todos lados).
Otra razón es que las macros pueden complicar inmensamente los errores de tipo de depuración. Imagino que la generación de mensajes de error significativos para los errores de tipo producidos por el código macrogenerado sería una gran tarea para el compilador.
Clojure es un Lisp con su macro sistema y su filosofía de código como datos , y esta filosofía difícilmente se lleva bien con el sistema de tipo estático. Por ejemplo, ¿cuál será el tipo de dicha lista ?
(defn square [x] (* x x))
?
Sin embargo, si necesita tipeo estático, Clojure lo permite con sugerencias de tipo .
Estoy de acuerdo, un lenguaje puramente funcional aún puede tener un ciclo de lectura-evaluación-impresión interactivo, y sería más fácil con la inferencia de tipo. Supongo que Clojure quería atraer a los programadores de lisp al ser "lisp para el JVM", y optó por ser dinámico como otros ceceos. Otro factor es que los sistemas de tipo deben diseñarse como el primer paso del lenguaje, y es más rápido para los implementadores del lenguaje omitir ese paso.
porque eso es lo que el mundo / mercado necesitaba. no tiene sentido construir lo que ya está construido.
he oído que la JVM ya tiene un lenguaje estáticamente tipado;)