Dans quelle mesure un cadre de développement de langage devrait-il être facile à utiliser?

11

Cela fait partie d'une série de questions qui se concentre sur un projet appelé le projet d'abstraction, qui vise à résumer les concepts utilisés dans la conception de langage sous la forme d'un cadre.

Une autre page qui lui est associée concernant le typage structurel peut être consultée ici . Le méta-sujet associé à une enquête sur le cadre et le bon endroit pour publier peut être trouvé ici .

Dans quelle mesure devrait-il être facile d'utiliser un framework de développement de langage?

J'ai écrit des cadres de génération de code à grande échelle qui comprenaient également la possibilité d'envoyer le résultat au compilateur spécifique au langage. Le sujet de la facilité d'utilisation provient d'un exemple de cadre de ce type: CodeDOM ou le modèle d'objet de document de code.

Il s'agit d'un framework écrit par Microsoft qui décrit des structures de code communes, mais généralement omis (coercitions d'expression) et avait tendance à être un peu abstrait dans sa représentation de certaines constructions, à émettre carrément du mauvais code en fonction de ce que vous faisiez: plus tôt CodeDOM mal traité émettant PrivateImplementationTypesur CodeMemberMethod, lorsque le type utilisé était une interface générique. CodeDOM était ma raison d'origine pour écrire mon premier générateur de code.

Une chose que j'essaie de faire, pour simplifier le cadre, est de réduire la quantité de travail dont vous avez besoin pour faire quelque chose, et de vous concentrer sur les actions par rapport aux types spécifiques qui composent ces actions.

Voici une comparaison côte à côte du fonctionnement du framework que j'écris:

//Truncated...
/* *
 * From a project that generates a lexer, this is the 
 * state->state transition character range selection logic.
 * */
var nextChar = nextMethod.Parameters.Add(new TypedName("currentChar", typeof(char).GetTypeReference()));
//...
char start = rangeElement.B.Value.Start;
char end = rangeElement.B.Value.End;
/* *
 * 'start' <= nextChar && nextChar <= 'end'
 * */
currentExpression = start.LessThanOrEqualTo(nextChar).LogicalAnd(nextChar.LessThanOrEqualTo(end));

Versus CodeDOM:

//Truncated...
var nextChar = new CodeVariableReferenceExpression("nextChar");
//...
var start = new CodePrimitiveExpression(rangeElement.B.Value.Start);
var end = new CodePrimitiveExpression(rangeElement.B.Value.End);
currentExpression = new CodeBinaryOperatorExpression(new CodeBinaryOperatorExpression(start, CodeBinaryOperatorType.LessThanOrEqual, nextChar), CodeBinaryOperatorType.BooleanAnd, new CodeBinaryOperatorExpression(nextChar, CodeBinaryOperatorType.LessThanOrEqual, end));

L'objectif du cadre est les passionnés de langage, ainsi que ceux intéressés par la génération de code ou d'applications. Compte tenu de son accent sur la compilation, la génération de code et le développement du langage, le cadre devrait-il se concentrer sur la facilité d'utilisation ou la puissance brute?

Mon objectif principal est d'augmenter la disponibilité de ces outils, afin que ceux qui s'intéressent au domaine n'aient pas besoin de beaucoup d'expérience dans le domaine de la théorie des langues avant de pouvoir commencer à travailler sur leurs propres projets axés sur les langues.

Étant donné que je suis l'auteur du cadre, ma vision de "l'utilisabilité" est biaisée. Ainsi, je dois demander à un autre si la focalisation et l'objectif ont du sens pour ceux qui ne sont pas associés au projet.

Allen Clark Copeland Jr
la source
1
Vous devriez poser cette question sur codereview.stackexchange.com .
Robert Harvey
6
La question de savoir si un framework doit être facile à utiliser au détriment de la puissance brute ne semble pas du tout être adaptée à Code Review.SE, où «l'architecture de niveau supérieur et la conception de systèmes logiciels» n'est pas en cours. sujet là-bas, et est sur le sujet ici. La révision de code est pour quand vous avez du code de travail et que vous voulez une critique.
L'entrée d'un générateur de code n'est qu'un autre langage de programmation. Le désir de génération de code signifie que le langage que vous générez est insuffisamment puissant. De meilleurs langages ont des générateurs de code intégrés.
kevin cline le
@kevincline Le cas d'utilisation typique d'un générateur de code est un langage spécifique à un domaine qui utilise un cadre de génération de code à usage général. Ce n'est pas vraiment un choix, l'alternative serait de compiler dans votre propre langage intermédiaire interne et de l'interpréter via une machine virtuelle, ou de le traduire vous-même dans une construction de niveau inférieur, mais à la fin vous faites la même chose . C'est ce que ce cadre vise à faire, lorsque vous devez faire le travail pour générer du code de manière dynamique, vous utiliseriez cela plutôt que de créer votre propre implémentation de la même chose.
Allen Clark Copeland Jr
Ce n'est pas tant que la langue source est insuffisante, c'est qu'une grammaire linguistique n'est que du texte jusqu'à ce qu'un logiciel intermédiaire soit écrit pour traduire du texte source vers la plate-forme cible. Dans ce cas, c'est la Common Language Infrastructure (CLI) ou le code dans les langages à usage général qui cible la CLI. Le cadre vise à gérer le travail de grognement de prendre des représentations de haut niveau et de les traduire en constructions suffisamment bas pour la génération d'IL. c'est-à-dire un compilateur, ce n'est pas parce que vous avez besoin d'un compilateur que votre langue n'est pas suffisamment puissante. C'est requis.
Allen Clark Copeland Jr

Réponses:

2

Il est difficile de construire un cadre de développement de langage. Vous devez décider quels types de choses vous aimeriez qu'il soutienne, puis vous devez décider lesquelles de celles que vous savez comment faire et comment les intégrer ensemble dans un ensemble cohérent. Enfin, vous avez suffisamment investi pour que cela fonctionne avec de vrais langages (par exemple, des langages informatiques typiques ainsi que des DSL), et fait réellement quelque chose d'utile. Je vous laisse mon chapeau pour avoir essayé.

Vous pourriez comparer votre effort avec celui que j'ai commencé il y a 15 ans, le DMS Software Reengineering Toolkit . Le DMS est destiné à fournir une analyse, une analyse et une transformation générales du code. Étant donné une spécification de langage explicite, il analysera le code, construira les AST, régénérera le code à partir des AST (prettyprint), transformera le code en utilisant des modèles écrits dans le langage de programmation ciblé, construira des tables de symboles, contrôlera le calcul et le flux de données, etc. En ajoutant du code personnalisé, on fait en sorte que le DMS emporte une grande variété d'effets. (Voir les outils sur le site; ils sont tous DMS sous une forme ou une autre).

Voici un document technique sur le DMS tel qu'il était il y a plusieurs années. (Nous continuons de l'améliorer)

Bien que DMS lui-même ait été difficile à construire, nous avons constaté qu'il a fallu un gros morceau d'ingénierie correspondant pour définir de véritables langages pour DMS, y compris IBM COBOL, C # 4.0, Java 1.7, C ++ 11 (et bien d'autres).

Ce que nous pensons qu'il fait (raisonnablement bien): réduire le coût de construction des outils de 1 à 2 ordres de grandeur. Cela signifie que des tâches qui pourraient autrement prendre de 1 à 10 ans peuvent être envisagées par de simples mortels comme des projets d'un mois à un an. Ce qui n'est toujours pas facile:

  • Définir de nouveaux langages
  • Gérer toutes les idioties des langues actuelles
  • Faciliter l'écriture du code personnalisé spécifique à votre tâche
  • Définir de nouvelles analyses complexes
  • Gestion des programmes partiels ou des programmes contenant des erreurs
  • (À votre point de départ) Facilitez l'utilisation de ces outils par des non-experts

Il y a donc beaucoup de place à l'amélioration. Laissez fleurir de nombreuses fleurs.

Ira Baxter
la source
0

Il a peut-être été répondu à cette question dans Le Mois de l'homme mythique, section «Intégrité conceptuelle». Sinon, c'est au moins très pertinent pour votre question. Même si Brooks décrit l'architecture d'un système informatique complet, l'essai s'applique parfaitement aux frameworks et aux nouveaux langages.

Je crois qu'il existe une corrélation positive entre le taux d'adoption de toute technologie et son intégrité conceptuelle et sa facilité d'utilisation. Il devrait y avoir une étude de cas de technologies récentes comme les langages, les frameworks et les OS, pour prouver cette corrélation, mais n'en connait pas encore.

maxpolk
la source
Mon seul problème avec cette réponse est qu'elle ne fournit aucune valeur réelle. Est-ce que les références sont une section d'un livre et à partir de votre description ne seraient applicables qu'une fois le progiciel publié. Il ne me donne pas de réponse avant la sortie, car il dit essentiellement "cela fonctionnera bien s'il est facile à utiliser et pertinent pour le domaine". Je ne peux pas dire à quel point cela fonctionnera, car ce n'est pas encore au point où vous pouvez l'utiliser. Le truc avec les compilateurs, c'est que vous faites beaucoup, beaucoup de travail, seulement pour réaliser que vous n'êtes qu'à mi-chemin de la montagne, et c'est la partie facile.
Allen Clark Copeland Jr