Bret Victor, connu pour une présentation qui a inspiré le projet Kickstarter d'IDE "LightTable", a mis en ligne en ce mois ci un nouvel essai en anglais sur le sujet des environnements de développement et des caractéristiques nécessaires pour les rendre ergonomiques et efficaces.
L'argumentaire, parfois tranchant, ne laissera personne indifférent. L'article est néanmoins très lisible et illustré de courtes animations et vidéos.
http://worrydream.com/LearnableProgramming/
Je ne peux pas résumer l'article dans ce journal, aussi je reprend juste les points avec lesquels je me sens le plus en phase :
l'environnement doit faire son maximum "montrer" et expliquer le sens des composants du langage, y compris en utilisant des représentations temporelles et des métaphores. L'outil ne peut pas démarrer sur un écran vide, mais sur une boite à outils prête à l'emploi. L'objectif est de rendre les API doivent être "transparentes".
l'environnement doit particulièrement faciliter la composition et la décomposition des procédures, et la création de nouveau composants par spécialisation et généralisation de composants existants, mais là j'avoue que je ne vois pas encore quelle genre d'interface permettrait cela pour les développements commerciaux courants.
Le développement par itération successive nécessite un système persistant
('there is no future in destroy-the-world programming')
Je regrette qu'une personne qui semble si douée ne se lance pas elle même dans la réalisation de ses idées. Je trouve difficile à avaler que Bret critique durement les efforts des autres sans tenter lui même de réaliser sa vision. A moins que j'ai raté un épisode ??
Autres liens connexes :
J'ai trouvé cet article sur le google-groupe 'augmented-programming'
Démo de Bret Victor : 'Inventing on Principle' : http://vimeo.com/36579366
Projet LightTable sur Kickstarter : http://www.kickstarter.com/projects/ibdknox/light-table
Site de Bret : http://worrydream.com/
# Le faire, c'est mieux quand c'est possible...
Posté par arnaudus . Évalué à 6.
Je pense que tu as tout à fait compris le truc : la plupart des fonctions suggérées sont proprement impossibles à implémenter. La seule qui me paraît à la limite faisable, c'est la documentation automatique, mais il faut pour cela que l'auteur de la bibliothèque ait respecté un standard particulier.
Le gros risque de se lancer dans un tel logiciel à documentation intégrée, c'est qu'il va fonctionner pour "for" et pour "return", mais pas pour Toto::dothis(), alors qu'évidemment, après une semaine de programmation, on n'a plus besoin des premiers.
L'autre truc, c'est qu'il est souvent impossible de décrire les paramètres de manière concise. C'est bien beau de mettre un exemple "rect(10,5,12,8)", avec "10: abscisse du point supérieur gauche". Mais c'est un exemple purement scolaire, très souvent, la vraie doc pourrait ressembler à "10: par défaut, abscisse en pixels du point supérieur gauche. Si Options.cm == TRUE, alors 10 est l'abscisse en cm. Si négatif, le rectangle débutera hors du cadre, sauf si Options.overlay == 2 (le cadre ne limite pas le rendu des formes sauf le cadre extérieur). Si l'absisse en pixels est un nombre réel, il est tronqué (et non arrondi).".
Tout ceci est donc plein d'idées, les vidéos fonctionnent bien, mais au final, ça fait un peu "logiciel magique" qui ne peut pas être implémenté.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par Ontologia (site web personnel) . Évalué à 2.
Je suis assez d'accord, le problème fondamental, c'est qu'on peut difficilement demander à la machine d'extraire une sémantique du code qu'elle traite, et de la traiter.
Dans son exemple, il a géré la sémantique des fonctions de dessins basique : créer un rectangle, un disque, etc… Mais quand il va devoir s'attaquer au vast monde, ça va être plus dur.
Je pense que cette (très bonne idée) va être tranquillement digérée dans les années à venir, en commençant par les interfaces.
Si on veut passer la marche d'après, il va falloir sauter un gouffre : mettre de l'IA et une ontologie dans l'IDE.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par arnaudus . Évalué à 2.
Mouais, en gros il faudrait que l'IDE comprenne plus de trucs que le compilo. Imaginer ça pour un langage comme C++ me semble assez absurde.
Et puis, à mon avis, le principal problème des programmeurs débutants (et même des autres), ce n'est pas de comprendre comment une fonction fonctionne, c'est de comprendre que cette fonction existe et de connaitre son nom. Du coup, il faut forcément la doc sous le nez, et l'explication des paramètres devient secondaire. Toute cette machinerie de sémantique ne peut donc qu'aider à comprendre du code existant ; pour reprendre les exemples, si le programmeur ne connait pas ellispe et rect, il n'aura jamais accès à la doc.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par Gof (site web personnel) . Évalué à 3.
Justement, le C++ est parfait pour ça. Vu que c'est statiquement typé, un bon IDE peut savoir beaucoup de chose à propos de chaque fonction ou type.
Ça permet notamment d'afficher plein d'informations intéressantes, comme la documentation doxygen par exemple dirrectment dans le tooltip.
Et aussi faire de l'autocompletion sémantique qui donne toutes les information.
C'est pour ça que j'adore KDevelop.
(J'aime tellement KDevelop que j'ai même fait une version online pour lire le code: http://woboq.com/blog/codebrowser-introduction.html )
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
rect( x: 10px, y: 1px, width: 100px, height:200px ) ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par reno . Évalué à 2.
Oui, dommage que beaucoup de langages ne supportent pas ce type d'appels de fonction, ça me parait quand même beaucoup plus lisible.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par arnaudus . Évalué à 2.
Je suis complètement d'accord : d'une part c'est beaucoup plus lisible, et d'autre part on n'a pas à connaitre l'ordre d'appel des paramètres (et on peut omettre ceux qui sont au milieu s'ils sont définis par défaut).
Ça peut être sympa de mettre l'unité aussi, je n'y avais jamais pensé. La seule méthode qui s'y rapporterait serait d'appeler un constructeur dans les langages orientés objet:
rect(cm(10.3), pixel(32));
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
rect().x(1).y(2).width(12).height(23)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par BFG . Évalué à 2.
Vous risquez d'en oublier un, et l'erreur ne sera pas vue à la compilation.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par arnaudus . Évalué à 1.
Si je comprends bien, les méthodes x(), y(), etc. renvoient des objets de classe rect? Concision mise à part, ça revient au même que:
C'est ingénieux, mais je me demande si ça ne fait pas trop "usine à gaz", et si les performances sont maintenues par rapport à l'appel d'une fonction simple. L'avantage, c'est que ça permet d'avoir des paramètres par défaut, mais il semble un peu plus difficile d'avoir des paramètres obligatoires (le constructeur par défaut doit mettre des flags à FALSE et détecter au moment d'utiliser l'objet si les variables ont été initialisées?).
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par ckyl . Évalué à 2.
Ca se nomme un builder et c'est très utilisé dans les langages qui ne permettent pas le nommage des paramètres et les valeurs par défaut pour éviter les constructeurs imbitables avec 30 paramètres.
Example: http://www.drdobbs.com/jvm/creating-and-destroying-java-objects-par/208403883?pgno=2
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par BFG . Évalué à 3.
Pour remplacer des paramètres optionnels (ou éviter de nombreuses surcharges au constructeur), ça peut être utile, mais pour des paramètres obligatoires (comme les x, y, largeur, hauteur d'un rectangle), c'est une mauvaise idée, car le code compilera encore même si l'on oublie ".x(1234)".
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par fearan . Évalué à 4.
et ça permet de créer un objet incomplet qui pétera lorsqu'on devra utiliser un truc en plus qu'on avait pas prévu à l'origine.
Je hais les constructeurs vides. Ça oblige à avoir un tas de code de vérification (alors oui on peut en début de chaque fonction faire un appel isOk, isValide, isCorrecte…), mais si on interdit la création d'objet incorrecte c'est mieux non?
Si le constructeur à tant de paramètre qu'il devient imbitable et illisible, peut être qu'il faudrait faire des sous classe non?
Un constructeur avec 30 paramètre j'ai jamaisvu, et pourtant j'en ai vu du code, (dont des template avec plus de 30 paramètre Template. )
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par ckyl . Évalué à 2. Dernière modification le 27 septembre 2012 à 17:19.
Tu n'as juste rien compris au pattern builder. Le constructeur vide il est sur le builder pas sur l'objet. Et tu verifies la validité de la config au moment ou tu retournes l'objet. Et génial ca simplifie aussi la création des objets immutables qui ont pas mal de variables internes. C'est justement ce type de pattern qui te permet de te passer des vérifications au court de l'utilisation.
Aller un exemple gratos: http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/CacheBuilder.html
Une fois que ton cache est construit tu ne peux plus le reconfigurer afin de rester dans un état cohérent. Tu m'expliqueras comment tu fais ca sans builder et sans une API immonde; y'a juste une quinzaine de paramétrage possibles.
Oh 5 ou 6 paramètres suffisent. Il suffit d'avoir 5 bool dans le tout pour faire un truc illisible et casse gueule.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par fearan . Évalué à 3. Dernière modification le 27 septembre 2012 à 17:34.
Bof pour 5 boolléen, tu peux très bien faire 1 paramètre par ligne suivi d'un // estLetal ou // estLiquide. On est pas non plus obligé de faire un gros truc de porcasse hein.
J'ai rien contre les builders, mais les mettre à toutes les sauces, comme j'ai tendance à le voir dans le code, ça rend le truc illisible, y a pas moyen de créer un objet simplement, tout passe par un builder ou une factory, ou un constructeur vide.
Et passer par un builder pour un rectangle, c'est légèrement overkill.
Récemment j'ai du rajouter un passage message en java. J'ai du modifier plus de 12 classes! Ah les pattern étaient bien appliqué même un peu trop je pense.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par ckyl . Évalué à 1.
Le code ca se maintient sur 10 ans et plus. Le truc qui te parait évident, le sera pas forcément pour le gars qui se tapera un refactoring 5 ans plus tard. On essai donc d'utiliser la méthode qui sera le moins casse gueule. Et comme souvent ca dépend du contexte.
Bha si puisque tu dis des choses honteusement fausses comme "et ça permet de créer un objet incomplet qui pétera lorsqu'on devra utiliser un truc en plus qu'on avait pas prévu à l'origine.".
Comme tout ca s'utilise intelligemment, c'est un outil. Dire qu'il ne faut pas l'utiliser quand ce n'est pas approprié c'est enfoncer une porte ouverte.
Le problème c'est donc les devs pas l'outil. Change de devs…
Je te propose toujours de me faire une API équivalente du Cache. Tu disais que tu n'avais jamais vu de classe nécessitant un builder de toute ta longue carrière. Pourtant des classes du type de Cache j'en croise et j'en écris régulièrement.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par fearan . Évalué à 2.
Pour ce truc la, création de classe en passant une structure de paramètres, mais bon il est vrai que généralement je crée en c++; et je n'ai pas rencontré de cas où des paramètre de classes doivent être fixe en nombre suffisant pour nécessiter un passage de structure en paramètre.
Si la classe ne doit pas bouger, il y a toujours la capacité de la placer en const, avec au pire quelques membres mutable.
Viens faire un tour sur le code sur lequel je bosse, c'est fou le nombre de dessein de programmation que l'on peut y trouver, le plus souvent de façon totalement inutile (coté java, la partie que je maintien ), et parfois des truc qui me laissent dubitatif, mais là je pense plus à une mauvaise maîtrise de l'outil qu'à une volonté de reproduire un design pattern.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par Thomas Douillard . Évalué à 2.
Il y a aussi ça dans en C++ dans boost pour les unités.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par Batchyx . Évalué à 2.
Après il faut voir si ça vaut vraiment la peine de vouloir utiliser ça avec les paramètres nommés de boost, et les constantes littérales de C++11 juste pour pouvoir écrire
make_rect(_x=1cm. _width=1inch, _y=a.y, _height=a.height);[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par Thomas Douillard . Évalué à 2.
Effectivement, on peut faire des tas de trucs avec les template et des macros, par contre bon oui faut pas trop avoir peur d'avoir l'impression de se battre contre le langage :)
J'aurai tendance à répondre que c'est beaucoup de contorsions, là c'est un peu l'équivalent d'essayer de faire de l'objet en C avec la glib. Vaudrait mieux que ce soit directement dans le langage, mais vu sa vitesse d'évolution c'est sans doute pas pour demain.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par Benbben . Évalué à 4.
en C# je pourrais écrire :
avec un constructeur à 4 paramètres dont certains peuvent être facultatifs.
Et si le constructeur existe seulement sans paramètres, je peux quand même écrire :
si x, y, width et height sont des propriétés de l'objet.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par reno . Évalué à 4.
Après le problème c'est qu'on utilise rarement des nombres en dur et qu'avec des variables ça fait un peu redite non?
rect(x: foo_x, y: foo_y, width: foo_w, height:foo_h), ça n'apporte pas grand chose à la place de rect(foo_x, foo_y, foo_w, foo_h)
# Editeur Wysiwyg ?
Posté par moi1392 . Évalué à 2.
Ça a l'air sympa à première vue, mais en fait, ça ressemble beaucoup aux éditeur html qu'on a vu pendant longtemps (dreamweaver et autres).
Et on est sacrément revenu dessus.
Pour moi ça reste limité à des sous-sous domaines très particuliers qui de toute façon ne se font pas en c++ et on déjà des éditeurs dans le genre très évolués (flash par exemple)
Le seul cas pratique que j'y vois, c'est le test rapide d'une petite fonction utilitaire qui prends des paramètres simples sans avoir à écrire un petit binaire complet. Et ça, c'est la merde sous windows peut-être, mais sous linux, écrire un main avec un appel et le compiler, ça me prends 30 secondes avec un pattern que j'ai.
Parce que tester avec des fonctions qui prennent des paramètre super complexes, il va falloir écrire le code qui fait le rendu de ce paramètre, et qui sait le créer et modifier ses valeurs.
Et souvent, le plus dur, c'est d'imaginer ce que ça va être ce code, et on se rends compte que dans 80% des cas, le code en question, et bien on est en train de l'écrire, c'est l'appli qu'on fait… Donc s'il faut écrire l'appli pour pouvoir écrire plus facilement l'appli, on avance pas des masses.
[^] # Re: Editeur Wysiwyg ?
Posté par ckyl . Évalué à 1.
Et dieu inventa les tests unitaires.
[^] # Re: Editeur Wysiwyg ?
Posté par wilk . Évalué à 3.
Et les développeurs ne les utilisèrent pas et furent tous punis : obligés de programmer en Java.
[^] # Re: Editeur Wysiwyg ?
Posté par Gof (site web personnel) . Évalué à 2.
Ça ressemble fort à ce que Qt Creator peut faire quand on travail avec du QML
# Smug alert !
Posté par Didrik Pining . Évalué à 2.
Encore un qui participe au dernier grand délire "à la mode" dans le lala-land: Tout l'article est écrit à she par défaut.
Seriously guys…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.