Interprète MSH

J'attire votre attention sur ma vision d'une langue idéale. Dans mes articles précédents, j'ai déjà exposé mon idée du langage idéal De MUMPS à MSH Caractéristiques et différences du langage de programmation MSH de MUMPS .

Les critiques étaient pour la plupart négatives. Après avoir lu les critiques, j'ai été surpris de constater que tout dans le monde des langages de programmation est déjà très parfait. Mais de vagues soupçons me rongent que tout n'est pas si bon dans ce monde. Bien sûr, il y a déjà beaucoup de langues, mais une variété de concepts linguistiques n'est pas observée.

Si nous rejetons les embellissements mineurs des langues, il existe plusieurs de ces concepts.

• Programmation d'objets
• Gestion des données, dactylographie.
• Passer un nombre variable de paramètres aux procédures et fonctions.
• Gestion du processus d'exécution.

De la solution de ces problèmes s'ajoutent les propriétés d'un langage de programmation.

Programmation d'objets

À mon avis, c'est un concept important et il doit être présent dans la langue. Bien sûr, même si le langage n'a pas de classes et d'objets, rien ne vous empêche de penser et d'écrire des programmes dans le style objet, mais quand même, la présence de tels mécanismes permet de simplifier cette tâche.

Gestion des données, saisie

Je considère que cette section est la plus importante du concept de langage. J'ai rencontré beaucoup de discussions à ce sujet sur Habré. Principalement argumenté pour le typage statique et dynamique. En typage dynamique, l'avantage a été appelé la flexibilité du langage, mais l'inconvénient est censé être le manque de fiabilité du langage et la mauvaise adaptabilité aux environnements de développement. En typage statique, tout est exactement le contraire. Je considère les arguments sur la meilleure fiabilité des langages avec le typage statique comme absurdes, il est possible que le typage statique aide au développement d'outils de programmation, mais rien de plus. Je ne suis partisan d'aucune de ces approches. Je considère que taper comme tel le principal mal des langages de programmation modernes. Bien qu'il soit présent dans la grande majorité des langages de programmation. Le langage doit prendre complètement en charge toute la gestion des données, y compris la compréhension de ses types. Ce qui est bien réel. Et le programmeur doit gérer la logique du programme. Si vous devez vérifier les données, la saisie n'aidera pas. Il suffit de vérifier leur contenu. Je ne peux expliquer la présence de la typification que par la tradition et l'inertie de la pensée.

Passer un nombre variable de paramètres aux procédures et fonctions

Il s'agit d'un problème mineur, mais il est difficile à résoudre par la plupart des langues. Bien qu'un excellent exemple existe dans Assembler. Passer des paramètres à travers la pile. Vous avez juste besoin d'abandonner la liste des paramètres formels et de passer les paramètres à travers une liste. Il n'est pas tout à fait clair pour moi de renvoyer un nombre variable de valeurs de fonction pour quoi et comment l'utiliser. Dans tous les cas, une entité doit être retournée.

Gestion des processus

Cette section que je considère également comme cruciale pour le concept de langage. Les constructions de contrôle des langages sont presque identiques. De petites nuances apparaissent à l'aide de la commande goto. Je ne comprends pas pourquoi ils combattent cette équipe avec une telle frénésie. Une commande très pratique, surtout si l'argument de cette commande peut être calculé. Dans l'implémentation du calcul parallèle, les variantes de la variante sont principalement 2. Soit elles sont implémentées au moyen de bibliothèques, soit elles peuvent être incluses dans le langage lui-même. Je suis partisan de la deuxième méthode.

Les langues manquent de gestion des événements. Bien qu'il soit largement utilisé. Pour construire une interface graphique, pour implémenter le traitement des événements, la boucle principale est lancée. Cette solution ne brille pas avec élégance. Entrer dans un tel cycle est un autre problème. Une langue normale devrait avoir une fonction de gestion des événements.

Mes idées sont bien sûr subjectives, et peut-être même incorrectes. Mais ils sont basés sur mon expérience personnelle. Un système d'exploitation moderne est un tas de fichiers indésirables qui ne sont pas débogués, qui ne seront jamais débogués. Pile d'API, diverses bibliothèques à partir desquelles les erreurs sont diffusées. Le nombre de langages de programmation a dépassé toutes les limites possibles. De plus, en principe, ils diffèrent peu les uns des autres. Et en général, je ne dirai rien sur le nombre de cadres. Tout système, même moyen, est un gâteau multicouche provenant de divers sous-systèmes, éventuellement mal compatibles, dont le débogage complet ne sera jamais effectué. Le débogage d'un simple programme C peut prendre des mois. Et tout cela à mon avis est généré en tapant dans des langages de programmation.

Pour le moment, aucun langage ne correspond à mes idées sur le langage de programmation correct. Le plus proche à mon avis est le langage de programmation MUMPS, mais il n'y a pas d'implémentation d'un tel langage comme langage de programmation. Il existe des implémentations de bases de données dans lesquelles ce langage est utilisé comme langage. Les limites de cette approche sont évidentes, ce qui m'a fait développer un nouveau langage MSH et écrire son implémentation en tant qu'interprète. Pour le moment, tout ce que je vais faire n'y est pas mis en œuvre. En particulier, il n'y a pas d'environnement de développement, mais vous pouvez vous faire une idée du langage.

L'implémentation est faite pour Linux x64.

Qui s'intéresse à mon travail, écrivez à la poste, j'enverrai la distribution.
PS.
MSH n'est pas seulement un langage sans type, il est non déclaratif. En principe, il ne contient aucune description de variable. Dans le cas général, une variable a non seulement un type, mais aussi une structure. Des tableaux, des listes, des HASH, des piles et une déclaration sont nécessaires pour décrire chacune des structures. Dans MUMPS, il n'y a pas de tels langages de déclaration en principe; toute variable est un arbre. Aucun espace pour un tel arbre n'est réservé. Un nœud d'arbre est créé au moment de l'écriture des données, et seuls ces nœuds existent dans lesquels l'enregistrement a été effectué. Il n'y a aucune restriction sur le type d'index. Par conséquent, la comparaison de MUMPS avec PHP, Java Script et d'autres langages est incorrecte. MUMPS est un monde séparé, avec ses propres problèmes et avantages. Pour le comprendre, vous devez reconstruire la pensée. Il est impossible de comprendre MUMPS en lisant des critiques abusives. Nous devons nous y plonger. Lisez la documentation. Installez le système MUMPS. Travaillez dessus. Le fait qu'ils ne me comprennent pas ici est tout à fait naturel. Nous parlons de différents mondes. Dans le monde de MUMPS, il n'y a aucune discussion que nous menons ici sur les types, les structures. Peu de MUMPSists sont intéressés par comment et où leurs données sont stockées. Toutes les données dans MUMPS ont toujours deux représentations: un nombre et une chaîne. Et selon l'opération, telle ou telle représentation est prise. Je connais toujours le résultat exact en fonction de l'opération que j'ai appliquée. MUMPS force le programmeur à travailler en termes d'arbre. Les arbres peuvent être localisés à la fois sur des supports externes: globaux (analogiques des bases de données), et en mémoire: locaux (analogiques des variables dans les programmes). En gros, lors de la conception d'un système d'information, je travaille directement avec des données sur un disque de données locales intermédiaires, j'ai un minimum et elles ne me posent aucun problème. Par conséquent, sur les forums MUMPS, vous ne trouverez pas de discussions sur les types de variables de leurs localisations. Une méthode de conception typique consiste à concevoir des arbres d'entrée, le week-end. Et puis, si nécessaire, vous écrivez des programmes pour former des arborescences d'entrée et de sortie. Les données dans MUMPS sont primaires et les programmes sont secondaires. Avec mes articles, je vise à introduire le plus de programmeurs possible dans cet autre monde de MUMPS. Je pense que ce monde est plus correct. J'admire ces langages simples, puissants et élégants. Cela me fait plaisir d'écrire dessus. À mon grand regret, j'ai peu à faire. Je veux créer une langue dans laquelle tout peut être écrit sans dépasser les limites de cette langue. Écrivez un serveur, écrivez un client de bureau, ajoutez une langue aux navigateurs.