Dans son excellente conférence au titre de « The Future of Programming », Bret Viktor s'imagine à la fin des années 60, alors que les idées autour de l'informatique fusent, et prédit ce qu'aurait pu être l'évolution de ces idées.

Bret Viktor est un excellent conférencier, son classique « Inventing on Principle » avait déjà fait une petite sensation.

Il faut dire que ses conférences inspirent et motivent. Elles donnent à réfléchir, voire parfois à rêver.

Bret Viktor se place donc dans une démarche de comparaison de ce qui aurait pu être et de ce qui est. C'est avec un grand sérieux et dans un costume qui évoque les débuts de l'informatique qu'il annonce ce qui, à la vue des progrès récents, ne manquera pas de se produire.

Tout cela, bien entendu, pour montrer que le présent réel n'est pas allé dans les directions qu'il indique. Tout en supposant qu'on aurait peut-être pu y aller. Et poser la question en filigrane : est-ce qu'on ne se laisserait pas aller au confort de choses qui fonctionnent, sans aller chercher de la nouveauté, bousculer nos paradigmes, inventer ?

Ce thème est repris par la conclusion, parfois incomprise au point qu'il l'explique longuement dans sa très complète page de références¹, est « The most dangerous thought you can have as a creative person is to think you know what you're doing. »

Réfléchir à ce que l'on fait, essayer de nouvelles choses, progresser et faire progresser. Ce sont des choses qui résonnent. Mais est-ce que les solutions qu'il évoque auraient vraiment pu évoluer vers une utilisation et une adoption grandissante ? Bret Viktor ne l'affirme pas.

Le discours repose sur la mécanique d'une projection linéaire des progrès passés vers les progrès futurs, à même vélocité. Or, et c'est écrit dans ses références et notes, l'époque décrite est une époque d'effervescence : on teste tout, on tâtonne, on innove. Mais cette effervescence et ces essais diminuent avec le temps.

Est-ce à cause d'un immobilisme ? D'un manque de créativité ? D'une population de programmeurs se contentant de reproduire des recettes apprises ? Je ne crois pas que ce soit la seule raison.

Avec le temps, l'informatique s'est diversifiée et ses domaines se sont spécialisés. Beaucoup de méthodes ont subies l'épreuve du feu, l'épreuve de la montée en puissance, l'épreuve de l'utilisation réelle. Et beaucoup de ces méthodes se sont révélée ne pas pouvoir supporter la charge. Ou, pour être plus optimiste : pas encore.

Nous ne sommes pas encore prêt à appliquer ce que l'on peut finalement appeler preuve de concept à des ensembles de problèmes plus large. Ou encore, cela fonctionne, mais ce n'est économiquement pas viable. Autrement dit : d'autres méthodes, moins élégantes, restent tout de même plus efficaces à appliquer.

Les chercheurs existent pourtant, des gens qui publient des articles sur des manières de faire, d'autres manières de penser. Et l'étude de l'évolution montre que la programmation et ses paradigmes évoluent toujours.

La vitesse d'évolution et de nouvelles découvertes diminue avec le temps. Cela me semble se retrouver dans d'autres secteurs : plus on en connaît sur le sujet, moins on trouve. Jusqu'à la prochaine découverte qui change complètement la donne.

Feuilles de styles et balisage

Bret Viktor parle de feuilles de style et de langages à balises comme quelque chose qui n'existera pas dans le futur, c'est-à-dire maintenant, et le spectateur réagit comme prévu : il rit.

Cependant, sommes-nous prêt à détecter automatiquement la mise en forme d'un document tel que l'utilisateur l'imagine ?

Les traitements de texte ont offerts des possibilités de « style automatique » essayant de déterminer la structure d'un document automatiquement. Les résultats ne sont pas très probants.

Le programme n'a d'autre choix pour le moment de demander à l'utilisateur la structure du document, au moins dans les grandes lignes. Mais les balises ne sont pas obligatoires et même, elles ne sont pas souhaitables dans les cas d'utilisation les plus courant. C'est pour cela que de nombreux formats de textes de mise en forme dite « naturel », ont été développés. Markdown, reStructuredText, MediaWiki et autres.

Les traitements de textes ont aussi montré que l'utilisation des styles était pour l'utilisateur le seul moyen de traiter des textes importants en ayant la possibilité de garder la main sur des modifications de style à grande échelle. L'inverse, modifier le style localement, s'avère non maintenable et à réserver à de petites productions.

Et pour le moment encore, un programme, tout en proposant un style par défaut, ne peut pas lire dans l'esprit de l'auteur afin de savoir si le fond de la base doit être blanc ou gris.

Ces feuilles de styles, côté Web, se débarrassent elles-aussi de leur balises à travers des technologies comme SASS ou Stylus.

Échafaudage de langages

L'historique de l'acceptation des langages de plus en plus haut niveau qu'expose la conférence est très instructif. Chaque nouveau paradigme, chaque nouvel « étage » d'abstraction de la programmation de la machine est d'abord perçu comme inutile par les habitués des couches précédentes.

La conférence tant à supposer qu'à l'heure actuelle, on devrait déjà en train d'être programmer en déclarant ce que l'on veut atteindre plutôt que comment l'atteindre. Ou bien au moins en manipulant des blocs et structures qui s'imbriqueraient naturellement.

Nous n'y sommes pas, et pourtant, ce ne sont pas les tentatives qui manquent.

Quoi, pas comment

La programmation par manipulation, pour commencer. Celle-ci existe, mais généralement se cantonne à un domaine métier précis. La programmation nodale fonctionne très bien avec les descriptions de « shaders »², ou de la description procédurale graphique.

Dès que le domaine se complexifie, comme par exemple la programmation de comportements dans des jeux vidéos, les problèmes commencent : la création de nouveaux comportements est simple, naturelle, mais lorsque l'ensemble des comportements sont mis ensemble, le système ressemble très rapidement à un plat de spaghettis, où il est très difficile de tracer le fonctionnement.

Ces systèmes se complexifient au fur et à mesure qu'ils deviennent généralistes.

Dans la programmation par règles d'inférence et déclaration des buts à atteindre, de nombreuses recherches ont été faites. Et s'il est vrai que l'ajustement mental pour passer d'un langage impératif à un langage à inférence peut bloquer leur acceptation et leur développement, ce n'est pas le seul frein à leur adoption.

Car il est toujours nécessaire, au moins pour une partie de la population des programmeurs, de définir le comment. En effet, chaque nouvel « étage » d'abstraction ne rend pas le précédent obsolète. Juste plus marginal. Si le nouvel étage apporte un réel gain de temps pour des résultats au moins à peu près identiques, alors il est accepté.

Millefeuille

Pour reprendre l'exemple de la conférence. Lors de l'arrivée des langages d'assemblages, il a toujours fallu des gens pour écrire les assembleurs et les porter sur les différents matériels, travailler sur les optimisations du code généré.

Lors de l'arrivée du Fortran, il a fallu écrire le compilateur, c'est à dire la transformation du Fortran vers un langage d'assemblage lui-même transformé en code machine.

Et les étages ont continué à s'empiler, se construisant chacun sur les piliers du précédent. Les gains n'ont d'ailleurs pas été perçus systématiquement au début de certaines évolutions, et le barycentre de l'Histoire de la programmation ne s'est pas dirigé vers des langages généralistes permettant d'écrire le « quoi » plutôt que le « comment ».

Si on continue l'historique de Bret Viktor, on peut parler de l'arrivée des « Garbage Collector »%%ensemble de procédés qui permettent de nettoyer automatiquement la mémoire de l'ordinateur des structures dont le programme n'a plus besoin.%% ou des compilateurs « Just In Time »%%la dernière phase de compilation en code machine natif est faite juste avant l'exécution réelle... juste à temps%%, beaucoup de sceptiques ont considéré que l'exécution serait plus lente pour des gains inexistants.

Même si beaucoup de tests prouvant à montrer la supériorité de ces systèmes ont travaillé dans le sens inverse par leur manque d'honnêteté, les gains existent. Ces systèmes ne conviennent pas à tous les domaines, mais ont pris d'assaut en grand nombres d'entre eux, à commencer par le plus visible : la programmation Web en Javascript.

Et pourtant, tous les étages précédents existent toujours.

Le Javascript est compilé vers une machine virtuelle (qui utilise un « garbage collector » et parfois de la compilation « just in time »), qui elle même est programmée en C++ (par exemple), qui lui même est compilé en assembleur qui a été transformé en code machine.

Et les programmeurs spécialistes de tous ces étages existent et sont nécessaires, car le matériel sur lequel s'exécute tout ceci est loin d'être immuable. Au contraire.

Un milieu du chemin

Actuellement, il existe des méthodes qui se situent à mi-chemin vers la programmation par contraintes, à décrire les buts. Le TDD (Test Driven Developement) classique ou basé sur les propriétés, le BDD (Behavior Driven Developement) sont des manières de décrire le quoi avant d'écrire le comment.

La but ultime n'est donc pas perdu de vu. Mais, telle une mise en abîme du TDD, l'informatique fonctionne par « Baby Steps » en connaissant le but et en implémentant le comment.

Le futur, toujours à venir

Lire des visions futuristes venues du passé est toujours instructif. « Le Futur antérieur, souvenirs de l'an 2000 » (ISBN : 208012157X) nous montre l'an 2000 vu 50 à 100 ans auparavant. Ce livre est fantastique. Parfois, cela touche juste, mais le plus souvent c'est très étonnant. Et s'il est inquiétant que « 1984 » d'Orwell (ISBN : 207036822X) soit pris comme mode d'emploi par certains de nos contemporains, la grande majorité du roman d'anticipation vise trop court.

Pour se rapprocher de l'informatique, lire d'anciens magazines est instructif. Les prévisions sont toujours très optimistes. Dans « Jeux & Stratégie », j'ai retrouvé un article d'un de mes professeurs prévoyant l'époque à laquelle un joueur de Go professionnel pourrait être battu par un ordinateur. Optimiste, aussi.

La réussite de la conférence de Bret Viktor passe aussi par cet optimisme. Il triche un peu, vu qu'il connaît bien le futur qu'il décrit.

Et cela aiguillonne un peu.