¿Los lenguajes dinámicos eliminarán los lenguajes estáticos?
El propósito de mi escrito es discutir la necesidad de un control de calidad en el uso de lenguajes dinámicos y la controversia resultante sobre la rentabilidad. Esto no significa que los lenguajes dinámicos sean completamente superiores a los lenguajes estáticos, ni que los lenguajes estáticos serán completamente reemplazados por lenguajes dinámicos. Además, permítanme hablar brevemente sobre la relativa superioridad y significado del lenguaje estático que experimento.
En primer lugar, quiero expresar mi opinión constante de que las computadoras no hacen magia. En concreto, hay dos aspectos. En primer lugar, cuanto más cerca esté de la máquina, más probabilidades tendrá de lograr un rendimiento más rápido; en segundo lugar, los modelos de máquinas actuales siempre gestionan los datos de forma lineal (vale la pena quejarse de que, además del sistema operativo, los sistemas de partición de archivos siempre hacen esto). hacer, y si la capa inferior se puede ubicar y acceder directamente en el espacio 2D/3D en coordenadas polares, en lugar de en forma de sectores, cilindros y grupos, no lo sé y necesitaré orientación experta).
El papel de la gestión lineal de la información es que las herramientas de programación basadas en estructuras de datos lineales o de acceso a la información a través de direcciones suelen ser más rápidas que las basadas en estructuras de diccionario, al menos con mayor margen de optimización. Para los lenguajes estáticos, hemos determinado la estructura y el tamaño del objeto en el momento de la compilación (el contenido de tamaño dinámico se puede administrar a través de referencias), lo cual no es posible para los lenguajes dinámicos. La estructura de objetos de los lenguajes dinámicos siempre se basa en la estructura del diccionario y se debe considerar el problema de los cambios en la estructura de los objetos en tiempo de ejecución. Esto lo convierte siempre en un nivel más de gestión de datos que el acceso directo a la dirección. Esta es la razón por la que rara vez se ven compiladores de lenguajes dinámicos. Casi todos los lenguajes dinámicos populares son plataformas interpretadas/de código de bytes, e incluso los lenguajes más comunes como Python/Ruby tienen el tan criticado GIL (Global Interpreter Lock). Según la experiencia de la comunidad Python, el rendimiento de un solo núcleo de varias implementaciones de C-Python sin GIL que han estado disponibles durante muchos años no es tan bueno como el de la versión oficial actual. Jython y IronPython se benefician de JVM y CLR, dos plataformas de máquinas virtuales probadas. Sus lenguajes de primer nivel son lenguajes compilados estáticamente (aunque sus compiladores principales generan código de bytes, generalmente nos referimos a Java y C# como lenguajes compilados). Perl6, que la comunidad Perl ha estado esperando durante muchos años, aún no se ha lanzado (aunque se lanzó su máquina virtual Parrot, no se ha verificado en la práctica debido al progreso de la implementación del lenguaje principal). Es obvio que es difícil lograr un entorno de alto rendimiento para lenguajes dinámicos, especialmente un entorno paralelo.
Básicamente hablando, en el modelo de hardware actual, es muy difícil gestionar la información de forma no lineal, expandirse y contraerse dinámicamente y modificar dinámicamente la estructura. Por ejemplo, el Sr. Hou Jie dio una conferencia utilizando Windows 95 como ejemplo para explicar en detalle la implementación subyacente de malloc/free. Los amigos que hayan oído hablar de él deberían comprender la complejidad de la gestión dinámica de los recursos de memoria del sistema operativo. Se introduce contenido similar en muchos libros técnicos, como los sistemas operativos. Los amigos que estén interesados pueden buscarlo. Tengo a mano un libro "Programación del sistema Unix", que contiene contenido relevante.
Este tipo de problema implica cuestiones profundamente arraigadas. No soy un profesional, soy un lego en esto. No soy muy bueno hablando, pero los amigos interesados pueden profundizar más y descubrir que en realidad es mucho más problemático de lo que parece. Es todo un desafío lograr un rendimiento estático en lenguajes dinámicos. El protocolo de búfer de protocolo de Google también se basa en un modelo estático.
Los lenguajes estáticos modernos están bien disfrazados, por lo que se pueden escribir de forma muy dinámica, como C#3, Scala, etc. , pero esencialmente los tipos involucrados en su código aún se pueden determinar en el momento de la compilación. De los lenguajes con los que me he encontrado, Haskell tiene la historia más larga de este tipo de funciones, derivando tipos a través de un sistema matemático muy estricto. En este proceso, los programadores aún necesitan declarar explícitamente el tipo de función antes de la compilación.
Los lenguajes estáticos son cada vez más amigables y ágiles, y los lenguajes dinámicos son cada vez más rápidos, pero la frontera entre ambos sigue siendo bastante clara. Los lenguajes estáticos son más rápidos y tienen más optimización. potencial. Los lenguajes dinámicos son más flexibles y tienen capacidades expresivas más fuertes. Ésta es la razón fundamental por la que ambos no pueden reemplazarse.
Por supuesto, el problema del rendimiento no es simple. Los lenguajes dinámicos a menudo no son tan lentos como los resultados de las pruebas.
Esto se debe a que expresar una lógica empresarial compleja a menudo requiere estructuras de datos y códigos de acceso complejos, y estos contenidos de datos complejos cambian constantemente a medida que los usuarios acceden a ellos. Para lograr todo esto, si utilizas un lenguaje estático, debes prestar atención a la implementación de estructuras de datos dinámicas. Si utiliza tecnología de desarrollo sin GC, también debe prestar atención al reciclaje de recursos de memoria. De hecho, habrá grandes desvíos y el sistema resultante no será tan rápido como un lenguaje dinámico ya preparado (aunque esto no es universal). Es más, en realidad, las interfaces de E/S siempre son lineales en lectura y escritura, lo que hace que las diferencias de rendimiento entre diferentes idiomas sean aún más graves. Por lo tanto, la forma más reconocida de implementación de proyectos ahora es utilizar lenguaje dinámico para implementar el proyecto. Luego, si hay demanda y carga de costos, se usa lenguaje estático para optimizar el cuello de botella en el rendimiento.
Por supuesto, el modelo anterior se utiliza a menudo en proyectos basados en servidor. En un entorno GUI, se requieren interacciones frecuentes con entornos de interacción persona-computadora, como monitores, ratones y teclados, lo que consume muchos recursos. Además, en una era en la que los lenguajes estáticos como CPP son populares, el desarrollo de GUI ha sido bastante maduro y, debido a razones históricas de acumulación de poder técnico, los lenguajes estáticos y compilados siguen siendo la fuerza principal en este campo. Como máximo, puede presentar capacidades de desarrollo secundarias, proporcionar una interfaz para llamadas de idiomas dinámicas o incorporar un entorno de interpretación para uso limitado. De hecho, incluso en un entorno de servidor, con el desarrollo de Internet, los problemas de rendimiento se han vuelto cada vez más prominentes. Encontré una función lógica simple que no se podía optimizar al nivel ideal usando Python. Finalmente, escribí un módulo nginx usando Objective C. Por otro lado, lenguajes como Objective C son bastante dinámicos y usar su estructura de diccionario lo es. más C es mucho más conveniente y es completamente compatible binariamente con C. En términos de rendimiento y espacio, se puede observar claramente que cuesta más rendimiento que la mayoría de las estructuras de diccionarios en C. Las computadoras no tienen poderes mágicos y la gente siempre tiene que gastar algunos recursos informáticos para ganar comodidad. Acercarlo lo más posible al ideal es el objetivo del técnico.
Cada vez más arquitecturas a gran escala requieren que pensemos no solo en términos de módulos, bibliotecas de conexión e interfaces de funciones, sino también en términos de tiempo de ejecución real, instancias en ejecución y comportamiento del servidor. No sólo necesitamos un entorno de ejecución bien equipado, sino que también necesitamos herramientas rápidas y eficientes con acceso directo al hardware. Incluir el desarrollo de algunos entornos de servicios personalizados menos dinámicos pero más rápidos se ha convertido en un requisito cada vez más común.
Aunque los lenguajes de programación se están desarrollando y la forma en que expresamos nuestras ideas es cada vez más poderosa, constantemente surgen nuevos desafíos a medida que la cantidad de usuarios, los modelos de negocio y los métodos de servicio cambian rápidamente. Para los equipos profesionales de desarrollo de TI, enfrentamos más desafíos. Necesitamos una cartera de tecnologías más rica, y sigue siendo un lujo esperar que una tecnología domine el mundo, incluso si se limita a las aplicaciones de Internet. El auge de los lenguajes dinámicos en los últimos diez años es en realidad una lección para compensar la falta de expresión lógica en el pasado. Este es un beneficio limitado que aporta el desarrollo de hardware, pero los recursos de hardware siempre se desarrollan rápidamente pero no se utilizan por completo. La combinación de lenguaje dinámico y lenguaje estático, teniendo en cuenta los efectos de un desarrollo eficiente y un alto rendimiento, sigue siendo una idea práctica en el futuro previsible.