Eve, un nouveau langage qui fait la part belle aux commentaires
Les commentaires sont essentiels quand on utilise un langage informatique. Ils servent à documenter dans notre propre langage les lignes de code qui ne sont pas toujours explicites. Les développeurs les utilisent aussi pour expliquer la logique générale, l’utilité d’une fonction ou encore pour ajouter une attribution quand c’est nécessaire. Bref, les commentaires sont au cœur du développement informatique, mais ils restent souvent minoritaires et à part.
Le pari d’Eve est précisément d’inverser cette proportion. Ce nouveau langage de développement place le code au milieu des commentaires, et non l’inverse. Ses fichiers sont organisés comme du texte, avec des blocs de code entre deux paragraphes de texte. L’idée étant d’expliquer ce que fait chaque élément et d’organiser son programme comme un manuel avant tout.
Au cœur de l’expérience, cette idée que l’humain devrait être au centre, pas l’ordinateur. Eve n’impose pas d’ordre pour le code par exemple, c’est au développeur de choisir comment l’organiser. La table de matière sur la gauche de l’interface de développement est là précisément pour ça : elle permet de s’y retrouver plus facilement et surtout de façon logique.
Au-delà de cette idée du code au milieu des commentaires, Eve est aussi un nouveau langage qui pioche beaucoup du côté du HTML pour construire ses interfaces. De manière générale, ce nouveau-venu repose sur des technologies du web et ce langage de haut niveau repose sur du JavaScript (et node.js) pour fonctionner. Les développeurs web apprécieront les avantages que cela apporte, à commencer par l’inspecteur qui permet d’analyser facilement n’importe quel élément dans l’interface.
Eve est un projet novateur, mais aussi nouveau et encore très limité. Pour l’heure, c’est même plus un concept qui permet de réaliser des applications assez simples qu’un langage prêt à l’emploi. Cela n’enlève rien à son intérêt, en particulier dans le monde de l’éducation, où le focus sur les commentaires peut être précieux. Autre avantage à souligner, l’environnement de développement est un simple site web, ce qui facilite considérablement son utilisation. Vous pouvez l’essayer avec ce guide de démarrage.
Si Eve vous intéresse, vous pouvez apprendre comment il fonctionne et comment l’utiliser sur sa page GitHub, puisqu’il s’agit d’un projet open-source. La documentation est disponible à cette adresse.
Yeeeeeess !! C'est vraiment super !
Merci pour l'article !
Intéressant à priori car trop de projets ne contiennent quasi aucun commentaire, et alors c'est galère à maintenir quand les devs initiaux ne sont plus là.
Ceci dit, au sujet de l'utilité des commentaires, vous dites qu'ils peuvent servir à “ ajouter des attributions ».
-> Que voulez vous dire par là ?
Ok, j'avais pas compris qu'il s'agissait de citer ses sources.
Et oui, c'est une pratique recommandée. Quant à savoir si elle est courante... Je ne dois pas avoir de bol, car en général j'hérite de code non documenté (et propriétaire).
Un langage de programmation qui fait la part belle au bavardage, et qui porte un nom de femme - et quelle femme, la toute première ! Cela relève d'un certain humour !!!
Ça s'appelle du Literate Programming, ou programmation littérale.
C'est un paradigme plutôt vieux, initié par Knuth, pour lequel il se servait essentiellement de sa création TeX, en créant ensuite Web. (Vous pouvez vous procurer son livre à ce sujet, très intéressant, qui se lit en juste 1h)
Bref, rien de nouveau sous le soleil, mais un concept rajeuni qui fait du bien !
Aujourd'hui, l'informatique est un monde schizophrène, avec d'un côté les prouesses qu'il permet, et de l'autre les codeurs rester à l'âge de pierre, sur des technos et surtout des paradigmes de plus en plus vieux. On peut encore assister à des débats aussi ridicule que tabulation vs. espace (d'un point de vue extérieur, ça l'est pas mal), alors qu'il suffirait juste d'une gestion dynamique et intelligente de l'alignement, chose qu'on peut faire faire facilement aujourd'hui. Les programmeurs continuent des l'enlisement dans la programmation impérative au lieu de participer à l'avènement de la programmation déclarative (fonctionnelle en tête !).
De toute façon, un programme, ce n'est rien qu'un fichier texte, non ? Quand les programmeurs arrêteront de raisonner programme = fichier texte, alors une évolution sera possible ! On peut faire tellement mieux, à la manière de la différence entre Word et Notepad. C'est le cas des créateurs d'Eve, et je les félicite pour ça.
Mais bon, on continue aujourd'hui à écrire sur des claviers QWERTY/AZERTY, donc à quoi bon ? La place de ce déchet est maintenant dans un musée, pas sous nos doigts !
Triste monde de l'informatique.
Signé un jeune informaticien.
@stiflou
Votre note m'a fait sourire.
Comme vous voyez, on peut être un vieil informaticien décrépit et avoir les mêmes soucis que vous.
L'informatique est une hélix.
Vue de profil, ça grimpe.
Vue de haut, ça tourne en rond.
@stiflou
Si on lit un peu la documentation on comprend qu'il s'agit surtout d'une base de donnees et d'un langage d'operation sur la base de type pattern matching.
Le langage s'appuie sur la récursivité mais ne semble pas disposer de puissance des langages fonctionnel et encore moins d'une approche comme Prolog... Y a bien les fonctions ensemblistes map et reduce classiques, mais y a pas de moteur d'inferences et l'approche fonctionnelle semble vraiment minimaliste.
Pour ce qui est du litterate programming, la documentation y fait explicitement reference en citant Knuth. Pour autant si la volonté de coller au litterate programming est bien une reference, le langage lui meme ne l'est pas. En fait on a d'un coté un langage d'interrogation de base de données et de l'autre le markdown classique pour ecrire des commentaires, et c'est l'IDE qui mix le tout...
C'est donc pas un langage définie sur le litterate programming, mais une IDE qui favorise simplement l'usage de l'auto-documentation.
A ce niveau beaucoup de langages sont mieux integrés avec une syntaxe propre aux commentaire difinie dans le langage et une IDE qui est capable de faire des traitements puissant sur la gestion de la documentation. Java embarque ce type d'approche, mais un exemple de reference c'est Eiffel.
On peut aussi se poser la question aujourd'hui de la pertinence d'un langage "litteraire" sachant que la majorité du temps la programmation se fait avec des IDE tres puissants. Faut voir que le litterate programming est né dans les annees 70, ou les interfaces graphiques etaient surtout des concepts.
Aujourd'hui on a UML, des IDE avec des bases de donnees pour gerer le code et la documentation et cela en multilangages... Meme un truc immonde comme le C peut etre bien documenté, faut il encore que le programmeur le fasse.
Ne vaut il pas mieux avoir un langage unifié et coherent, bien structuré, qui permette d'exprimer un fonctionnement d'une seule maniere...
@C1rc3@0rc
« On peut aussi se poser la question aujourd'hui de la pertinence d'un langage "litteraire" sachant que la majorité du temps la programmation se fait avec des IDE tres puissant »
Flashback : c'était, je crois, à UCSD que j'ai entendu, fin des années '70, cette perle :
« The operating system is what was left out of the programming language. »
En plus, considérant l'état des outils de l'époque, ce n'était pas totalement faux. Il faudrait visualiser l'évolution des IDE depuis cette époque. On peut se demander si l'évolution des IDE n'a eu au moins sinon plus d'importance pratique que celle des langages.
Knuth n'est pas aussi extrême que l'étaient Dijkstra ou Tony Hoare, mais ce sont des gens parfaitement capables de se mettre sur une Selectric (ou devant une feuille blanche, dans le cas de Dijkstra), d'écrire un programme et de le lire comme de la littérature scientifique. Dans leur contexte mental, le “literate programming” est parfaitement conséquent. Mais leur pratique est complètement dissociée du développeur lambda.
@C1rc3@0rc :
Le C ce n'est pas immonde, c'est juste efficace. D'ailleurs UNIX est écrit en C.
De plus, nombre de langages ont repris la base de sa syntaxe, comme JavaScript ou PHP.
@marc_os
Ah ben si Javascript et PHP en ont repris la syntaxe il n'y a rien à dire en effet...
Et ce n'est pas que la syntaxe qui a été reprise par ces 2 langages...
En ce qui me concerne, cette descendance me fait fuir.
EDIT : j'ai écrit ce qui suit pendant que notre camarade @stiflou publiait son commentaire. La convergence est une coïncidence temporelle.
Trois remarques en vrac :
1 - La doc d'Eve se réfère au concept de «literate programming» de Donald Knuth, dont j'avais évoqué ici l'oeuvre, surtout METAFONT. Or, Knuth avertissait déjà il y a 30 ans : ce n'est pas la verbosité qui rend un programme lisible, c'est le style et la structure.
2 - On brasse et rebrasse les mêmes idées depuis 50 ans dans le domaine des «self-documenting, self-commenting languages».
Une ou plusieurs couches de hypertexte en plus ne vont pas résoudre le problème fondamental.
3 - Certains ici se sont plaints de la «lourdeur» d'Atom, qui serait due à ses fondements JavaScript.
Mais d'après ce que je vois, Eve est une surcouche de JavaScript / node.js. Et ça, ça va ?
@ occam : « certains », c'est moi, j'imagine…
Je pensais avoir été clair, mais si jamais : Eve est une expérience intéressante, pas un langage prêt pour la production. Je vois plus d'intérêt côté éducation qu'autre chose.
Sinon pour le concept de literate programming, je dois avouer mon ignorance en la matière. Donc merci pour vos lumières, c'est enrichissant.
@nicolasf
Nicolas, merci du retour.
Non, ce n'était pas vous, qqn parmi les commentateurs avait descendu en flammes Atom à cause de JS.
Mais je suis trop fatigué après cette nuit de cauchemar pour vérifier qui.
Le problème avec de tels projets (Eve) est que les concepts qu'ils essaient de promouvoir ne sont d'aucune utilité tant que les langages «de production» ont trois générations de retard. À ce titre, Swift est déjà une aubaine.
Implémenter les idées d'Eve dans un préprocesseur pour Swift serait un projet d'utilité publique, car il s'ouvrirait sur du réel. Par exemple.
les lignes de code
place le code
des blocs de code
les lignes de code sont organisées
pas d’ordre pour le code
cette idée du code
Avec une telle pauvreté du vocabulaire, et l'appauvrissement de la pensée qui en découle, il y a du boulot pour écrire des commentaires d'instructions informatiques pertinents !
@ heret : ah chouette, tu es là ! ?
Les commentaires, c'est vraiment un truc de lopettes. Pourquoi pas des bandeaux publicitaires pendant qu'on y est ? Les programmeurs, les vrais, ceux qui en ont mettent tout sur une seule ligne, pas d'espace superflu, que des variables sur une lettre.
De toutes façons, qui lit les commentaires, à part les tarlouzes qui sont pas capables de comprendre du code ?
Seymour Papert, sors de ce code !
(Bon, plus sérieusement, je vais jeter un oeil sur le bouquin de Donald Knuth.)
@Matlouf
APL, mon langage fétiche (que plus personne ne connait ☹️) permettait de définir une machine de Turing sur une seule ligne.
Ça devrait vous convenir.
Mais sans de copieuses notes manuscrites sur le printout, toute séquence tant soit peu complexe devenait indéchiffrable au bout de quelques jours.
Bonjour la syntaxe.
Quant aux trucs du genre "webkit-user-select" ou "moz-user-select" dans le code... :-/
Enfin bref.
Personnellement je pense qu'un bon code est un code qui se comprend en le lisant sans avoir besoin de commentaires.
Bien nommer ses variables, fonctions, classes, etc., bien factoriser son code, bien séparer les composants, etc. suffit entièrement à rendre un code compréhensible et tenable dans le temps.
Coder en Ruby par exemple permet aussi d'avoir une lecture agréable du code, avec un langage quasi parlé.
Enfin quand on se force à ne PAS écrire de commentaire, on cherche des bonnes pratiques, on cherche à mieux coder.
IMHO
@ bobune
Et une fois que tu seras parti, ceux qui devront reprendre ton travail te maudiront.
Exemple concret :
if (statut == "validé")
{
// liste des actions à faire dans le cas validé...
}
Toi, tu sais que si le "statut" n'est pas "validé", alors il ne faut rien faire.
Mais dans un an, la personne qui reprendra ton code soit pour corriger un bogue, soit pour le faire évoluer en ajoutant ou modifiant des fonctionnalités, cette personne va se demander:
Et si "statut" ne vaut pas "validé", on fait quoi ? Pourquoi est-ce que le code actuel ne fait rien ?
Au mieux, il va perdre du temps pour essayer de comprendre.
Une règle que j'applique et que j'ai du mal à faire suivre, c'est « pas de if sans else ». Si on ne fait rien, on dit pourquoi.
Par contre, je suis aussi tombé un jour sur un truc du genre : « Ça marche comme ça, ne surtout pas toucher ! ». Sans autre explication. Le mec il avait construit un château de sable qui par miracle tenait à peu près, mais lui même ne savait pas trop pourquoi, donc "pas toucher"... Mais au moins on le savait.
Ce qu'il faut, c'est écrire la juste quantité de commentaire.
Répéter en toute lettres une évidence, ça ne sert à rien.
Une règle empirique est : « Dès que tu dois te gratter la tête cinq minutes pour savoir comment faire, alors un commentaire est judicieux, car sinon ton successeur devra se gratter la tête deux fois plus longtemps que toi ! »
Car en plus, tous les chemins mènent à Rome. Si si !
Donc ton successeur qui va lire ton code super intelligent, super bien organisé, auto-explicatif, va toujours se demander à un moment donné, « mais pourquoi il a fait comme ci et pas comme ça ? ». Et sans commentaire ni aucune documentation technique, ben il va pouvoir se poser la question longtemps, et peut-être que s'il est moins intelligent que toi, il va tout mette à la poubelle et réécrire ton code, et rater un point important, parce qu'il n'aura pas pu deviner tes motivations !
"Une règle que j'applique et que j'ai du mal à faire suivre, c'est « pas de if sans else ». Si on ne fait rien, on dit pourquoi."
Chez moi, c'est plutôt : si tu as besoin d'un else, revois ton if pour qu'il modifie une valeur / un comportement par défaut au besoin.
"Une règle empirique est : « Dès que tu dois te gratter la tête cinq minutes pour savoir comment faire, alors un commentaire est judicieux, car sinon ton successeur devra se gratter la tête deux fois plus longtemps que toi ! »"
Encore une fois chez moi, si on doit se gratter la tête plus de 5 minutes pour comprendre du code, c'est qu'il est pas assez clair (mauvais nommage des variables / classes / fonctions et j'en passe, découplage trop faible...)
Où je bosse, on nous demande de faire du découplage très fort, quitte à écrire des fichiers de 5 lignes, histoire de savoir qui fait quoi et pas avoir à chercher pendant plus d'une heure le fonctionnement exact que l'on veut, ou comment comprendre un bloc de code de 3k lignes (je bosse sur un monolithe legacy depuis 3 ans, je commence à savoir ce que c'est que de perdre du temps à relire du code écrit salement malheureusement :( )
Après chacun ses techniques, mais ce qu'on nous rabâche depuis un bon moment c'est que si on a besoin d'écrire un commentaire dans notre code, c'est qu'il est pas assez clair. Après il y a des cas spécifiques où il vaut mieux en écrire, mais si c'est pour expliquer ce que le code fait, c'est qu'on a pas su être assez clair dans notre façon de développer.
Pour l'exemple de code au dessus, comme c'est un if tout seul, sans contexte, personne ne peut comprendre ce qu'est statut. Il faut reprendre ça dans le contexte complet :)
Et sinon, dans le monolithe qu'on maintien, je suis tombé sur un commentaire il y a un bon moment qui disait "ATTENTION : JE NE SAIS PAS CE QUE FAIT CE CODE". Exemple typique du gars qui a développé un truc de 150 lignes et qui s'est perdu dans son fonctionnement :p
@ MaksOuw
« si tu as besoin d'un else, revois ton if »
Programmation 100% linéaire sans tests ni boucles ?
Faudrait donner ta méthode aux fabricants de processeurs, ça leur permettrait de virer plein d'instructions assembleur inutiles selon toi.
« si on doit se gratter la tête plus de 5 minutes pour comprendre du code, c'est qu'il est pas assez clair »
Visiblement, tu as lu trop vite ce que j'ai écrit.
Je ne parlais pas de comprendre du code existant, mais je parlais de sa rédaction, de l'instant où on l'écrit. Ce que je dis, c'est que si un truc n'est pas évident à écrire et qu'il faut réfléchir un peu avant de se jeter à l'eau, alors il est utile d'écrire dans un commentaire le pourquoi de la réflexion. Et comme je le disais, il y a souvent plusieurs alternatives possibles, plusieurs façon de faire possibles. Quand on fait un choix, il est motivé par quelque chose. Et si on n'écrit pas dans un commentaire (ou de la doc) ses motivations, les "pour" et "contre" telle ou telle façon de faire, le successeur qui devra maintenir le code n'en saura rien. Et il se trouve qu'actuellement je suis un tel successeur, et que souvent j'ai à me poser ce genre de question : "Mais pourquoi ce conn..d a-t-il fait comme ça" ? Je demande autour de moi, et personne ne sait.
Note, c'est aussi une tentative de la part de certains développeurs de se rendre indispensables. "Après moi, le déluge".
Mais bon, je sais, les adeptes du développement "agile" écrivent sur des post-it qui tôt ou tard finissent à la poubelle.
C'est comme écrire des spécifications, ça fait chier tout le monde.
Sérieux, heureusement que les mecs chez Airbus ne bossent pas comme ça !
"Mais bon, je sais, les adeptes du développement "agile" écrivent sur des post-it qui tôt ou tard finissent à la poubelle."
Haha, c'est qu'ils savent pas utiliser correctement la méthode agile alors :p (bon après chez nous on l'applique peut être un peu trop à la lettre et ça en devient chronophage, c'est pas beaucoup mieux)
Effectivement j'avais pas compris ton commentaire comme ça. Je suis aussi un successeur de ce type, avec 10 années de développement sur un soft vieillissant, je peux te dire que des fonctionnalités, il y en a à la pelle, mais alors le code est juste inbuvable (blocs de 5k lignes etc. J'ai du mettre mon second écran à la verticale pour voir le plus possible de code !)
Pour l'histoire du code 100% linéaire, j'ai jamais dit de ne pas mettre de tests ni de boucle. Mais c'est au niveau des else, ça sert à rien de mettre un else pour en faire un comportement standard. Autant mettre le comportement standard avant la floppée de if / le switch histoire que des valeurs par défaut soient définies. Ca prend peut être un peu plus de place en mémoire (et encore, avec les machines qu'on a à l'heure actuelle c'est même pas un problème), mais c'est pour moi plus propre.
@ MaksOuw
Au sujet du if/else, je suis d'accord sur le fond, ce que je voulais dire et que je n'ai pas précisé, c'est que s'il n'y a rien à faire dans le else, un petit commentaire aidera celui qui devra revoir le code un jour :
if (test)
{
// code
}
// else // commentaire pour dire pourquoi on ne fait rien, même si ça semble évident.
S'il est parfois difficile de comprendre ce qui est écrit et qu'on voit, il est souvent encore plus difficile de deviner ce qui n'est pas écrit ! Car la question qui s'impose est alors : "Mais pourquoi on ne fait rien dans ce cas ?".
@bobune
Comme qui dirait du style ?
Structuré, si ça se trouve ?
vraiment bien !
So, when I do my essay today, it is important to identify (understand) his topic, to determine the desired scope and purpose of each paragraph. Start with a basic idea or a vivid phrase. The task is to immediately capture the attention of the reader (listener). A comparative allegory is often used here when an unexpected fact or event is associated with the main subject of the essay.