Discussion :

[schnee]

>>car il y a toujours une ambigüité et une plurivocité du sens dans les signifiants.

Fort juste. Et l'anglais, qui serait probablement la première langue à être utilisée dans ce contexte, est l'une des plus ambigües.
Il suffit de voir comment les ordinateurs à l'heure actuelle traduisent des textes d'une langue à l'autre pour douter qu'ils soient bientôt prêts à comprendre en plus ce qu'ils reçoivent.

[abgech]

Oh, la, la, le langage naturel, une très vieille lune.

Le COBOL, de 1959 (!) était déjà basé sur cette idée. Extrait de l'article COBOL de wipipédia :
Le parti-pris initial de définir un langage de programmation proche du langage naturel (comme pour FLOW-MATIC) devait faciliter, sinon la programmation, du moins l'audit des programmes COBOL par des gestionnaires non-informaticiens.

Et l'on sait ce qu'il en advint.

[Jilkaren]

Plus qu'un véritable langage, je vois ici une opportunité de créer des "filtres" complexes. Je m'explique :

Il arrive souvent dans un programme qu'on veuille donner la possibilité à un utilisateur de créer ses propres fonctionnalités. On peut prendre comme exemple les filtrages des boîtes mail, les systèmes d'intégration / tri dans une base de données, ou encore les diverses applications (je pense notamment en carto) qui permettent à l'utilisateur de créer des boites / chaines de traitement pour modifier une donnée.

Aujourd'hui, pour réaliser ça, soit :
1 - On offre un "cliquo-drome" à l'utilisateur, une interface lourde et pas toujours super intuitive,
2 - On utilise un petit langage (souvent maison d'ailleurs), dont on donne la syntaxe à l'utilisateur, et à lui de créer un script qui exécute ce qu'il veut.

Donc, avec les travaux du MIT, on pourrait juste demander à l'utilisateur de formuler en bon anglais (et j'espère un jour en bon français xD ) ce qu'il souhaite rééaliser et ... Tada ! C'est transformé en code exploitable par l'application source.

En bref, on permettrai à l'utilisateur une expérience intuitive, et ça éviterai (peut être) au programmeurs de faire un binding compliqué derrière.

[Matthieu Vergne]

L'évolution vers ce genre de langage "naturel" me semble on ne peut plus normal, vu qu'on cherche toujours à faire des langages de plus haut niveau pour abstraire plus facilement et se rapprocher du langage naturel. Par exemple en Java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (path1.isShorterThan(path2)) return path1 else return path2

C'est quand même très proche de l'anglais comparé à de l'assembleur. L'expressivité des langages d'aujourd'hui permet de facilité grandement la compréhension.

Là où le bas blesse c'est toujours sur l’ambigüité de la langue naturelle. Là où le progrès serait énorme, c'est surtout sur la capacité du langage à identifier ces ambigüités (là où il trouve plusieurs interprétations possibles) et les signaler au designer qui pourra alors améliorer sa spec grace à des questions automatiquement générées. La méthode de ces chercheurs dans ce cas n'est pas la bonne, car un apprentissage fera que l'interprétation sera choisie de manière probabiliste. Ça ne nous dira pas quand quelque chose est pas clair ni ça ne nous proposera différentes interprétations. La rigueur du programmeur restera donc nécessaire pour éviter de "dire" n'importe quoi au compilateur.

C'est les même méthodes qu'on utilise en traduction automatique : un apprentissage est fait et la traduction est générée en fonction... Perso j'utilise pas Google Trad pour me traduire des phrases entières, uniquement pour voir les différentes traductions d'un mot ou d'une petite expression. Le problème ici est le même, ça manque de fiabilité quand l'interprétation n'est pas unique.

Je me demande par exemple comment serait traduit sous forme de code "La barre de navigation doit être de couleur rouge. Celle de notification doit être encore plus rouge lorsqu'une notification apparait.". Des rouges, il y en a beaucoup en RGB 24 bits par exemple. Fait jouer ta subjectivité.

[Cafeinoman]

Même si leur boulot n'en est qu'à ces début, l'idée est je pense d'en arriver à ce type de scénario :
"Ma mamie va chercher son pain. En sortant, elle dit à l'ordi de sa maison de préparer le café pour qu'il est fini de passer 30min après son départ (comme ça il est fait et pas froid quand elle rentre). Si quelqu'un dans la liste autorisé sonne avant, il faut lui ouvrir et faire le café tout de suite."
Et voilà, ma mamie à codé son petit script. Ok je suis pas super imaginatif sur ce coup là, mais à mon avis, en terme d'application pour le scriptage des appareils domotiques, il y a de l'idée dans leur trucs. Même si ça n'ira jamais effectivement très loin...
Et puis l'algorithmique finira bien par être une langue obligatoire dans le secondaire de toute façon !

[Matthieu Vergne]

Pour un ensemble de tâches prédéfinies c'est clair que ça peut servir. Cela dit ils sont sur du bas niveau (construction de regex), pas dans du haut niveau (contrôle de dispositifs). Pour de la domotique, on rejoint le contrôle vocal qu'on trouve déjà sur certains smartphones. Ce travail là je le vois plus comme quelque chose qui suit les même principes mais pour une utilisation bien différente.

[Cafeinoman]

Pour un ensemble de tâches prédéfinies c'est clair que ça peut servir.

Oui, ça ça existe déjà. Ma grand-mère programme effectivement son disque dur pour enregistrer "Question pour un Champion" quotidiennement.

Je crois qu'en prenant une conditionnelle aussi simple, j'ai mal illustré! L'idée était que son petit "si" devenait une condition dans le déroulement normal de l'opération. Le vocal est traduit en texte, transformé en regex, qui permet de générer un algorithme à la volée.

Meilleur exemple :

Je vais faire des courses, il faut du café quand je rentre. Et fait le ménage. Et si quelqu'un arrive, fait du café et appel moi.

passe par la régex qui génère au final

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
while(maison.occupants()=Maison.VIDE){
	robotmenager.run();
	if(gpsVoitureMamie.eta()<cafetiere.tempsPourFaire())
		{cafetiere.faireCafe();}
}
if(sonette){
	if(!personneConnues.verifier(sonette.personneQuiSonne()){
		sonette.messageAbsence();
	}else{
		maison.addOccupant(sonette.personneQuiSonne());
		cafetiere.faireCafe();
		prevenirArriver(ModeCom.SMS, sonette.personneQuiSonne());
	}
}

Si ça ça se fait déjà, je vois pas pourquoi je me tue à faire du Java... (je sais, ça chatouille le troll comme remarque). Mais plus sérieusement, même si on est encore dans du "simple" (pas u peu d'ambiguité dans la formulation), il y a quand même un truc dans leur idée.

Après je suis d'accord avec toi sur les limites des programmes par apprentissage. Je pense qu'il faudrait beaucoup de développeur, d'ethnologue, de linguistes et de statisticien pour obtenir une base suffisante pour prendre des décision, mais des trucs du genre "du café ça doit être chaud", ça peut se faire.

Mais à l'heure de l'internet des objets et quand tout le monde veut sa nouvelle IHM (tactile, kinect, Google Glass), je pense que ce n'est pas à négliger.

[Myder]

Je pense que cet initiative c'est juste une banalisation du métier de programmeur. A coté des aspects qu'on peut trouver intelligent de leur part, il faut aussi comprendre que finalement un programmeur ça ne voudra rien dire dans le futur. FOUTAISE!!!