Intérprete de MSH

Les traigo a mi atención mi visión de un lenguaje ideal. En mis artículos anteriores, ya expuse mi idea del lenguaje ideal De MUMPS a MSH Características y diferencias del lenguaje de programación MSH de MUMPS .

Las críticas fueron en su mayoría negativas. Después de leer las reseñas, me sorprendió descubrir que todo en el mundo de los lenguajes de programación ya es muy perfecto. Pero las vagas sospechas me corroen que todo no es tan bueno en este mundo. Por supuesto, ya hay muchos idiomas, pero no se observa una variedad de conceptos lingüísticos.

Si descartamos los pequeños adornos de los idiomas, entonces hay varios de estos conceptos.

• Programación de objetos
• Gestión de datos, mecanografía.
• Pasar un número variable de parámetros a procedimientos y funciones.
• Gestión del proceso de ejecución.

De la solución de estos problemas se suman las propiedades de un lenguaje de programación.

Programación de objetos

En mi opinión, este es un concepto importante y debe estar presente en el idioma. Por supuesto, incluso si el lenguaje no tiene clases y objetos, entonces nada le impide pensar y escribir programas en el estilo de objeto, pero aún así, la presencia de tales mecanismos hace posible simplificar esta tarea.

Gestión de datos, mecanografía

Considero que esta sección es la más importante en el concepto de lenguaje. Conocí muchas discusiones sobre este tema en Habré. Principalmente abogó por la tipificación estática y dinámica. Para la escritura dinámica, la ventaja se llamaba flexibilidad del lenguaje, pero la desventaja es supuestamente la falta de confiabilidad del lenguaje y la poca adaptabilidad a los entornos de desarrollo. En la escritura estática, todo es exactamente lo contrario. Considero que los argumentos sobre la mejor confiabilidad de los lenguajes con escritura estática son absurdos, es posible que la escritura estática ayude en el desarrollo de herramientas de programación, pero nada más. No soy partidario de ninguno de los enfoques. Considero que escribir como tal es el mal principal de los lenguajes de programación modernos. Aunque está presente en la gran mayoría de los lenguajes de programación. El lenguaje debe hacerse cargo de toda la gestión de datos, incluida la comprensión de sus tipos. Lo cual es bastante real. Y el programador debe lidiar con la lógica del programa. Si necesita verificar los datos, escribir no será de ayuda. Solo deben verificarse el contenido. Puedo explicar la presencia de la tipificación solo por tradición e inercia del pensamiento.

Pasar un número variable de parámetros a procedimientos y funciones

Este es un problema menor, pero es difícil de resolver en la mayoría de los idiomas. Aunque existe un gran ejemplo en Assembler. Pasando parámetros a través de la pila. Solo necesita abandonar la lista de parámetros formales y pasar los parámetros a través de una lista. No me resulta del todo claro devolver un número variable de valores de función para qué y cómo usarlo. En cualquier caso, se debe devolver una entidad.

Gestión de procesos

Esta sección también considero crucial para el concepto de lenguaje. Las construcciones de control de los lenguajes son casi idénticas. Pequeños matices surgen usando el comando goto. No entiendo por qué están luchando contra este equipo con tanto frenesí. Un comando muy conveniente, especialmente si se puede calcular el argumento de este comando. En la implementación de la computación paralela, las variantes de la variante son principalmente 2. O se implementan mediante bibliotecas o se pueden incluir en el lenguaje mismo. Soy partidario del segundo método.

Los idiomas carecen de manejo de eventos. Aunque es ampliamente utilizado. Para construir una GUI, para implementar el procesamiento de eventos, se inicia el bucle principal. Esta solución no brilla con elegancia. Entrar en ese ciclo es otro problema. Un lenguaje normal debe tener una instalación de manejo de eventos.

Mis ideas son, por supuesto, subjetivas y quizás incluso incorrectas. Pero se basan en mi experiencia personal. Un sistema operativo moderno es un montón de basura que no se depura, que nunca se depurará. Pila de API, varias bibliotecas desde las cuales se transmiten errores. El número de lenguajes de programación ha excedido todos los límites posibles. Además, en principio difieren poco entre sí. Y, en general, no diré nada sobre la cantidad de marcos. Incluso el sistema promedio es una torta de múltiples capas de varios subsistemas, posiblemente poco compatibles, cuya depuración completa nunca se realizará. La depuración de un programa C simple puede llevar meses. Y todo esto en mi opinión se genera escribiendo en lenguajes de programación.

Por el momento, no existe un lenguaje que satisfaga mis ideas sobre el lenguaje de programación correcto. El más cercano a él en mi opinión es el lenguaje de programación MUMPS, pero no hay implementación de un lenguaje como el lenguaje de programación. Hay implementaciones de bases de datos en las que este lenguaje se usa como idioma. Las limitaciones de este enfoque son obvias, lo que me hizo desarrollar un nuevo lenguaje MSH y escribir su implementación como intérprete. Por el momento, no todo lo que voy a hacer está implementado en él. En particular, no existe un entorno de desarrollo, pero puede hacerse una idea del lenguaje.

La implementación está hecha para Linux x64.

Quien esté interesado en mi trabajo, escriba al correo, le enviaré la distribución.
PS.
MSH no es solo un lenguaje sin tipo, no es declarativo. En principio, no hay descripciones variables en él. En el caso general, una variable no solo tiene un tipo, sino también una estructura. Se requieren matrices, listas, HASH, pilas y una declaración para describir cada una de las estructuras. En MUMPS, no existen tales lenguajes de declaración en principio; cualquier variable es un árbol. No se reserva espacio para tal árbol. Se crea un nodo de árbol en el momento de escribir datos en él, y solo existen tales nodos en los que se realizó la grabación. No hay restricciones sobre el tipo de índice. Por lo tanto, comparar MUMPS con PHP, Java Script y otros lenguajes es incorrecto. MUMPS es un mundo separado, con sus propios problemas y ventajas. Para entenderlo, necesitas reconstruir el pensamiento. Es imposible entender MUMPS leyendo reseñas abusivas. Debemos sumergirnos en él. Lee la documentación. Instale el sistema MUMPS. Trabaja en ello. El hecho de que no me entiendan aquí es bastante natural. Estamos hablando de mundos diferentes. En el mundo de MUMPS no hay discusiones que estamos llevando a cabo aquí sobre tipos, estructuras. Pocos de los MUMPSistas están interesados ​​en cómo y dónde se almacenan sus datos. Cualquier dato en MUMPS siempre tiene dos representaciones: un número y una cadena. Y dependiendo de la operación, se toma esta o aquella representación. Siempre sé el resultado exacto dependiendo de la operación que apliqué. MUMPS obliga al programador a trabajar en términos de un árbol. Los árboles se pueden ubicar tanto en medios externos: globales (análogos de bases de datos) como en memoria: locales (análogos de variables en programas). Básicamente, cuando diseño un sistema de información, trabajo directamente con datos en un disco de datos locales intermedios, tengo un mínimo y no me crean ningún problema. Por lo tanto, en los foros MUMPS no encontrará discusiones sobre los tipos de variables de sus localizaciones. Un método de diseño típico es diseñar árboles de entrada, fines de semana. Y luego, según sea necesario, escribe programas para formar árboles de entrada y salida. Los datos en MUMPS son primarios y los programas son secundarios. Con mis artículos, pretendo presentar tantos programadores como sea posible a este otro mundo de MUMPS. Creo que este mundo es más correcto. Admiro este lenguaje simple, poderoso y elegante. Me da placer escribir sobre eso. Para mi profundo pesar, tengo poco que hacer. Quiero crear un idioma en el que todo se pueda escribir sin ir más allá de los límites de este idioma. Escriba un servidor, escriba un cliente de escritorio, agregue un idioma a los navegadores.