L'article n'est pas terrrible parcequ'il passe à côté de plein de points assez évidents dont il serait pourtant assez facile de parler dans un journal tout public. Il est difficile d'y voir autre chose qu'un coup de pub un peu perso du "directeur du laboratoire."
Voilà tous les points qui viennent en tête de façon (presque) immédiate en lisant l'article:
Dire que la programmation WYSIWYG réduirait les bugs dans les programmes est un peu pipo. Il y a des milliers si ce n'est des millions de personnes qui programment en WYSIWYG tous les jours et qui ne sont pourtant pas à l'abri des bugs, même les plus simples: il s'agit des utilisateurs de tableurs. Les tableurs les plus connus ne disposent pas d'un mode "plan" qui permettrait de lire (coucou le texte!) l'ensemble des définitions d'une feuille de calcul pour vérifier sa cohérence.
L'article ne parle pas du tout d'autres approches pour réduire les bugs, comme le typage statique, les méthodologies montantes pour l'analyse du code (certaines basées sur l'IA), les fuzzers, les mélangeurs de mémoire, etc.
L'article ignore totalement que tous les langages ne suggèrent pas des modes de développement identiques, par exemple en Common Lisp on développe de façon interactive, c'est quasiment du WYSIWYG avec un point focal.
Visual Studio, c’est plus de 55 millions de lignes de codes, et 98% d’entre elles ne sont pas pertinentes, estime Granger. Le problème est que c’est un assemblage de plein de travaux différents et pour le comprendre, le parcourir, pour un informaticien, il faut être capable de jouer les fonctions qu’on rencontre dans sa tête. C’est comme jouer aux échecs avec un bandeau sur les yeux : l’essentiel de l’énergie est dépensé à avoir une représentation des pièces et de leurs mouvements... tant et si bien qu’il ne reste plus d’énergie mentale pour penser au jeu lui-même.
Le paragraphe que je cite est complètement faux, la première fois que j'ai utilisé un débogueur visuel c'était en 1999 ou 2000... aux dernières nouvelles, ça existe toujours et tous les programmeurs connaissent ce genre d'outils – même s'ils ne sont pas forcément disponible pour tous les langages.
L'idée de programmer en utilisant un logiciel WYSIWYG est par ailleurs loin d'être nouvelle:
Le programme "concept" sensé illustrer le propos de Victor Bret, le directeur du laboratoire, semble être une réimplémentation dans un navigateur du logiciel de géométrie interactive CABRI qui existait dès la fin des années 90. Il y a plein de variations sur ce type de programme, il y en avait un clone dans KDE, etc.
Un outil de programmation interactive plus grand public que le CABRI est l'Automator d'Apple. En gros les diverses applications compatibles avec ce système exportent des traitements. Par exemple l'opération "Choisir des fichiers" de l'explorateur de fichiers, l'opération "Filtre Sépia" de l'application de visualisation d'image et l'opération "envoyer un mail" de l'application de messagerie. Le logiciel Automator permet de combiner ensemble ces opérations pour obtenir des chaînes de traitement, et on peut attacher ces traitements à certaines évènements du système, par exemple pour que le traitement se déclenche pour les fichiers déposés dans un dossier qui devient "magique". Cela existe depuis 2004 et même si les traitements sophistiqués ne sont pas possibles (il n'y a qu'une seule branche de traitement) cela fournit une offre convaincante pour concevoir des traitements par lot simplets.
À la fin des années 90 un copain de fac m'avait parlé d'un logiciel qu'ils utilisaient pour concevoir les circuits électroniques, qui était exactement un environnement de développement WYSIWYG – certes non généraliste. Certains participants de LinuxFR connaissent certainement par cœur ce type de logiciel!
Plus proche de nous, les développeurs utilisant React ont à leur disposition quelques outils qui leur permettent de faire du développement interactif.
Pour être clair je pense que l'idée de faire du développement interactif avec un outil visuel permettant d'ajuster des blocs entre eux est en soi pertinente, mais si on veut être pris au sérieux en tant que chercheur sue le sujet, il me semble plus judicieux de proposer un environnement qui permettrait de développer une application relativement ambitieuse en guise de prototype plutôt que de refaire un truc qui date des années 90. Cela permettrait de montrer comment on résout de cette façon là des problèmes auxquels sont confrontés les programmeurs. (Bref de s'intéresser un peu au nœud du problème!)
Du coup on se demande ce que fait réellement dans la vie Victor Bret. Est-ce un agent de la CIA qui a une couverture de chercheur en systèmes automatiques? Est-ce que cela vaut le coup de lire les articles de James Somers dans The Atlantic? (Qui à la différence du blog qui en rapporte le propos ont une prétention journalistique!) Est-ce que ça vaut le coup de traduire ces articles en français?
# Article pas terrible
Posté par Michaël (site web personnel) . En réponse au journal [liens] Mais juste un. Évalué à 10. Dernière modification le 26 novembre 2017 à 19:45.
L'article n'est pas terrrible parcequ'il passe à côté de plein de points assez évidents dont il serait pourtant assez facile de parler dans un journal tout public. Il est difficile d'y voir autre chose qu'un coup de pub un peu perso du "directeur du laboratoire."
Voilà tous les points qui viennent en tête de façon (presque) immédiate en lisant l'article:
Dire que la programmation WYSIWYG réduirait les bugs dans les programmes est un peu pipo. Il y a des milliers si ce n'est des millions de personnes qui programment en WYSIWYG tous les jours et qui ne sont pourtant pas à l'abri des bugs, même les plus simples: il s'agit des utilisateurs de tableurs. Les tableurs les plus connus ne disposent pas d'un mode "plan" qui permettrait de lire (coucou le texte!) l'ensemble des définitions d'une feuille de calcul pour vérifier sa cohérence.
L'article ne parle pas du tout d'autres approches pour réduire les bugs, comme le typage statique, les méthodologies montantes pour l'analyse du code (certaines basées sur l'IA), les fuzzers, les mélangeurs de mémoire, etc.
L'article ignore totalement que tous les langages ne suggèrent pas des modes de développement identiques, par exemple en Common Lisp on développe de façon interactive, c'est quasiment du WYSIWYG avec un point focal.
L'idée de programmer en utilisant un logiciel WYSIWYG est par ailleurs loin d'être nouvelle:
Le programme "concept" sensé illustrer le propos de Victor Bret, le directeur du laboratoire, semble être une réimplémentation dans un navigateur du logiciel de géométrie interactive CABRI qui existait dès la fin des années 90. Il y a plein de variations sur ce type de programme, il y en avait un clone dans KDE, etc.
Un outil de programmation interactive plus grand public que le CABRI est l'Automator d'Apple. En gros les diverses applications compatibles avec ce système exportent des traitements. Par exemple l'opération "Choisir des fichiers" de l'explorateur de fichiers, l'opération "Filtre Sépia" de l'application de visualisation d'image et l'opération "envoyer un mail" de l'application de messagerie. Le logiciel Automator permet de combiner ensemble ces opérations pour obtenir des chaînes de traitement, et on peut attacher ces traitements à certaines évènements du système, par exemple pour que le traitement se déclenche pour les fichiers déposés dans un dossier qui devient "magique". Cela existe depuis 2004 et même si les traitements sophistiqués ne sont pas possibles (il n'y a qu'une seule branche de traitement) cela fournit une offre convaincante pour concevoir des traitements par lot simplets.
À la fin des années 90 un copain de fac m'avait parlé d'un logiciel qu'ils utilisaient pour concevoir les circuits électroniques, qui était exactement un environnement de développement WYSIWYG – certes non généraliste. Certains participants de LinuxFR connaissent certainement par cœur ce type de logiciel!
Plus proche de nous, les développeurs utilisant React ont à leur disposition quelques outils qui leur permettent de faire du développement interactif.
Pour être clair je pense que l'idée de faire du développement interactif avec un outil visuel permettant d'ajuster des blocs entre eux est en soi pertinente, mais si on veut être pris au sérieux en tant que chercheur sue le sujet, il me semble plus judicieux de proposer un environnement qui permettrait de développer une application relativement ambitieuse en guise de prototype plutôt que de refaire un truc qui date des années 90. Cela permettrait de montrer comment on résout de cette façon là des problèmes auxquels sont confrontés les programmeurs. (Bref de s'intéresser un peu au nœud du problème!)
Du coup on se demande ce que fait réellement dans la vie Victor Bret. Est-ce un agent de la CIA qui a une couverture de chercheur en systèmes automatiques? Est-ce que cela vaut le coup de lire les articles de James Somers dans The Atlantic? (Qui à la différence du blog qui en rapporte le propos ont une prétention journalistique!) Est-ce que ça vaut le coup de traduire ces articles en français?