Ma réponse n'est vraiment qu'une élaboration de Gilles, que je n'avais pas lue avant d'écrire la mienne. C'est peut-être néanmoins utile.
Permettez-moi de commencer ma tentative de répondre à votre question en distinguant deux dimensions du travail des langages de programmation qui se rapportent assez différemment à la théorie du langage de programmation en général et au calcul des processus en particulier.
Ce dernier se déroule généralement dans l'industrie dans le but de fournir des langages de programmation en tant que produit. Les équipes développant Java chez Oracle et C # chez Microsoft en sont des exemples. En revanche, la recherche pure n'est pas liée aux produits. Son objectif est de comprendre les langages de programmation comme des objets d'intérêt intrinsèque et d'explorer les structures mathématiques sous-jacentes à tous les langages de programmation.
En raison d'objectifs divergents, différents aspects de la théorie du langage de programmation sont pertinents dans la recherche pure et dans la R&D axée sur les produits. L'image ci-dessous peut donner une indication de ce qui est important où.
On peut se demander à ce stade pourquoi les deux dimensions sont si différentes en apparence et comment elles sont néanmoins liées.
L'idée principale est que la recherche et le développement de langages de programmation ont plusieurs dimensions: technique, sociale et économique. Presque par définition, l'industrie s'intéresse aux retombées économiques des langages de programmation. Microsoft et al ne développent pas de langages par bonté mais parce qu'ils croient que les langages de programmation leur confèrent un avantage économique. Et ils ont étudié en profondeur pourquoi certains langages de programmation réussissent, et d'autres, apparemment similaires ou avec des fonctionnalités plus avancées, ne le font pas. Et ils ont constaté qu'il n'y avait pas une seule raison. Les langages de programmation et leurs environnements sont complexes, tout comme les raisons pour adopter ou ignorer un langage spécifique. Mais le facteur le plus important pour le succès d'un langage de programmation est l'attachement préférentiel des programmeurs à des langages déjà largement utilisés: plus les gens utilisent un langage, plus les bibliothèques, les outils, le matériel pédagogique sont disponibles et plus le programmeur est productif peut utiliser cette langue. Cela s'appelle également l'effet réseau. Une autre raison est le changement de langue coûteux pour les individus et l'organisation: la maîtrise du langage, en particulier pour un programmeur peu expérimenté, et lorsque la distance sémantique avec les langues familières est grande, est un effort sérieux et long. Compte tenu de ces faits, on peut se demander pourquoi les nouvelles langues gagnent du terrain? Pourquoi les entreprises développent-elles de nouvelles langues? Pourquoi ne restons-nous pas simplement avec Java ou Cobol? Je pense qu'il y a plusieurs raisons principales pour lesquelles une langue réussit,
Un nouveau domaine de programmation s'ouvre et n'a aucun titulaire à déplacer. Le principal exemple est le Web avec son essor concomitant de Javascript.
Adhérence linguistique. J'entends par là le prix élevé du changement de langue. Mais parfois, les programmeurs se déplacent dans différents domaines, emportant un langage de programmation avec eux et réussissant avec l'ancien langage dans le nouveau domaine.
Une langue est poussée par une grande entreprise avec une puissance de feu financière sérieuse. Ce soutien réduit le risque d'adoption, car les premiers utilisateurs peuvent être raisonnablement sûrs que la langue sera toujours prise en charge dans quelques années. Un bon exemple de cela est C #.
Une langue peut venir avec des outils convaincants et un écosystème. Ici aussi, C # et son écosystème .Net et Visual Studio pourraient être mentionnés à titre d'exemple.
Les anciennes langues récupèrent de nouvelles fonctionnalités. Java vient à l'esprit, qui, à chaque itération, reprend plus de bonnes idées de la tradition de programmation fonctionnelle.
Enfin, un nouveau langage pourrait avoir des avantages techniques intrinsèques, par exemple être plus expressif, avoir une syntaxe plus agréable, des systèmes de frappe qui captent plus d'erreurs, etc.
Dans ce contexte, il ne devrait pas être surprenant qu'il y ait un certain décalage entre la recherche pure en langage de programmation et le développement de langage de programmation commercial. Alors que les deux visent à rendre la construction et l'évolution des logiciels plus efficaces, en particulier pour les logiciels à grande échelle, le travail en langage de programmation industriel doit être plus intéressé à faciliter une adoption rapide pour atteindre une masse critique et obtenir l'effet réseau. Cela conduit à une concentration de la recherche sur les choses qui intéressent les programmeurs qui travaillent. Et cela a tendance à être des choses comme la disponibilité de la bibliothèque, la vitesse du compilateur, la qualité du code compilé, la portabilité, etc. Le calcul de processus tel que nous le pratiquons aujourd'hui est peu utile aux programmeurs travaillant sur des projets traditionnels (bien que je pense que cela changera à l'avenir).
λπβ-réduction pour la programmation fonctionnelle, résolution / unification pour la programmation logique, passage de nom pour le calcul simultané). Pour comprendre si un langage comme Scala peut avoir une inférence de type complète viable, nous n'avons pas à nous soucier de la JVM. En effet, la réflexion sur la JVM nuira à une meilleure compréhension de l'inférence de type. C'est pourquoi l'abstraction du calcul en minuscules calculs de base est vitale et puissante.
Donc, vous pouvez penser à la recherche sur le langage de programmation comme un immense bac à sable où les gens jouent avec des jouets, et s'ils trouvent quelque chose d'intéressant en jouant avec un jouet spécifique et ont étudié le jouet à fond, alors ce jouet intéressant commence sa longue marche vers l'acceptation industrielle traditionnelle . Je dis longue marche parce que les fonctionnalités du langage inventées pour la première fois par un chercheur en langage de programmation ont tendance à prendre des décennies avant d'être largement acceptées. Par exemple, la collecte des ordures a été conçue dans les années 1950 et est devenue largement disponible avec Java dans les années 1990. La correspondance des motifs remonte à 1970 et n'est largement utilisée que depuis Scala.
Le calcul de processus est un jouet particulièrement intéressant. Mais c'est trop nouveau pour faire l'objet d'une enquête approfondie. Cela prendra encore une décennie de recherche pure. Ce qui se passe actuellement dans la recherche sur la théorie des processus est de prendre la plus grande réussite de la recherche sur le langage de programmation, la théorie des types (séquentiels) et de développer la théorie des types pour la transmission simultanée de messages. Les systèmes de typage d'expressivité modérée pour la programmation séquentielle, disent Hindley-Milner, sont maintenant bien compris, omniprésents et acceptés par les programmeurs qui travaillent. Nous aimerions avoir des types modérément expressifs pour la programmation simultanée. Les recherches à ce sujet ont commencé dans les années 80 par des pionniers comme Milner, Sangiorgi, Turner, Kobayashi, Honda et d'autres, souvent basés, explicitement ou implicitement, sur l'idée de linéarité qui vient de la logique linéaire. Les dernières années ont vu une augmentation importante de l'activité et je m'attends à ce que cette trajectoire ascendante se poursuive dans un avenir prévisible. Je m'attends également à ce que ce travail commence à s'infiltrer dans la R&D axée sur les produits, en partie pour la raison pragmatique que de jeunes chercheurs qui ont été formés au calcul des processus iront travailler dans des laboratoires de R&D industriels, mais aussi en raison de l'évolution du CPU et de l'architecture informatique. à partir de formes séquentielles de calcul.
En résumé, je ne m'inquiéterais pas que vous ne trouviez pas la théorie de pointe du langage de programmation telle que le calcul de processus utile dans votre propre travail de construction de langages. C'est tout simplement parce que la théorie de pointe ne répond pas aux préoccupations des langages de programmation actuels. Il s'agit de futures langues. Il faudra du temps pour que le «monde réel» se rattrape. Les connaissances que vous utilisez pour créer des langages d'aujourd'hui sont la théorie du langage de programmation du passé. Je vous encourage à en savoir plus sur le calcul des processus car c'est l'un des domaines les plus intéressants de toute l'informatique théorique.
La science de la conception de langages de programmation en est à ses balbutiements. La théorie (l'étude de la signification des programmes et de l'expressivité d'une langue) et l'empirisme (ce que les programmeurs gèrent ou ne parviennent pas à faire) fournissent de nombreux arguments qualitatifs pour peser d'une manière ou d'une autre lors de la conception d'une langue. Mais nous avons rarement une raison quantitative de décider.
Il y a un délai entre le moment où une théorie se stabilise suffisamment pour qu'une innovation soit utilisable dans un langage de programmation pratique et le moment où cette innovation commence à apparaître dans les langages «traditionnels». Par exemple, on peut dire que la gestion automatique de la mémoire avec la collecte des ordures est arrivée à maturité pour une utilisation industrielle au milieu des années 1960, mais qu'elle n'a atteint le courant dominant avec Java qu'en 1995. Le polymorphisme paramétrique était bien compris à la fin des années 1970 et l'a rendu en Java au milieu des années 200. À l'échelle de la carrière d'un chercheur, 30 ans, c'est long.
L'adoption industrielle à grande échelle d'une langue est une question que les sociologues doivent étudier, et cette science en est encore à ses balbutiements. Les considérations du marché sont un facteur important - si Sun, Microsoft ou Apple pousse une langue, cela a beaucoup plus d'impact que n'importe quel nombre de papiers POPL et PLDI. Même pour un programmeur qui a le choix, la disponibilité de la bibliothèque est généralement beaucoup plus importante que la conception du langage. Ce qui ne veut pas dire que la conception de la langue n'est pas importante: avoir une langue bien conçue est un soulagement! Ce n'est généralement pas le facteur décisif.
Les calculs de processus sont encore au stade où la théorie ne s'est pas stabilisée. Nous croyons comprendre les calculs séquentiels - tous les modèles de choses que nous aimons appeler calcul séquentiel sont équivalents (c'est la thèse de Church-Turing). Cela ne vaut pas pour la concurrence: les différents calculs de processus ont tendance à avoir de subtiles différences d'expressivité.
Les calculs de processus ont des implications pratiques. De nombreux calculs sont distribués - ils impliquent des clients qui parlent à des serveurs, des serveurs qui parlent à d'autres serveurs, etc. et avec l'utilisateur).
Faut-il avancer dans la recherche pour créer de meilleurs logiciels? Après tout, il existe une industrie d'un milliard de dollars qui ne peut pas distinguer le calcul pi d'une tarte dans le ciel. Là encore, cette industrie dépense des milliards de dollars pour réparer les bugs.
«Seront-ils jamais nécessaires» n'est jamais une question valable dans la recherche. Il est impossible de prévoir à l'avance ce qui aura des conséquences à long terme. J'irais même plus loin et je dirais que c'est une hypothèse sûre que toute recherche aura des conséquences un jour - nous ne savons tout simplement pas à l'époque si ce jour viendra l'année prochaine ou le prochain millénaire.
la source
Ceci est une question délicate! Je vais vous dire mon opinion personnelle, et je souligne que c'est mon opinion .
Je ne pense pas que le pi-calcul soit directement approprié comme notation pour une programmation simultanée. Cependant, je pense que vous devriez certainement l' étudier avant de concevoir un langage de programmation simultané. La raison en est que le pi-calcul donne un faible niveau --- mais surtout, compositionnel! --- compte de la concurrence. En conséquence, il peut exprimer tout ce que vous voulez, mais pas toujours de manière pratique.
Expliquer ce commentaire nécessite de réfléchir un peu aux types. Premièrement, les langages de programmation utiles ont généralement besoin d'une sorte de discipline de type pour construire des abstractions. En particulier, vous avez besoin d'une sorte de type de fonction pour utiliser les abstractions procédurales lors de la création d'un logiciel.
Maintenant, la discipline de type naturel du pi-calcul est une variante de la logique linéaire classique. Voir, par exemple, le document Abramsky's Process Realizability , qui montre comment vous interprétez des programmes simultanés simples comme des preuves de propositions à partir d'une logique linéaire. (La littérature contient beaucoup de travail sur les types de session pour taper des programmes de pi-calcul, mais les types de session et les types linéaires sont très étroitement liés.)
C'est très bien de la théorie du type POV, mais c'est gênant lors de la programmation. La raison en est que les programmeurs finissent par gérer non seulement leurs appels de fonction, mais aussi la pile d'appels. (En effet, les encodages de lambda calcul en pi calcul finissent généralement par ressembler à des transformations CPS.) Maintenant, la saisie garantit qu'ils ne verront jamais cela, mais néanmoins c'est beaucoup de comptabilité imposée au programmeur.
Ce n'est pas un problème unique à la théorie de la concurrence --- le mu-calcul donne un bon compte-rendu théorique des opérateurs de contrôle séquentiel comme call / cc, mais au prix de rendre la pile explicite, ce qui en fait un langage de programmation maladroit.
Donc, lors de la conception d'un langage de programmation simultané, mon avis est que vous devez concevoir votre langage avec des abstractions de niveau supérieur au pi-calcul brut, mais vous devez vous assurer qu'il est correctement traduit en un calcul de processus typé sensible. (Un bel exemple récent de ceci est les processus, fonctions et sessions de niveau supérieur de Tonhino, Caires et Pfenning : une intégration monadique .)
la source
Vous dites que «le véritable objectif final serait d'utiliser la théorie pour réellement construire un PL». Donc, vous admettez probablement qu'il y a d'autres objectifs?
De mon point de vue, le but n ° 1 de la théorie est de fournir une compréhension, qui peut être dans le raisonnement sur les langages de programmation existants ainsi que les programmes écrits en eux. Dans mes temps libres, je gère un gros logiciel, un client de messagerie, écrit il y a longtemps en Lisp. Toute la théorie PL que je connais, comme la logique de Hoare, la logique de séparation, l'abstraction des données, la paramétricité relationnelle et l'équivalence contextuelle, etc. est très utile dans le travail quotidien. Par exemple, si j'étends le logiciel avec une nouvelle fonctionnalité, je sais qu'il doit encore conserver la fonctionnalité d'origine, ce qui signifie qu'il devrait se comporter de la même manière dans tous les anciens contextes même s'il va faire quelque chose de nouveau dans de nouveaux contextes. Si je ne savais rien sur l'équivalence contextuelle, je ne serais probablement même pas en mesure de formuler le problème de cette façon.
En ce qui concerne votre question sur le pi-calcul, je pense que le pi-calcul est encore un peu trop nouveau pour trouver des applications dans la conception de langage. La page wikipedia sur le pi-calcul mentionne BPML et occam-pi comme conceptions de langage utilisant le pi-calcul. Mais vous pouvez également consulter les pages de son prédécesseur CCS et d'autres calculs de processus tels que CSP, join calculus et autres, qui ont été utilisés dans de nombreux modèles de langage de programmation. Vous pouvez également consulter la section «Objets et pi-calcul» du livre Sangiorgi et Walker pour voir comment le pi-calcul est lié aux langages de programmation existants.
la source
J'aime chercher des implémentations pratiques de calculs de processus dans la nature :) (en plus de lire sur la théorie).
etc.
la source