Quand est-il raisonnable de créer mon propre langage de programmation?

Existe-t-il des types d'applications destructrices, des classes de problèmes algorithmiques, etc., où il est préférable, à long terme, de créer mon propre langage?

PS: Juste pour être sûr, je veux dire un nouveau langage de programmation et un compilateur, pas un nouveau compilateur pour un langage existant.

EDIT : Merci pour les réponses. Pouvez-vous donner quelques exemples, où il est absolument inutile de créer un DSL ou des cas dans lesquels un DSL pourrait être une bonne idée?

Il est certainement pertinent pour une personne d’écrire sa propre langue à des fins éducatives. Pour en savoir plus sur la conception du langage de programmation et sur la conception du compilateur. Mais les utilisations dans le monde réel sont rares.

En écrivant votre propre langue, vous êtes:

• Ajoutant une énorme quantité de complexité à votre problème
• Ajouter une quantité importante de travail pour écrire et maintenir le nouveau langage et le nouveau compilateur

Ainsi, si vous envisagez d'écrire votre propre langue pour votre projet, les fonctionnalités fournies par cette dernière ne nécessitent pas de compensation des coûts susmentionnés.

Prenez le développement de jeux par exemple. Ils ont souvent besoin de mini-langages au sein de leurs jeux ou langages de script. Ils utilisent ces langages pour écrire une grande quantité d’événements dans le jeu. Cependant, même dans ce cas, ils choisissent presque toujours des langages de script existants et les adaptent à leurs besoins.

Permettez-moi de citer Paul Vick, ancien développeur en chef du compilateur VB et travaillant actuellement sur Project Oslo et le langage M:

C'est incroyablement difficile et incroyablement difficile de créer un nouveau langage, même basé sur un langage existant. Pourtant, de nombreux programmeurs se disent: «Hé, j’utilise des langages, cela peut-il être si difficile?» Et y aller. … Probablement plus de 98% d'entre eux ne parviennent jamais à gagner du terrain, mais que Dieu bénisse les optimistes car sans eux, nous n'aurions jamais les 2% de langues qui réussissent. Personnellement, je suis disposé à sacrifier les millions de dollars et les heures perdues en langages qui ne le font jamais pour que nous puissions avoir des langages comme C # et Java, Ruby et Python, etc.

Donc, le fait de proposer une nouvelle langue est une mauvaise idée ne devrait pas dissuader les gens de développer de nouveaux DSL, cela devrait simplement leur donner une pause et, espérons-le, un peu d'humilité. Je pense que la clé est de commencer petit et de rester petit.

DSLs: Certainement une mauvaise idée!

Quand est-ce raisonnable?

Quand vous en avez envie!

N'écoutez pas ces gens qui ont des commentaires sournois qui disent en gros:

"Ne le faites pas parce que c'est trop dur et que le langage X est meilleur que n'importe quel langage que vous pouvez inventer".

Le fait est que la création d’un DSL se produit tout le temps. Un framework est un DSL. Une macro est une DSL. Chaque fois que vous écrivez une fonction pour votre programme, cela fait partie d'un DSL. Bien sûr, c'est dans les limites de la grammaire, mais le vocabulaire fait partie d'un langage. C'est pourquoi les industries créent souvent leur propre langage: c'est plus efficace!

Si "ne le fais pas" était la bonne réponse, nous écririons tous en COBOL et Fortran.

Vous voudrez peut-être lire des extraits du prochain livre DSL de Martin Fowler , si vous songez à écrire votre propre langue.

Je ne peux pas vraiment penser à une analyse de rentabilisation pour créer une langue à partir de rien si ce n'est une expérience d'apprentissage extraordinaire.

Edit: pour les DSL, il y a beaucoup de business case, mais la clé ici est de ne pas s'emballer et de rester simple.

Je suggère que les questions clés sont: "Quel problème est-ce que j'essaie de résoudre?" et "Qui obtient le retour sur investissement?"

Si vous essayez de développer vos propres compétences et votre propre expérience, alors avancez à toute vitesse, mais pas dans un système de production censé résoudre le problème de quelqu'un d'autre.

On dirait que la principale raison pour laquelle vous voulez une nouvelle langue est que vous commencez à découvrir dans votre code des modèles que les langues existantes ne gèrent pas bien. Mais la création de votre propre langage pose de nombreux problèmes. Il vous manquera toutes les bibliothèques et tous les frameworks construits pour les langages existants. Vous passerez beaucoup de temps à concevoir et à mettre en œuvre le nouveau langage, ce qui est tout le temps que vous n'avez pas à consacrer à la vraie tâche de programmation. Vous déploierez beaucoup d'efforts pour convaincre les autres développeurs qu'ils doivent utiliser votre langage. Et vous aurez du mal à recruter et à former de nouveaux développeurs.

Pourquoi ne pas écrire dans un langage tel que Lisp qui vous permet d’étendre le langage à mesure que vous découvrez de nouveaux modèles? Ensuite, vous obtenez toute la puissance d'une nouvelle langue avec tous les avantages d'une langue établie.

Une des raisons pourrait être de le créer à titre expérimental pour en savoir plus sur la conception de langage et la construction de compilateurs.

Une autre raison pourrait être de créer un langage de script dans une application lorsque vous n'avez pas la possibilité d'ajouter une API tierce.

Je ne pense pas que vous puissiez programmer sans créer un nouveau langage, il est donc bon de comprendre que c'est ce que vous faites et de comprendre les problèmes.

• Qu'est ce qu'une langue?
  Vocabulaire, syntaxe et sémantique.

Un langage standard tel que VB, Java, C #, etc. n'est qu'un langage de base . Dès que vous ajoutez des classes, des méthodes, etc., vous avez ajouté du vocabulaire et de la sémantique. Il existe de nombreuses façons d'implémenter les langages: analyse et traduction, analyse et interprétation, macros superposées à un langage existant, ajout de classes et de méthodes à un langage existant.

• Que voulez-vous qu'une langue fasse?
  Soyez bon pour exprimer des problèmes avec concision.

Comment savez-vous si vous avez fait cela? La mesure que j'utilise est le nombre de modifications . Si l'exigence d'une phrase A se présente, je procède à la mise en œuvre de l'exigence dans le code. Lorsque j'ai terminé et que tous les bogues ont été résolus, je vérifie le code et le référentiel de code me fournit une liste des modifications apportées, B. Plus le nombre B est petit, meilleur est le langage. En moyenne sur l’espace des besoins réels et possibles, cette mesure me dit à quel point la langue est "spécifique à un domaine".

• Pourquoi la concision est-elle bonne?
  Parce que cela minimise les bugs.

S'il faut N changements de code pour implémenter 1 exigence et que vous faites parfois des erreurs, alors le nombre de bogues que vous introduisez est approximativement proportionnel à N. Dans la limite où N = 1, il est presque impossible d'introduire un bogue sans essayer.

Notez qu'il s'agit d'un défi direct au "gonflement du code" que nous voyons aujourd'hui.

ADDED: En réponse à votre demande d'exemple, voir l' exécution différentielle . Je ne dirai pas que cela peut être compris rapidement, mais cela réduit considérablement le code de l'interface utilisateur.

Il est toujours "faisable", d'utiliser le mot dans votre question (d'origine), mais ce n'est pas très souvent utile et très rarement optimal compte tenu de l'abondance de langages et de cadres bien supportés et matures.

C'est un défi intellectuel intéressant, cependant.

Seulement si les activités principales de votre équipe sont les langages de programmation.

J'ai travaillé sur un langage de programmation créé dans une société financière.

Clairement, pour l’architecte lui-même, c’était un grand défi et il a amélioré ses propres compétences.

Inévitablement, le langage ne pouvait ni se développer ni s’améliorer à un rythme aussi rapide que celui de C # ou de Java - ils avaient des équipes dédiées à cela.

La langue a rapidement stagné, personne n’ayant voulu réélaborer le projet animalier de quelqu'un d’autre.

L'architecte d'origine est parti. La langue se flétrit et mourut après 10 ans.

Ces 10 années ont été un enfer pour tous ceux qui ont eu la malchance de travailler sur une langue sans issue.

Alors allez-y, créez votre propre langage, mais s'il vous plaît, ne demandez à personne d'autre de l'utiliser réellement. S'il vous plaît ne vous attendez pas à ce que quelqu'un d'autre vous en remercie.

Concevoir des langues peut être amusant. Mais vous n'êtes pas obligé de vous restreindre à la programmation.

Si je construis une application moyennement complexe, j'aime bien ajouter une sorte de langage de macro / script pour faciliter l'exécution de tâches répétitives complexes. La plupart des utilisateurs n'utiliseront pas cette fonctionnalité, mais les rares qui l'utilisent lui en sont très reconnaissants. De plus, je m'assure que les personnes de l'assistance ont tout intérêt à les aider à résoudre les problèmes de leurs clients.

C'est tout à fait raisonnable si cela est fait pour développer vos compétences et apprendre.

Autre que cela, si vous devez poser la question, alors ce n'est pas. Si vous essayez de savoir si vous pouvez traiter une certaine classe d'algorithmes ou un certain domaine de problèmes mieux que les langues existantes, vous devez tout d'abord être un expert dans le domaine auquel vous vous adressez. Vous saurez que cela est approprié lorsque vos compétences et votre expérience vous l'indiquent.

Et vous pourriez vous tromper à ce sujet également, mais vous auriez besoin d'un autre expert pour vous en convaincre (ou pour vous montrer que vous n'êtes pas l'expert que vous croyez être). Une discussion animée qui serait, pas un simple Q-and-A comme vous le trouverez ici.

À part à des fins d’auto-éducation, je voudrais affirmer qu’aujourd’hui, il n’est nul besoin de créer sa propre langue. En toute circonstance. Déjà. Indépendamment de ce que vous voulez faire, il existe une multitude de langues existantes que vous pouvez utiliser / adapter à vos besoins.

Cela dépend définitivement de la situation. Comme dit nosklo - Si vous avez une bonne idée, un tout nouveau concept ou quelque chose du genre, je vous recommande fortement de le faire.

En général, je suggérerais de compter sur la technologie établie.

Mais si vous êtes intéressé par la création de votre propre "langue", vous devriez jeter un coup d'œil à: YACC & Lex

Vous pouvez, mais ne vous attrapez pas dans l'anti-motif "Recréer la roue carrée".

Ce qui signifie que vous recréez ce qui a déjà été fait, seulement plus pauvre que l’original.

Wouter était connu pour créer un nouveau langage pour toute nouvelle idée. Vous pouvez vous inspirer de son travail: la page du langage de programmation de Wouter .

Quand créer votre propre langue?

Quand vous voulez, comme un grand projet de loisir.

Pour une langue spécifique à un domaine. Ceux-ci peuvent être assez élaborés; regardez ce qui se passe dans la communauté de la fiction interactive (ou l'aventure textuelle) en consultant les archives .

Quand vos objectifs sont très ambitieux et que vous pensez pouvoir faire une réelle avancée, comme le projet Arc de Paul Graham .

De plus, dans tout langage suffisamment adaptable (peut-être C ++, certainement Common Lisp) lors du développement de constructions de bas niveau.

Quand l’éviter comme vous le feriez, j’espère, éviter un cliché comme l’éviter comme la peste?

Quand ce sera la base du développement continu de projets réels. Elle finira toujours par être sérieusement à la traîne par rapport à ce qui est disponible dans le commerce à bon marché et paralysera tout développement ultérieur. J'ai travaillé pour une entreprise avec sa propre version de COBOL et je ne veux jamais travailler dans une autre entreprise qui gère sa propre langue. Nous avons vu d’autres versions de COBOL obtenir de meilleures capacités et de meilleurs outils, alors que nous étions coincés avec les mêmes problèmes. (Je ne veux plus jamais travailler avec COBOL, mais c'est une autre histoire.)

Les situations dans lesquelles vous pourriez créer votre propre langue ne tombent pas dans cette situation. Les projets de loisirs ne sont pas utilisés pour un développement réel. Quelque chose comme Arc réussira (et obtiendra plusieurs implémentations et une évolution et un développement plus poussés) ou échouera (et personne d'autre ne l'utilisera). Une petite langue spécifique à un domaine n'est qu'une partie d'un projet et, étant petite, elle peut être améliorée avec le temps. Un langage d'aventure textuel est utilisé pour écrire des jeux individuels, et ces jeux, en plus d'être des projets de loisir, ne sont presque jamais utilisés pour un développement continu.

Mon point de vue est que les DSL sont généralement une "idée faible" et qu'il est plus productif à long terme d'utiliser un langage standard et de définir vos besoins spécifiques à un domaine en tant que bibliothèque de "non-DSL".

Toutefois, il se peut que vos besoins soient suffisamment personnalisés pour qu’il soit préférable d’avoir un DSL (pas seulement une implémentation légèrement modifiée de gcc ou lisp) pour votre entreprise. De nombreuses entreprises utilisent des langues insérées dans les langues actuelles qui ciblent ce qu’elles font, sans écrire / maintenir leur propre langue. Par exemple, j'ai entendu dire que PHP offrait une bonne installation; Lua est conçu pour être une halte-accueil, ModelView utilise Python et AutoCAD utilise AutoLISP comme scripteur.

Il n'y a rien de mal à écrire votre propre langage de programmation si vous pouvez exploiter les outils existants. Dans le monde d’aujourd’hui, cela signifierait que vous définissez une syntaxe utilisable pour un langage existant (tel que Java ou C #) ou écrivez un petit système de transformation (expandeur de macros) générant du code dans un langage existant.

Aller jusqu'au code machine, c'est réinventer BEAUCOUP de roues ...

Une très bonne raison pour un DSL est de représenter de manière succincte les données de domaine. Cela permet aux experts du domaine de travailler directement avec les données au lieu de passer par d'autres. L'astuce consiste alors à disposer des programmes résultants sous une forme facile à traiter.

De manière générale, la réponse serait un grand NON. Parmi les centaines de langues disponibles, il en existe généralement une qui conviendra à votre problème.

Cependant, il existe des circonstances où il est rationnel de développer un nouveau langage: -

• Lorsqu'un de vos concurrents possède désormais l'une de vos principales plateformes de développement. Je pense à la dépendance actuelle de Google à Java et à son développement de "go" (cela aide si vous avez un auteur du langage le plus réussi sur la liste de paie!).
• Lorsque vous devez écrire une tonne de code pour une nouvelle plate-forme et que les langues existantes sont détaillées et sujettes aux erreurs - par exemple, php pour le développement Web.
• Lorsque vous rencontrez des problèmes d'échelle et de parallélisme qui n'ont jamais été rencontrés auparavant car personne n'avait jamais eu autant de matériel pour traiter autant de données auparavant - par exemple Scala et (dans une certaine mesure, GO).

Ce qui est bon en langage, c'est la compositionnalité ou l'assemblage des mêmes composants de différentes manières.

Si votre problème de domaine nécessite que vous configuriez une série de commutateurs orthogonaux, une langue n'ajoutera probablement pas beaucoup au-dessus des formulaires, d'une interface utilisateur graphique ou d'une configuration textuelle simple. fichier. (Je suppose ici qu'un fichier complet de paires clé / valeur n'est pas ce que vous entendez par un "langage".)

OTOH, si votre configuration est comme un vrai langage, par exemple. les verbes et les noms peuvent être combinés dans de nombreuses combinaisons différentes (et nouvelles) à n'importe quel degré de complexité, puis une langue va devenir presque inévitable, car l'explosion combinatoire d'essayer de spécifier ce que vous voulez par toute autre méthode accable.

A part les exercices d’apprentissage, il est raisonnable de créer votre propre langage de programmation uniquement lorsque vous comprenez d’autres langues, votre domaine de problèmes spécifique et la manière dont les langues existantes traitent ce domaine de problèmes. Cette compréhension est suffisamment approfondie pour que vous sachiez qu’un nouveau langage est raisonnable. solution sans avoir besoin de poser la question.

La dernière fois que je me suis mis à le faire pour un projet de loisir, j'ai commencé à spécifier ce que je voulais que la syntaxe ressemble à et réalisé à mi-parcours que je réinventais prolog. D'autres langues qui pourraient vous convenir lorsque vous pensez avoir besoin d'inventer une langue sont le lisp, le lua ou quelque chose comme Haskell. En gros, toutes ces langues que vous avez ignorées au collège parce que vous pensiez qu'elles ne seraient jamais utiles.

Une des raisons est à des fins éducatives, comme déjà mentionné. Mais il y a plus. Par exemple, de nombreuses langues de recherche, telles que Sing#le système d'exploitation Singularity et BitCles Coyotos , ont été conçues car les langues existantes n'offrent pas les fonctionnalités requises (par exemple, la vérification au niveau de la langue).

Tom Van Cutsem a récemment écrit une réponse d'essai à cette question même:

http://soft.vub.ac.be/~tvcutsem/whypls.html

Résumé de la balle (à partir de cette page):

• Le langage en tant que mécanisme d'abstraction syntaxique: pour réduire le code répétitif "passe-partout" qu'il est impossible d'extraire de l'utilisation des mécanismes d'abstraction intégrés à un autre langage.
• Le langage en tant que forme de pensée: induire un changement de paradigme dans la manière de structurer le logiciel (changer le "chemin de moindre résistance").
• Le langage en tant que simplificateur: résumer un paradigme existant à ses parties essentielles, souvent pour améliorer la compréhension et la compréhension.
• Langage en tant qu'applicateur: pour appliquer des propriétés importantes ou des invariants, éventuellement pour faciliter la déduction de propriétés plus utiles à partir de programmes.

Probablement jamais.

Lua est le meilleur choix que vous puissiez obtenir si vous souhaitez intégrer la langue dans une autre langue.

Des langages spécifiques à un petit domaine sont actuellement utilisés, et cela a du sens dans certaines applications.

Sinon, les raisons sont principalement académiques.

Créer une langue quand on n'en a pas besoin est vraiment une mauvaise chose à faire en raison de la complexité impliquée dans son développement et son maintien. J'ai vu de nombreux projets introduisant une sorte de langage de script spécifique à ce programme uniquement, et c'est ce qui ralentissait considérablement le développement de la base. Les langages d’automatisation tels que Phantom, AutoHotKey, AutoIt sont de bons exemples. Ces outils seraient beaucoup mieux adaptés à l’OMI s’ils utilisaient un langage très répandu, comme Lua.

Votre «édition» semble être une question fondamentalement différente («Quand devrais-je créer un DSL?» Plutôt que la question initiale que les gens comprenaient comme «Quand devrais-je créer un nouveau langage de programmation à usage général»). Il semble que les gens aient complètement répondu à la question «originale», mais il y a peu de réponses qui donnent des critères spécifiques pour savoir quand utiliser un DSL. Je propose donc une liste de contrôle:

1. Votre base d'utilisateurs est plus grande que quelques personnes, généralement non technique et / ou avec un accès système restreint (il est donc déraisonnable de s'attendre à ce qu'ils apprennent / utilisent un langage généraliste existant). Si cela appartient à votre équipe de développement ou à votre organisation logicielle, vous pouvez plutôt dire "écrivez simplement un script".
2. Vos utilisateurs doivent l’utiliser suffisamment souvent, avec des comportements suffisamment variés et changeants (vous ne pouvez pas simplement fournir une bibliothèque fixe de fonctions gérées par vous).
3. Le comportement que les utilisateurs peuvent spécifier est trop compliqué à spécifier en tant que données (par exemple, vous ne pouvez pas y parvenir à l'aide d'une table de base de données, d'une matrice de saisie utilisateur, d'une liste de tâches ou d'une collection de valeurs clé ... réfléchissez bien. parce que vous pouvez réaliser beaucoup de complexité avec ceux-ci). Si vous pouvez obtenir le comportement en utilisant la saisie de données ou la configuration au lieu de DSL, vous devriez probablement le faire, car le travail sera beaucoup moins fastidieux. Une sorte de conditionnalité, ou de composabilité / chaînage, ou la modélisation de quelques abstractions différentes peut indiquer que le comportement dont vous avez besoin est trop complexe pour des données / configuration claires.
4. Mais le comportement est toujours suffisamment limité pour que vous puissiez le spécifier dans un DSL concis. Par exemple, si les utilisateurs commencent à demander "pouvez-vous simplement ajouter ...?". S'ils ont besoin de se connecter à Internet, de lire et d'écrire à partir du système de fichiers, ou d'ouvrir et de fermer des processus, il ne s'agit plus d'un DSL. (J'ai vu cela se produire pour de vrai ... utilisateurs autorisés à intégrer de petits appels python, évoluant progressivement vers des scripts python, et détruisant finalement toute limite / modularité / performance)

Si tout cela est vrai, un DSL peut être approprié.

Existe-t-il des types d'applications destructrices, des classes de problèmes algorithmiques, etc., où il est préférable, à long terme, de créer mon propre langage?

Ça dépend.

Prenons notre cerveau. Cela semble être un désordre si complexe que nous rencontrons des frontières avec N'IMPORTE QUEL langage de programmation (du moins à présent). Alors peut-être que pour virtualiser réellement notre cerveau, nous avons besoin d’autres approches et donc d’autres sémantiques et syntaxes.

De manière générale, il existe encore des sujets aussi complexes qui pourraient conduire à d’autres stratégies qui incluraient également un «meilleur» langage pour un scénario donné.