Les langages de programmation ressemblent-ils davantage aux langages naturels?

Peut-on étudier les langages de programmation dans le contexte de la linguistique? Les langages de programmation évoluent-ils naturellement de manière similaire aux langages naturels?

Bien que la rationalité totale et la cohérence mathématique soient essentielles aux langages de programmation, il reste nécessaire (en particulier les langages modernes) de les rendre lisibles et confortables pour les humains.

Les langages de programmation évoluent-ils pour devenir plus linguistiques et donc plus naturels? Par exemple, le code machine, les cartes perforées et les langages d'assemblage ont cédé la place à des langages plus lisibles comme Ruby et Python, etc.

Quand je dis que les langages informatiques deviennent plus naturels, je ne veux pas dire qu'ils contiennent plus de «mots que nous avons en anglais», je veux dire qu'ils semblent devenir plus comme un langage naturel, en termes de complexité de grammaire et de capacité à exprimer le sens (par exemple, être capable de décrire avec éloquence une requête à partir d'une base de données de manière rationnelle et compréhensible par l'homme).

Qu'en pensez-vous tous? Les langages de programmation ressemblent-ils davantage aux langages naturels et deviennent-ils ainsi applicables aux lois de la linguistique?

Ou peut-être que les langues vivent sur un spectre, où d'un côté vous avez les langues extrêmement rationnelles et de l'autre les plus créatives. Peut-être que la programmation et les langages naturels sont identiques et se situent tous deux sur ce spectre linguistique (leur seule différence, peut-être étant la «chose» à laquelle ils essaient de donner leur sens).

Existe-t-il un lien entre la séparation (effet Babel Tower) des langages humains et des langages informatiques? Deviennent-ils plus diversifiés pour les mêmes raisons (c'est-à-dire pour résoudre des problèmes différents dans des systèmes informatiques / systèmes de culture en constante évolution, etc.)?

Non, pas vraiment. Les langages de programmation ne sont devenus des langages naturels que dans le sens de «mots que nous avons en anglais» ( sic ).

Une caractéristique clé des langages de programmation est qu'ils ne sont pas ambigus. Lorsque vous écrivez et exécutez un programme, il a une signification bien définie, qui est son comportement. Si vous voulez écrire un programme qui fonctionne comme prévu (un objectif difficile), il est important que le comportement¹ du programme soit aussi prévisible que possible. Les langages de programmation n'ont pas fait beaucoup de différence dans le grand écart vers les langages naturels.

À l'inverse, des efforts ont été faits pour combler l'écart de l'autre côté: analyser les langages naturels avec les mêmes outils que les langages de programmation. Ce champ est appelé traitement du langage naturel . Ces approches ont été pratiquement abandonnées au profit de l'apprentissage automatique . Je citerai un passage de l'article Wikipédia qui est directement pertinent ici:

Jusqu'aux années 80, la plupart des systèmes de PNL étaient basés sur des ensembles complexes de règles manuscrites. Cependant, à partir de la fin des années 80, il y a eu une révolution dans la PNL avec l'introduction d'algorithmes d'apprentissage automatique pour le traitement du langage. Cela était dû à la fois à l'augmentation constante de la puissance de calcul résultant de la loi de Moore et à la diminution progressive de la domination des théories chomskyennes de la linguistique (par exemple, la grammaire transformationnelle), dont les fondements théoriques décourageaient le type de linguistique de corpus qui sous-tend l'approche d'apprentissage automatique pour traitement de la langue.

L'une des façons dont la programmation évolue est que, lorsque nous concevons des systèmes de plus en plus grands, le code source n'est pas toujours un bon moyen de les comprendre. Par exemple, un processeur Intel est l'un des objets les plus complexes jamais conçus par Man, et son «code source» n'est pas seulement une collection de fichiers texte, loin de là. Mais le design complet n'évolue pas non plus vers quelque chose qui ressemble à un langage humain. Je ne sais pas quels sont les outils cognitifs ou métaphores appropriés ici, et je ne pense pas que personne ne le sache pour l'instant; redemander dans quelques siècles.

¹ _{Ou plutôt l'ensemble des comportements possibles annotés avec les circonstances dans lesquelles ils surviennent, mais cela n'ajoute qu'une étape d'indirection dans la modélisation, donc ce n'est pas vraiment pertinent ici.}

Les langages informatiques ont tendance à bien fonctionner avec la justesse et la précision, un peu comme la notation mathématique, qui n'a montré aucune inclination particulière à évoluer vers le langage naturel (que je connais) au cours des derniers milliers d'années.

Je doute aussi que si vous communiquiez avec votre enfant exclusivement à Haskell pendant les premières années de sa vie, il développerait une maîtrise du langage naturel. Donc, je pense qu'il y a un contraste assez net entre les langages naturels et informatiques.

Peut-être que la diffusion plus large des techniques de construction de la langue a légèrement amélioré le "naturel" au fil du temps, car les programmeurs "votent avec leurs pieds" en utilisant des langues qui leur semblent plus faciles et le nombre de personnes capables de créer des langues a augmenté de plus en plus. les praticiens et de meilleurs outils, mais cela est un petit effet sur les bords et ne représente pas une transformation fondamentale des langages de programmation en humains.

une étude de cas intéressante dans ce domaine est Perl vs Ruby (et Python ). Perl est un langage de script développé au début des années 90 qui a ajouté beaucoup de fonctionnalités par rapport aux langages de script basés sur Unix précédents (par exemple bash). l'auteur Larry Wall a déclaré publiquement que ses antécédents linguistiques avaient inspiré certaines des caractéristiques linguistiques.

cependant Perl a une syntaxe maladroite et de nombreux cas spéciaux qui rendent le langage un peu comme l'anglais dans toutes ses subtiles idiosyncrasies inspirant divers niveaux de critique . les langages de script ultérieurs comme Ruby et Python, développés par des informaticiens, ont beaucoup plus de cohérence dans leur syntaxe. le principal problème est que le langage naturel a de grandes ambiguïtés (cela est étudié dans le domaine de la linguistique.) donc le langage naturel aura une place clé sur les futures interfaces homme-machine comme Siri mais ces interfaces seront intrinsèquement sujettes à des problèmes d'ambiguïté.

voici donc un cas où l'évolution des langages informatiques s'est éloignée d'une idée de langage naturel. de plus, l'histoire générale des langages de programmation informatique est qu'ils ont été développés et modifiés pour lever l' ambiguïté (qui est très inhérente au langage naturel). cela n'a pas été compris au début de l'histoire des compilateurs (disons peut-être dans les années 1970) et, par exemple, les premières versions du langage Fortran avaient des déclarations avec des significations ambiguës qui dépendaient de l'implémentation du compilateur. une partie de la théorie du langage CS liée à l'analyse a été développée en partie en réponse à la découverte d'une ambiguïté dans l'analyse du langage.

Le langage machine est très précis, alors qu'un texte écrit par l'homme peut généralement être interprété de différentes manières (du texte poétique par exemple).

Ce qui est de plus en plus évolué est la correspondance des modèles, par exemple lorsque vous écrivez du code laid, un compilateur peut vous aider à proposer plusieurs solutions possibles, puis lancer un avertissement ou une erreur qui peut vous aider à vous exprime. (basé sur des modèles de code communs par exemple)

Il existe des recherches spécifiques sur les modèles d'interaction / conception, même T9 et SWYPE sont des reconnaisseurs de motifs qui vous aident beaucoup (les programmes qui enregistrent votre voix et la convertissent en texte sont également des reconnaisseurs de motifs).

Bien sûr, un programme est quelque chose qui repose sur des mécanismes précis, donc vous avez besoin de langues précises (pas naturelles), alors qu'une simple recherche sur Google est très naturelle, il vous suffit de taper quelques mots et vous obtenez ce que vous voulez.

Chaque tâche et objectif différents ont leur propre langue, ce n'est pas une simple "évolution d'un seul langage", il y a beaucoup plus de langues. Les tâches précises nécessitent des langues précises et les tâches détendues nécessitent des langues détendues

Vous pouvez écrire le même morceau de code C, puis le compiler avec plusieurs compilateurs différents, et (à moins qu'un compilateur ne soit buggé), le résultat du code sera le même même si un assemblage différent est généré, tandis que pour une recherche Web, donnez le même des mots clés vers différents moteurs de recherche donnent des résultats différents.

Il y a quelques années, mon fils aîné et moi avons développé un système de programmation et de développement en anglais simple afin de répondre aux questions suivantes:

1. Les programmes de bas niveau (comme les compilateurs) peuvent-ils être écrits de manière pratique et efficace dans des langues de haut niveau (comme l'anglais)?

2. Les langues naturelles peuvent-elles être analysées d'une manière relativement "bâclée" et fournir un environnement suffisamment stable pour une programmation productive?

3. Est-il plus facile de programmer lorsque vous n'avez pas à traduire vos pensées en langage naturel dans une syntaxe alternative?

Nous pouvons maintenant répondre à chacune de ces trois questions, par expérience directe, par un «oui» retentissant.

Nous pensons que notre analyseur fonctionne comme le cerveau humain. Considérer. Un père dit à son bébé:

"Tu veux sucer cette bouteille, petit gars?"

Et le gamin entend,

"bla, bla, SUCE, bla, bla, BOUTEILLE, bla, bla."

Mais il répond correctement parce qu'il a une "image" d'une bouteille dans le côté droit de sa tête reliée au mot "bouteille" sur le côté gauche, et une "compétence" préexistante près de l'arrière de son cou reliée à la terme "sucer". En d'autres termes, l'enfant fait correspondre ce qu'il peut avec les images (types) et les compétences (routines) qu'il a accumulées, et ignore simplement le reste. Notre compilateur fait à peu près la même chose, avec de nouvelles images (types) et compétences (routines) définies - pas par nous, mais - par le programmeur, alors qu'il écrit un nouveau code d'application.

Une définition de type typique ressemble à ceci:

Un polygone est une chose avec quelques sommets.

En interne, le nom "polygone" est désormais associé à un type de structure allouée dynamiquement qui contient une liste de sommets doublement liés. Le "sommet" est défini ailleurs (avant ou après cette définition) de façon similaire; le pluriel est automatiquement compris.

Une routine typique ressemble à ceci:

Pour ajouter une coordonnée x et une coordonnée ay à un polygone: Créez un sommet étant donné le x et le y. Ajoutez le sommet aux sommets du polygone.

Notez que les noms formels (noms propres) ne sont pas requis pour les paramètres et les variables. Nous pensons que c'est là un aperçu majeur. Ma chaise et ma table du monde réel ne sont jamais (dans une conversation normale) appelées "c" ou "maTable" - je les appelle simplement "la chaise" et "la table". De même ici: "le sommet" et "le polygone" sont les noms naturels de ces choses.

Notez également que les espaces sont autorisés dans les "noms" de routine et de variable (comme "x coord"). C'est le 21ème siècle, oui? Et que les "surnoms" sont également autorisés (comme "x" pour "x coord"). Et que les possessifs («sommets du polygone») sont utilisés de manière très naturelle pour référencer les «champs» dans les «enregistrements».

Notez également que le mot «donné» aurait pu être «utiliser» ou «avec» ou tout autre équivalent, car notre analyse bâclée se concentre sur les images (types) et les compétences (routines) nécessaires à la compréhension, et ignore, autant que possible, le reste.

Au niveau le plus bas, les choses ressemblent à ceci:

Pour ajouter un numéro à un autre numéro: Intel $ 8B85080000008B008B9D0C0000000103.

Notez que dans ce cas, nous avons à la fois la plus haute et la plus basse des langues - anglais et code machine (quoique en hexadécimal) - dans une seule routine. L'idée ici est que (comme un livre de mathématiques typique) un programme doit être écrit principalement dans un langage naturel, avec des extraits appropriés dans des syntaxes plus pratiques selon les besoins (et uniquement selon les besoins).

Vous pouvez obtenir notre système de développement ici: www.osmosian.com/cal-3040.zip. C'est un petit programme Windows de moins d'un mégaoctet. Si vous commencez avec le PDF dans le répertoire "documentation", avant de parcourir dix pages, vous recompilerez tout le shebang en lui-même (en moins de trois secondes sur une machine bas de gamme de Walmart).

Les questions et commentaires doivent être adressés à gerry.rzeppa@pobox.com

La séparation des langues humaines provient de l'évolution (darwinienne?) Dans des communautés isolées. La séparation des langages de programmation provient des variations des besoins techniques, de l'idéologie technique, des changements dans la compréhension technique et théorique, des changements dans notre capacité technique à mettre en œuvre. C'est un processus un peu plus conscient, je pense.

Les langages informatiques pourraient-ils ressembler davantage aux langages naturels? Probablement un peu, jusqu'à un certain point. Je suppose qu'une grande partie de la complexité du langage naturel résulte d'une variété de phénomènes d'évolution simultanés qui n'ont aucune raison de produire un résultat cohérent à un moment donné, même s'il est probable que les anciennes incohérences soient probablement éliminées progressivement tandis que de nouvelles apparaissent. . Je ne suis pas un expert en linguistique diachronique. Mais voulons-nous ce genre de complexité dans les langages de programmation.

La question de l'ambiguïté est importante, mais pas comme l'a déclaré la plupart des gens. Une langue est un moyen de communication, et elle doit être analysée dans le contexte de cette communication (homme-homme, homme-machine, les deux, entre les lieux ou entre les temps, ... pour le dire un peu simpliste). Ce qui importe n'est pas de savoir si vous ne pouvez faire que des déclarations sans ambiguïté dans la langue, mais si vous pouvez toujours vous assurer que la communication sera sans ambiguïté dans son contexte prévu. Il existe un langage de programmation bien connu et largement utilisé, qui permet d'écrire des programmes ambigus (enfin, il l'a fait, mais je n'ai pas regardé les dernières versions depuis un moment). Dans ce cas, le compilateur est suffisamment intelligent pour détecter l'ambiguïté et demander des éclaircissements, qui peuvent être incorporés dans le programme pour éliminer l'ambiguïté. Notez que la détection d'ambiguïté ne signifie pas qu'un seul des choix possibles a un sens, ils le font tous. La question est de savoir si l'une des entités communicantes peut détecter l'ambiguïté afin que l'expéditeur puisse la clarifier. Les êtres humains sont mauvais à cela, mais les ordinateurs peuvent être assez bons.

Les formalismes et les langages de programmation pourraient avoir une syntaxe plus riche et plus flexible. Je crois que la principale raison pour laquelle ils ne le font pas est le simple conservatisme. Les outils syntaxiques utilisés sont encore très souvent des outils conçus il y a trente ans ou plus, pour répondre aux limites des ordinateurs de l'époque. L'analyse de l'efficacité n'est plus un problème critique lors de la compilation et des techniques plus puissantes existent de manière pratique.

Fait intéressant, la base la plus largement utilisée pour la syntaxe des langages de programmation provient de la recherche en langage naturel: la grammaire sans contexte. Une grande partie de la recherche technique est passée à l'informatique théorique / technique dans les années 60, pour être quelque peu redécouverte au début des années 80 par les gens du langage naturel (je simplifie). Depuis lors, de nombreux progrès ont été réalisés pour la syntaxe dans les langues naturelles, tandis que l'informatique semble largement coincée avec les anciens outils syntaxiques. Le pendule du langage naturel oscille à nouveau vers les techniques statistiques, mais les approches algébriques de la syntaxe ne sont pas oubliées. Très probablement, de bonnes approches proviendront d'une combinaison de techniques algébriques et statistiques.

Mon sentiment est que le domaine critique est la sémantique et la transition entre la syntaxe et la sémantique. Ceci est encore très difficile à formaliser pour le langage naturel, alors que nous avons de nombreuses techniques précises dans le cas des langages de programmation et des systèmes formels. Comme le jeu est loin d'être joué pour les langues naturelles, il est difficile de dire quel impact il pourrait avoir sur les langages de programmation à l'avenir.

Un autre point est que de nombreux concepteurs de langages de programmation tentent de prouver quelque chose ou d'appliquer une idéologie technique. Ainsi, ils deviennent extrêmement normatifs dans leur conception pour empêcher les utilisateurs de s'écarter de leurs paradigmes prévus. C'est malheureusement extrêmement contre-productif pour la créativité. Le langage le plus créatif jamais conçu fut parmi les tout premiers: Lisp (1958). La liberté et la flexibilité qu'il a laissées ont été à l'origine d'une créativité considérable. Le prix était qu'il fallait de l'autodiscipline et de la compréhension. Mais Lisp était vraiment un métalangage, une langue pour la création de langues.

Maintenant, pour prendre une autre perspective, les programmes sont en fait des preuves de leur spécification considérée comme une déclaration mathématique (enfin, je simplifie encore). Certaines personnes (je ne me souviens pas des références, désolé) ont joué avec des prouveurs de théorèmes pour produire des preuves qui auraient l'air d'avoir été écrites par un mathématicien en langage naturel. Je suppose donc que l'idée d'avoir des programmes qui semblent avoir été écrits en langage naturel n'est peut-être pas totalement absurde.

Vous pouvez cependant remarquer que, même lorsqu'il est écrit de manière informelle par un mathématicien, le discours mathématique est très différent d'un discours ordinaire ou d'un livre d'histoire. Cela est dû à une différence significative dans l'univers du discours concerné, les domaines sémantiques dont on parle. Ainsi, alors que vous pouvez envisager des langages de programmation qui ressemblent davantage à des langages naturels, il existe une limitation naturelle qui est le domaine du discours et ses propres propriétés souhaitables. Elle restera très probablement essentiellement superficielle, c'est-à-dire principalement syntaxique. Le mathématicien peut parler de systèmes formels et de politique. Espérons que les deux discours ne se ressembleront pas. Les ordinateurs ne peuvent pas (encore?) Parler de politique ou la comprendre. Le jour où ils le feront, ce ne sera plus de la programmation.

En regardant en arrière dans l'histoire, les langages de haut niveau étaient, dès le premier (FORTRAN), une tentative de se rapprocher d'une forme plus naturelle pour exprimer des tâches de calcul, mais ces tâches étaient comprises comme mathématiques ou logiques (Fortran 1957, Algol 1958, Lisp 1958 ), ou davantage axé sur les affaires (Cobol 1959). En moins de 10 ans, les gens s'inquiétaient des langues qui seraient plus proches, mieux adaptées au problème en question, et il y avait des recherches significatives en soi-disant extensible languages, couvrant à la fois la syntaxe et la sémantique. L'émergence de object orientation(parfois sous d'autres noms) est une voie majeure pour exprimer les problèmes de manière plus naturelle . Bien qu'il soit toujours difficile d'attribuer la parentalité, il est probablement né des travaux sur l'intelligence artificielle, principalement en lisp, et de la langueSimula 67(Famille Algol) qui était elle-même destinée à exprimer plus naturellement des problèmes du monde réel à simuler sur ordinateur. Tout semble historiquement cohérent.

Bien qu'elles soient similaires en ce que les questions posées sont similaires, elles sont assez distinctes en termes de complexité. La principale différence est que le langage naturel est intrinsèquement ambigu (même au niveau des mots). On ne sait même pas ce que l'on entend par un mot? Cependant, dans le monde des langages de programmation, une variété de dispositifs de définition sont disponibles. Regardez les grammaires pour analyser le langage naturel et celles pour analyser les langages de programmation, la différence de taille est stupéfiante. Le fait est que les grammaires des langages de programmation sont des systèmes formels; ils se prêtent donc à l'analyse mathématique. Le traitement des ambiguïtés fait apparaître de nombreux problèmes pour lesquels une solution dans l'homologue du langage de programmation serait triviale ou simple.

Peut-être que l'écart entre les langues naturelles et les langages de programmation se réduira si l'écart entre les informaticiens et les personnes "naturelles" se rétrécit.

Au cours des dernières années, l'intérêt pour les (E) DSL et les interfaces fluides n'a cessé de croître, dans une grande variété de langages: Haskell, les différents langages de script, C #, Java et même C ++ (pensez à la surcharge de operator<<pour faire la sortie).

Dans une certaine mesure, cela permet au code de lire plus naturellement. Je vais illustrer avec un exemple EDSL en groovy. Le package groovy.time vous permet d'écrire

use ( TimeCategory ) {
    // application on numbers:
    println 1.minute.from.now
    println 10.days.ago

    // application on dates
    def someDate = new Date()
    println someDate - 3.months 
}

Si vous deviez le faire via la classe java.util.Calendar, vous devriez écrire quelque chose comme ceci pour le premier exemple:

void demo() {
    Calendar date = new GregorianCalendar();
    date.add(Calendar.MINUTE, 1);
    System.out.println(date);
}

Les langages informatiques (même les langages machine rudimentaires des jours passés) sont des langages humains, car ils sont principalement destinés à la communication avec des êtres humains, sont définis par les humains et ne sont utilisés que secondairement pour transmettre des instructions à une machine. Ils évoluent donc à peu près de la même manière que les langages "naturels" (recherchez simplement les "idiomes" de votre langue préférée, vérifiez comment, par exemple, C a évolué de K&R C vers ISO-C 2011. Mais ils existent dans un environnement différent, ils doit transmettre un sens précis (les ordinateurs sont encore trop stupides pour donner un sens et corriger ce qui leur est demandé), et il y a une prime sur la facilité de traitement (ainsi la grammaire et le vocabulaire de même C ++, PL / 1 ou APL sont beaucoup plus simples que par exemple l'anglais, qui, comme les langues naturelles, est plutôt simple).

On peut dire à peu près la même chose du formalisme des mathématiques ou des sciences en général, ou même des plans (intrinsèquement 2D, pas 1D comme les autres).