Alors, il commence par une brève explication de ce qu’est Inform et un petit historique de l’IF à parser. Ça le mène jusqu’au début des années 1990, époque durant laquelle les IF commerciales se cassent la gueule, tandis qu’en parallèle, de plus en plus de gens commencent à faire de l’informatique pour le plaisir et en particulier à rédiger leurs propres œuvres de fiction interactive. Il crée la première mouture d’Inform en 1993, c’est un langage ressemblant au C, dont il compare l’ampleur à un projet d’étudiant. Du fait des retours de la communauté, il a pu rapidement l’améliorer, les versions se succèdent jusqu’en 1996 et l’arrivée d’Inform 6.
En 2003, il décide de se remettre aux FI, il décide de repartir de zéro et de créer un langage complètement différent. Avec l’aide d’Andrew Plotkin et d’Emily Short, il crée alors Inform 7, qui sera rendu public en 2006.
Depuis, I7 a acquis une bonne base d’utilisateurs, qui lui rapportent tout plein de bugs. Il doit donc gérer ses priorités, essayer de jongler entre la résolution des bugs plus ou moins grave et l’ajout de nouvelles fonctionnalités.
Ensuite, il explique le choix qu’il a fait de baser I7 sur le langage naturel.
Il nous parle de Donald Knuth, et se pose la question de savoir si un programme peut-être considéré comme un oeuvre littéraire, si on peut le lire comme on lirait un livre. Si certains programmes ont été imprimés et vendus en librairie, et s’il est facile d’accéder au texte de programmes open source, le fait est qu’on ne les lit pas comme on lirait des textes. Cela serait dû au fait qu’ils contiennent énormément de manoeuvres de bas-niveau qui rendent difficile la compréhension globale. Le fait que beaucoup de programmeurs évitent de commenter leur travail par peur de la redondance avec le code lui-même n’aide pas non plus.
Donald Knuth a théorisé le « literate programming », une méthode permettant de mêler le code et l’explication de son fonctionnement. Graham Nelson a décidé d’appliquer ce principe à I7, notamment en s’assurant que la librairie standard soit lisible et compréhensible facilement par un être humain et l’a donc incluse sous forme d’exemples courts, reproductibles et commentés.
Mais il a décidé d’aller plus loin et de se baser sur l’anglais naturel afin de mêler définitivement le code et son commentaire. Il explique ensuite comment cette approche a influencé le fonctionnement même d’I7. Il prend pour exemple les « kind » d’I7, qui se rapprochent du concept de classe en informatique, mais qui a été influencé par la façon dont les gens créent des catégories : on regroupe des individus possédant des caractéristiques semblables, puis on définit la catégorie à partir de ces caractéristiques. Cependant, il arrive que certains membres de la catégorie ne comportent pas l’intégralité des caractéristiques qui la définissent. Il prend l’exemple des oiseaux : si une des caractéristiques qu’on attribue communément aux oiseaux est qu’ils volent, on considère les autruches et les pingouins comme des oiseaux tout de même, alors qu’ils ne sont pas capable de voler. I7 imite cette façon de fonctionner avec « usually », qui permet d’assigner une caractéristique générale à un groupe, tout en laissant la possibilité d’avoir des exceptions.
Il nous parle ensuite de prédicats unaires et binaires. Le langage naturel repose énormément sur des prédicats binaires, tandis que la plupart des langages informatiques, en particulier ceux qui sont orientés-objet, ont tendance à privilégier les prédicats unaires. Il utilise l’exemple « Sophie likes purple », qui dans Inform crée un prédicat binaire, créant une relation entre une personne et une couleur. Pour simuler ce genre de comportement avec Java ou Python, il faudrait soit ajouter une méthode par personne lui permettant d’aimer les couleurs, soit ajouter une méthode par couleur pour leur permettre d’être aimées. Dans les deux cas, il ne trouve pas ça très naturel de devoir subordonner la relation à un des participants.
La façon d’émuler les adjectifs de la plupart des langages de programmation lui paraît aussi insatisfaisante, généralement, on utilise des booléens et on crée des méthodes dédiées pour évaluer ou changer leur valeur, mais comme ça ne découle pas directement du langage, ce sont les utilisateurs qui nomment les méthodes et il en résulte un manque d’uniformité dans la syntaxe qui peut causer des erreurs.
Le fait qu’I7 comprenne des formulations avec « all » permet d’éviter de créer des boucles comprenant des variables d’itération qui n’ont pas de sens concret qui viennent entraver la compréhension de la source.
Il essaye aussi de limiter au maximum l’utilisation de nombres sans dimension dans I7, on peut donc adjoindre aux valeurs numériques leurs unités, ce qui permet d’éviter de comparer une longueur à une masse.
Il remarque aussi que la plupart des langages de programmation ne connaissent que le présent, alors qu’on peut être tenté de chercher si telle ou telle condition a été vraie dans le passé. I7 comprend donc certaines phrases au passé, par exemple pour savoir si le joueur est déjà passé dans une pièce précise. Le problème, c’est que certaines formulations en anglais naturel sont ambiguës, cet aspect d’Inform est limité.
Certains langages de programmation font un usage intensif de la ponctuation, ce qui leur permet d’être très précis, mais qui limite leur lisibilité.
Il termine sa première partie en comparant les avantages et inconvénients de ce choix du langage naturel pour I7. La deuxième partie parle plus du développement d’I7 depuis 2015, mais j’ai pas le courage de mal traduire / résumer ça maintenant… Déjà que sur la fin, c’est vraiment pas très clair ce que j’ai écrit, on va limiter la casse