Implémentation de l'interpréteur MSH. Je veux présenter au grand public l'interprète du nouveau langage de programmation MSH. J'ai déjà écrit des articles sur lui sur Habr. Le dernier est l'
interpréteur MSH . Cet article contient des liens vers des articles précédents sur ce sujet.
En fait, le public local est plutôt sceptique quant à cette créativité. Mais c'est injuste. Un langage de programmation réussi peut faire progresser considérablement l'ensemble de l'industrie informatique. Réduire l'effort de développement. J'ai repris le développement de ma langue pour ne pas satisfaire mes propres ambitions. Je crois qu'il n'y a pas de langage de programmation réussi. Et c'est extrêmement nécessaire. De plus, il n'y a pas de langue, mais il y a une idéologie de la langue. Cette idéologie est contenue dans le langage MUMPS. Mais en tant que langage de programmation, il n'existe pas. Il n'est utilisé que comme langage de base de données, ce qui limite considérablement la portée de son application. Cette situation, à mon avis, s'est développée en raison de l'intérêt personnel des développeurs de bases de données et du manque de compréhension du potentiel de ce langage par tout le monde. MUMPS existe maintenant en tant que norme de 1995. Bien sûr, sous cette forme, il est dépassé depuis longtemps. De nouveaux concepts de programmation sont apparus qui doivent avoir un langage moderne. J'ai entrepris de développer un tel langage. Dans ce cas, il fallait maintenir l'idéologie de MUMPS. Et l'idéologie est l'unité du code et des données. Le langage est basé non seulement sur les données, mais sur la structure des données. Et c'est une structure assez puissante. Ceci est un arbre. Toutes les autres structures sont modélisées sur la base d'un arbre. Dans un cas dégénéré, un arbre peut être composé d'un sommet. En fait, la ligne entre le code et les données est plutôt éphémère. L
La logique du programme peut être placée à la fois dans le code et dans les données. Et où tracer la ligne entre le code et les données dépend du programmeur. J'ai essayé de mettre toute la logique du programme dans les données. Et le programme a simplement fait le tour de l'arborescence des données et y a exécuté les commandes. Le code, bien sûr, n'a pas disparu, mais la structure du programme était en dehors du programme principal. La flexibilité d'un tel programme était élevée, mais comprendre un tel programme était tout simplement impossible. Le code et les données constituent donc l'unité. De plus, la structure des données est primordiale par rapport au contenu des données. La séparation en un langage de programmation et une base de données n'est pas naturelle.
Lors de la conception de systèmes d'information, les programmes manipulent principalement les structures de données plutôt que le contenu. Le contenu ne devient significatif qu'au moment des opérations arithmétiques. La nature secondaire du contenu suggère qu'il n'y a pas besoin de types de données. Les types de données sont générés par l'architecture informatique et l'imperfection des traducteurs. Les types de données n'ont rien à voir avec la signification significative des systèmes d'information. Il est clair que cela simplifie les compilateurs et les IDE, mais tout cela est secondaire. Les problèmes qui génèrent des types de données l'emportent largement sur les avantages qu'ils offrent. Cela ne signifie pas que vous n'avez pas besoin de contrôler le contenu des données. Mais cela ne devrait être fait qu'au moment de la réception des données de l'extérieur. Et les types de variables ne donnent pas d'aide à ce sujet. La variété du contenu des données dépasse de loin les types de base des langages de programmation. Il peut s'agir non seulement de nombres, mais également de chaînes de différents types. Et les nombres peuvent avoir diverses restrictions. Dans tous les cas, il est nécessaire de vérifier l'exactitude des données d'entrée. Les types de base ont donc très peu de relations avec le contenu des données.
Le langage moderne devrait prendre en charge la POO. En raison de l'absence d'une partie déclarative dans la langue, j'ai dû me limiter à une partie seulement de l'implémentation de la description de classe. Mais le langage n'impose pas de style de programmation. Voulez-vous utiliser des objets, ne voulez pas ne pas utiliser. La gestion des événements est largement utilisée dans Assembler. DOS a été construit sur la gestion des événements. Dans les langues de haut niveau, je ne connais pas de cas d'utilisation de cette technique. Bien qu'elle ait un fort potentiel. L'absence de traitement des événements dans le langage oblige les programmes à utiliser différents cycles de traitement des messages. Une solution plutôt maladroite qui pose beaucoup de problèmes lorsque vous essayez d'effectuer une sorte de traitement à l'intérieur de la boucle. Le traitement parallèle des tâches est déjà utilisé partout, mais dans de nombreuses langues, il n'est pas pris en charge au niveau linguistique. Cela rend les programmes dépendants du système d'exploitation et de sa version. Les pertes d'une telle décision sont évidentes à mon avis.
C'est l'idéologie sur laquelle le langage MSH est construit.
- L'unité du code et des structures de données, ce qui signifie que le langage a une structure de données puissante.
- L'absence de types de données et, par conséquent, leur déclaration.
- L'inclusion de techniques de programmation modernes dans le langage. Dans MSH, ce sont les objets, la gestion des événements et l'exécution parallèle des tâches.
Quiconque s'intéresse à cette langue peut en prendre connaissance sur github .
Il est présenté le code source et un exemple de travail. Le travail sur la langue vient de commencer et ce n'est pas un produit fini. Mais je pense que vous pouvez vous faire une idée de la langue. Le langage a été développé sous Linux x64.