Quand une nouvelle langue est-elle le bon outil pour le travail?

Question

J'ai longtemps essayé différentes langues pour trouver l'ensemble de fonctionnalités que je souhaitais et je n'ai pas réussi à le trouver. J'ai des langues qui conviennent à différents projets, mais j'ai trouvé un croisement de ces langues qui me permettra de réaliser 99,9% de mes projets dans une seule langue. Je veux ce qui suit:

• Construit sur .NET ou a une implémentation .NET
• Peu de dépendances du runtime .NET à la compilation et à l'exécution (important dans la mesure où l'un des principaux cas d'utilisation concerne le développement intégré, où le runtime .NET est complètement personnalisé)
• dispose d'un compilateur composé à 100% de code .NET sans dépendance non gérée
• Prend en charge l'imbrication d'expressions arbitraires (voir ci-dessous)
• Prend en charge les définitions d'opérateur personnalisées
• Prend en charge l'inférence de type
• Optimise les appels en queue
• A des définitions explicites immuables / mutables (gentillesse - j'ai appris à aimer ça mais je peux vivre sans cela)
• Prend en charge les macros réelles pour une métaprogrammation forte (impératif absolu)

Les deux langues principales avec lesquelles je travaille sont le boo et le nemerle, mais j'ai aussi joué avec le f #.

Principales plaintes contre Nemerle: le compilateur a des rapports d’erreurs horribles, son implémentation est boguée (compilateur et bibliothèques), les macros ne peuvent être appliquées qu’à l’intérieur d’une fonction ou d’attributs, et sa dépendance est assez lourde assez que c’est un dealbreaker).
Principales réclamations à l'encontre de Boo: pas d'imbrication d'expression arbitraire (dealbreaker), les macros sont difficiles à écrire, pas de définition d'opérateur personnalisé (dealbreaker potentiel).
Principales réclamations à l'encontre de F #: syntaxe laide, métaprogrammation difficile à comprendre, licence non libre (dealbreaker épique).

Donc, plus j'y pense, plus je pense à développer mon propre langage.

Avantages:

• Obtenir la syntaxe exacte que je veux
• Obtenez un délai d'exécution beaucoup plus rapide; difficile à quantifier, mais je ne serais pas surpris de voir la productivité des développeurs 1.5x, notamment en raison des infrastructures de test que cela peut permettre pour certains projets
• Je peux facilement ajouter des fonctionnalités personnalisées au compilateur pour jouer correctement avec mon runtime
• Je reçois quelque chose qui est conçu et qui fonctionne exactement comme je le souhaite - autant que cela ressemble à NIH, cela me facilitera la vie

Inconvénients:

• À moins que cela ne gagne en popularité, je vais devoir supporter la charge de l'entretien. Je sais que je peux au moins amener les gens de Nemerle, car je pense que tout le monde veut quelque chose de plus professionnel, mais cela prend un village.
• En raison du premier problème, je ne pense pas à l'utiliser dans un cadre professionnel. Cela dit, j'utilise déjà Nemerle et mon propre compilateur modifié personnalisé, car ils ne le maintiennent pas bien.
• Si cela ne gagne pas en popularité, il sera beaucoup plus difficile de trouver des développeurs, dans une mesure aussi Paul Graham pourrait même ne pas tolérer.

Donc, sur la base de tout cela, quel est le consensus général - est-ce une bonne ou une mauvaise idée? Et peut-être plus utilement, est-ce que j'ai raté de gros avantages ou inconvénients?

Modifier: vous avez oublié d'ajouter l'exemple d'imbrication - voici un cas dans Nemerle:

def foo = 
    if(bar == 5)
        match(baz) { | "foo" => 1 | _ => 0 }
    else bar;

Éditer # 2: Je me suis dit que cela ne ferait pas de mal de donner un exemple du type de code qui sera converti dans ce langage s'il existe (la réponse de S. Lott à elle seule suffira peut-être à me dissuader de le faire) . Le code utilise beaucoup de syntaxe personnalisée (opcode,: =, quoteblock, etc.), d'imbrication d'expression, etc. Vous pouvez consulter un bon exemple ici: ici .

Answer 1

Malheureusement, il n'y a pas de métrique ni d'histoires autour des langues en échec. Juste des langues réussies. De toute évidence, les échecs sont plus nombreux que les succès.

Sur quoi est-ce que je me base? Deux expériences communes.

1. Une ou deux fois par an, je dois supporter un argumentaire pour un produit / langage / outil / framework qui va absolument tout changer. Ma réponse est constante depuis une vingtaine d'années. Montrez-moi quelqu'un qui a besoin de soutien et mon entreprise les soutiendra Et c'est ça. N'entendez plus jamais parler d'eux. Disons que j'ai entendu 25 d'entre eux.

2. Une ou deux fois par an, je dois travailler avec un client orphelin de technologie. À un moment donné, une programmation intelligente a construit un outil / cadre / bibliothèque / paquet utilisé en interne pour plusieurs projets. Puis ce programmeur est parti. Personne d'autre ne peut comprendre cette chose, et ils veulent que nous la remplacions / réécrivions. Malheureusement, nous ne pouvons pas le savoir non plus, et notre proposition est de réécrire à partir de zéro. Et ils se plaignent du fait que leur génie ait construit l'ensemble des applications en quelques semaines. Cela ne peut pas nous prendre des mois pour les réécrire en Java / Python / VB / C #. Disons que j'ai écrit environ 25 de ces propositions.

C'est juste moi, un consultant.

En effet, une entreprise particulièrement triste a été créée par tout un portefeuille de logiciels informatiques écrit par un type intelligent possédant un langage et des outils privés. Il n'était pas parti, mais il s'était rendu compte que son langage et ses outils avaient pris du retard, que l'état de la technique avait évolué et qu'il ne l'avait pas fait.

Et le déménagement était - bien sûr - dans une direction inattendue. Son langage et ses outils fonctionnaient bien, mais le monde entier avait commencé à adopter des bases de données relationnelles et il n'avait absolument aucun moyen de mettre à niveau sa malbouffe pour s'éloigner des fichiers plats. C'était quelque chose qu'il n'avait pas prévu. En effet, c'était quelque chose qu'il ne pouvait pas prévoir. [Vous ne tomberez pas dans ce piège, voulez-vous?]

Alors, nous avons parlé. Il a réécrit beaucoup d'applications dans Plain-Old VAX Fortran (oui, il y a longtemps.) Et il l'a réécrit pour utiliser de vieilles bases SQL relationnelles (Ingres, à l'époque.)

Après une année de codage, ils avaient des problèmes de performances. Ils m'ont rappelé pour passer en revue toutes les bonnes choses qu'ils avaient faites pour remplacer le langage construit à la maison. Malheureusement, ils avaient conçu la pire base de données relationnelle possible. Pire possible. Ils avaient pris leurs copies de fichiers, leurs fusions, leurs tris, etc., et mis en œuvre chaque opération de système de fichiers de bas niveau à l'aide de SQL, en dupliquant les lignes de la base de données à gauche, à droite et au centre.

Il était tellement empêtré dans sa vision privée du langage parfait qu'il ne pouvait pas s'adapter à une nouvelle technologie relativement courante et omniprésente.

Answer 2

Je dis allez-y.

• Ce serait une expérience extraordinaire quelle que soit la météo, que ce soit pour la production ou non.
• Si vous le compilez en IL, vous n'avez pas à craindre de ne pas pouvoir réutiliser vos assemblages compilés avec C #
• Si vous pensez avoir des réclamations valables au sujet des langues que vous avez énumérées ci-dessus, il est probable que beaucoup de gens penseront comme vous. Bien sûr, pour 1 000 personnes intéressées, il y en a peut-être une qui est disposée à vous aider à la maintenir - mais c'est toujours le risque

Mais voici quelques points sur lesquels il faut se mettre en garde:

• Obtenez votre spécification de langue IN STONE avant le développement. Assurez-vous que toutes les fonctionnalités linguistiques sont bien définies, même les choses que vous ne voudrez peut-être que dans le futur. À mon avis, C # est en train de tomber lentement dans le "oh-just-one-more-language-extension" piège qui mènera à son destin final.
• Assurez-vous de l'optimiser. Je ne sais pas ce que vous savez déjà; mais si vous ne savez pas, alors apprenez;) Personne ne voudra d’un langage avec une syntaxe intéressante mais aussi lent que l’implémentation JavaScript de IE.

Bonne chance: D

Answer 3

Lorsque j'ai commencé ma carrière au début des années 90, il semblait exister cet engouement pour que chacun développe ses propres langues internes. Mes premiers 3 emplois ont été avec des entreprises qui l’avaient déjà fait. Une entreprise a même développé son propre système d’exploitation!

Par expérience, je dirais que c'est une mauvaise idée pour les raisons suivantes:

1) Vous passerez du temps à déboguer le langage lui-même en plus de la base de code qui s'y trouve.
2) Tous les développeurs que vous engagez devront suivre la courbe d'apprentissage de la langue.
3) Il sera difficile d’attirer et de retenir les développeurs, car travailler dans un langage propriétaire est une impasse pour la carrière de quelqu'un

La raison principale pour laquelle j'ai quitté ces trois emplois était parce qu'ils avaient des langages propriétaires et que vous remarquerez que peu d'entreprises empruntent désormais cette voie:).

Un argument supplémentaire que je ferais valoir est que la plupart des langues ont des équipes entières dont le travail à plein temps consiste à développer la langue. Peut-être que vous seriez une exception, mais je serais très surpris de pouvoir égaler ce niveau de développement en ne travaillant que sur le langage à temps partiel.

Answer 4

  

Principales plaintes contre Nemerle: le   le compilateur a un rapport d'erreur horrible,   l'implémentation est buggy comme l'enfer   (compilateur et bibliothèques), les macros   ne peut être appliqué qu'à l'intérieur d'une fonction   ou comme attributs, et c'est assez   dépendance lourde sage (bien que pas   assez que c’est un dealbreaker).

Je vois que votre article a été écrit il y a plus de deux ans. Je vous conseille d'essayer la langue Nemerle aujourd'hui. Le compilateur est stable. Il n'y a pas de bugs bloquants pour aujourd'hui. L’intégration VS a beaucoup d’améliorations, il y a aussi l’intégration SharpDevelop.

Si vous lui donnez une chance, vous ne serez pas déçu.

Answer 5

Ne développez JAMAIS votre propre langage.

Développer votre propre langage est un piège imbécile et, pire encore, il vous limitera à ce que votre imagination peut offrir, tout en vous obligeant à élaborer à la fois votre environnement de développement et le programme que vous écrivez.

Les cas dans lesquels cela ne s'applique pas sont à peu près si vous êtes Larry Wall, les gars d'AWK, ou si vous faites partie d'un groupe important de personnes vouées à tester les limites de la programmation. Si vous faites partie de ces catégories, vous n’avez pas besoin de mes conseils, mais je doute fortement que vous visiez un créneau dans lequel il n’existe pas de langage de programmation adapté à la tâche ET les caractéristiques des personnes qui l’exécutent.

Answer 6

Si vous êtes aussi intelligent que vous semblez l'être (une possibilité probable), mon conseil est de commencer par concevoir le langage en premier lieu, de le parcourir plusieurs fois, demandez à des types de confiance en qui vous avez confiance. communautés de langage de programmation sur la conception concrète que vous avez proposé et ensuite prendre la décision.

Lors de la création du design, vous vous rendrez peut-être compte qu’un simple piratage rapide de Nemerle donnerait tout ce dont vous avez besoin, par exemple. Beaucoup de choses peuvent arriver juste quand on réfléchit sérieusement à un problème, et la solution finale peut ne pas être ce que vous aviez réellement en tête au début du projet.

Dans le pire des cas, vous ne parvenez pas à mettre en œuvre le concept, mais vous devrez alors le relire et le faire mûrir, et vous saurez avec un degré de certitude élevé que c’est un bon chemin à suivre.

Conseil connexe, commencez petit, définissez simplement les fonctionnalités dont vous avez absolument besoin, puis utilisez-les pour obtenir le reste.

Answer 7

Écrire votre propre langue n’est pas un projet facile. Surtout un projet qui doit être utilisé dans tout type de "milieu professionnel"

.

C’est une énorme quantité de travail. Je doute que vous puissiez écrire votre propre langue tout en écrivant de gros projets qui l'utilisent - vous allez passer si longtemps à ajouter les fonctionnalités dont vous avez besoin, la correction de bugs et la conception de langage en général.

Je recommanderais vivement de choisir une langue proche de ce que vous voulez et de l'étendre pour faire ce dont vous avez besoin. Ce ne sera jamais exactement ce que vous voulez, mais comparé au temps que vous passerez à écrire votre propre langue, je dirais que c'est un petit compromis.

Answer 8

Scala a un compilateur .NET. Je ne connais pas le statut de cela cependant. C'est un peu un citoyen de deuxième classe dans le monde Scala (qui est davantage axé sur la JVM). Cependant, il peut être intéressant d’adopter le compilateur .NET au lieu de créer un nouveau langage à partir de zéro.

Scala est un peu faible dans l’ATM du département de méta-programmation. Il est possible que le besoin de métaprogrammation soit quelque peu réduit par d'autres fonctionnalités langagières. En tout cas, je pense que personne ne serait triste si vous implémentiez des fonctionnalités de métaprogrammation. De plus, une infrastructure de plug-in de compilation est en préparation.

Answer 9

Je pense que la plupart des langues ne conviendront jamais à tous les projets de loi.

Vous pouvez combiner vos deux langues préférées (dans mon cas, C # et Scheme ) et les utiliser ensemble. .

D'un point de vue professionnel, ce n'est probablement pas une bonne idée.

Answer 10

Il serait intéressant d’entendre certaines des choses que vous pensez ne pas pouvoir faire dans les langues existantes. Sur quels types de projets travaillez-vous qui ne peuvent pas être réalisés en C #?

Je ne suis que curiosité!