daeldir a écrit 152 commentaires

Si Daala arrive à être meilleur que H.266 (car ce sera lui son compétiteur), je serai le premier ravi (champagne!)

… Et tu comptes suivre un peu l'actualité de ce projet, voir aller troller chez eux aussi ?

Je dis troller, c'est pas méchant, hein ^^. Juste, comme tu as des compétences dans le domaine, quelques désaccords avec leur manière de faire (code prioritaire sur la spec), aller ne serait-ce qu'en discuter avec les concernés (parce que c'est pas dit que les lecteurs de LinuxFR fassent remonter ces critiques) pourrait te donner une chance d'ouvrir la bouteille de champagne plus tôt ;-)

^{ceci n'est pas un takakodé, juste une suggestion}

Sauf que Debian (comme n'importe qu'elle distribution) a la très grande majorité de ses programmes installés de cette manière. Alors oui pour compléter la liste faudra farfouiller un peu dans /opt ou /usr/local, trop dur…

Mais… Sur Windows, on n'a pas la majorité des programmes installés avec un programme d'installation, et donc accessible dans le panneau « Programmes et fonctionnalités » ? La liste dans ce panneau n'est pas la même que celle renvoyée par wmic product get name,version ?

Bon, je suis pas un gros utilisateur de Windows, mais j'avais très peu de programmes qui n'étaient pas accessibles à partir de là… Autant que de programmes dans /opt sur linux, on pourrait dire… (très peu).

Puis sur Linux, il y a des programmes dans /opt, dans /usr/local, dans le dossier personnel… Et même pas l'équivalent de ton astuce avec la base de registres ! Linux, çaynul ;-)

… Perso, j'adore les gestionnaires de paquets (installer en une commande, toujours la même, désinstaller, pareil, recherche rapide de logiciels et mise à jour de tout les programmes installés en même temps) mais je suis d'accord avec zebra3, le problème est le même sur Linux (ou alors, tu as pas de chance si la plupart de tes programmes n'utilisent pas un installateur correct).

Ça n'empêche pas le journal d'être intéressant, de nous présenter ce truc étrange qu'est le PowerShell. J'en avais jamais vu, mais j'avais lu je sais plus où que « microsoft avait enfin fait un truc utilisable » (d'où mon qualificatif « étrange » :-°).

Bon, voilà, j'en rajoute au troll \o/

miam…

Le multi compte est interdit sur linuxFR ? Bon à savoir.

Il me semble, oui. Après, je ne me souviens pas que l'individu en question aie été blâmé par la modération pour ça (pas publiquement, en tout cas). Mais il avait un style très reconnaissable, des sujets souvent similaires… Et une note très basse ! Pour ça, le système de notation fonctionnait bien ;-) (moi j'aime bien le système de notation, c'est souvent un bon indicateur, à la fois pour se juger soit même, et pour voir si ça vaut le coup de lire un long commentaire. Mais je navigue en -42, et je n'ai jamais été victime de ce système…)

si elle est publiée, peu de chances qu'elle se retrouve dans le négatif, parce qu'il y a ton travail, mais aussi celui des modérateurs

o_O
Les modérateurs pourraient être moinsés parce qu'une dépêche qu'ils ont modérée l'est aussi ?

Non, mais si la dépêche est de mauvaise qualité, elle ne passera pas la modération. Si elle passe, ça veut déjà dire qu'il y a de la qualité (un minimum), donc, peu de chances que la dépêche soit moinssée.

Après, il y a des dépêches de mauvaise qualité qui passent, parfois. Mais ça reste rare.

Et dépêche de qualité ne veut pas dire longue dépêche, ou dépêche objective… Mais ça, je laisse aux modérateurs le soin de définir ce qu'est une dépêche de qualité. Ils ont un peu regretté la qualité des dépêches de Patrick G, par exemple, parce que les gens n'osaient plus proposer des dépêches plus simples, qui pourtant étaient tout à fait acceptables ! (mais comparées au dépêches de Patrick G, c'est sûr ⸮)

Au niveau de ton écriture, on t'a déjà fait remarquer une utilisation abondante de points de suspensions (d'ailleurs, tu en utilises moins maintenant, non ?). Je rajouterais deux choses (conseils, tu en fais ce que tu veux ☺) :

• Tu utilises souvent l'expression « Ce n'est pas un détail… ». C'est… Un tic de langage ? Je sais pas, mais parfois, ou à la longue, c'est… Perturbant. Un peu agressif, dans mon ressentit… Bon, là, je parle d'un ressentit, personnel, inexplicable… Par contre, la répétition de cette phrase est réelle. Peut-être qu'il y a quelque chose à voir à ce niveau, que quand tu l'utilises, tu devrais te poser des questions sur la « finition » de ton intervention ?
• Tu réponds souvent aux messages en entiers. Parfois, tu peux ne répondre qu'à un ou deux points du message auquel tu réponds. Ça fait des commentaires moins longs, dont tout le contenu est pertinent. Si tu réagis à tout un message, mais que la moitiés des réactions sont un « Ça, d'accord », ça noie un peu le message (et si dans le lot, tu as une phrase qui plait pas et est inutile, ça peut plomber le message entier :-o).

Personnellement, avant de poster un message, je me pose toujours la question « Est-ce que ce message est pertinent ? ». Les trois quarts du temps, non, et je vous épargne donc ces interventions inutiles ;-)

Régulièrement, mes interventions sont « plussées », ce qui est pour moi un signe que j'ai bien jugé la pertinence de mon message.

Parfois, le message reste à 1. Dans ce cas, ça veut dire que c'était pas si intéressant et que j'aurais pu me taire. Mais au moins, j'ai dérangé personne.

Bref, je me sert du système de notation. D'un point de vue personnel, je trouve ça très utile.

Oh, et en parlant de tics de langages, amusez vous à relever toutes les occurrences de « personnel », « à mon avis », « de mon point de vue » dans mes messages… Quasiment jamais du factuel, toujours du subjectif, et avec des pincettes, s'il vous plaît ! J'ai aussi mes défauts :-D

Ben, c'est que les dépêches sont modérées à priori, donc, c'est pas grave si un troll en propose une, au pire, elle est pas publiée.

Alors que le journal, lui, est accessible tout de suite. Donc, on empêche les trolls de poster.

Je crois même que passé un temps, des non-membres pouvaient proposer des dépêches…! (De mémoire, donc, peut-être pas. Ou peut-être qu'on peut toujours…)

Évidemment, ça gêne aussi les non-trolls qui ne sont pas appréciés. Toi, par exemple, je n'ai pas l'impression que tu trolles trop, mais tu as longtemps été considéré comme « inutile », ce qui a limité ta capacité à poster des journaux.

Ceci-dit, au début, je décrochais en lisant tes commentaires, ou les trouvait remplit de bêtises (à mon avis). Si bien qu'à un moment, je lisais deux lignes, regardait l'auteur, sautait le commentaire (j'ai peut-être moinssé, je sais plus, mais dans ce cas, seulement les commentaires que j'ai lu, et quand ils disaient de grosses bêtises, et tu as eu une explication (pas forcément de moi) sur la bêtise en question).

Là, ça fait plusieurs fois que je lis tes commentaires en entier. Donc, au niveau du style au moins, tu t'es amélioré. Au niveau des idées… Les commentaires pertinents ont plus de chance d'être pertinentés, parce que les gens arrivent à les lire et les comprendre ! Donc, tes notes ont augmenté.

Aussi, je pertinente tes posts marqués comme « inutiles » quand ils ne le sont pas (à mon avis, je rappelle). Je fais ça pour tout le monde : pertinenter les pertinents, de temps en temps pertinenter les « pas inutiles » marqués comme tels, et (rarement) « inutiliser » les messages vraiment idiots (et non, « je ne suis pas d'accord » ne veut pas dire que le message est inutile !)

Aussi, je tiens à te féliciter : il y a un autre compte qui postait à moins dix par défaut. Puis quand il voulait poster un journal, il créait un nouveau compte (très vite postant à moins dix par défaut aussi). Toi, tu restes, tu tiens bon, t'essaye d'apprendre, tu t'améliore dans ta communication, et t'as même pas essayé le multi-compte pour poster un journal ! (ou alors, tu t'es pas fait choppé comme l'autre ;-)).

Je te souhaite donc d'arriver au stade où on peut poster des journaux, parce que tu fais des efforts ! (et si une de tes idées de journal peut faire une dépêche, tente… Elle sera modérée, de toute façon – donc, si elle est publiée, peu de chances qu'elle se retrouve dans le négatif, parce qu'il y a ton travail, mais aussi celui des modérateurs)

À l'heure où j'écris, le commentaire de pBpG est dans le négatif, mais pourtant, il n'y a pas que du faux.

Même sans chercher à corriger les « erreurs » auxquelles Internet Explorer peut être sensible, juste tester, pour voir, donne parfois des résultats surprenants. Ça va du « Dingue, ça marche alors que je fait des trucs super compliqués », au « Beuh… J'ai que du CSS et du HTML, et IE est le seul navigateur à me rendre un écran noir ? » (à l'époque où j'ai eu ça, c'était IE 8).

Bon… Si on n'a qu'un Linux sous la main, ça vaut pas le coup de s'embêter pour ça. Mais si on y a accès… Faut être curieux, sans forcément s'engager à supporter la bête :-)

C'est assez simple. Un artiste, c'est quelqu'un qui crée, donc qui ne copie pas

s/ne copie pas/ne se contente pas de copie verbatim

On copie toujours, à un moment ou un autre. C'est le fondement de la culture et de l'art. Copier n'empêche pas d'innover, au contraire, comme en informatique, réutiliser l'existant permet de faire plus qu'en partant de zéro.

L'un des rares mouvement qui peut se prétendre vierge de toute copie d'œuvres préexistantes est l'art brut.

Quand à la définition d'un artiste, non, ce n'est pas simple. Elle va dépendre des sensibilités, des intentions, de l'époque…

… Pas chez moi… Mais c'est pas moi qu'il faut mettre à jour, c'est ma machine…

Je suis déjà assez à jour pour ne pas troller sur la vitesse — parce que java est quand même devenu vachement bon à ce niveau, je trouve… De toute façon, meilleur que javascript (ou alors je suis plus à jour la dessus non plus…?).

Après, il est possible que tu m'aies prit au sérieux, alors je précise : c'était de l'humour. Un ordinateur pourri et de l'humour, voila la confirmation que je suis un charlot…

Et pour te donner raison, en fait, je pourrais même dire que c'est sympa les arguments de Java qui permettent de limiter la quantité de RAM totale utilisée par la VM : ça m'a permit de faire tourner un programme qui se faisait normalement tuer parce qu'il bouffait toute la mémoire. D'ailleurs, la machine en question a dix ans (mais la VM est à jour).

L'humour de LinuxFR, c'était mieux à vent…

Non, malgré le poids du navigateur, la consommation de RAM n'est toujours pas suffisamment élevée…

^{cherchez pas, je suis déjà dehors…}

Mais ça poserait les mêmes problèmes de portabilité et de sécurité que native client (NaCl), non ?

Mozilla a strictement refusé NaCl parce que le code généré n'est pas portable (puisque c'est du code machine). Niveau sécurité, un gros effort a été fournit par Google pour empêcher ce code machine de sortir du cadre du navigateur.

Permettre l'accès à une API externe, c'est cumuler les deux défauts : l'API n'est disponible que sur certaines machines, et la sécurité n'est pas garantie comme dans native client. XUL étant fait pour écrire des applications bureau, c'était pertinent, mais l'objectif de Firefox OS étant aussi de créer des APIs javascript portables (et à terme standardisées), ce serait étonnant qu'ils acceptent ce genre de pont vers le système…

Après, s'ils optimisent suffisamment emscripten et asm.js, on peut supposer que sur certaines machines, l'aspect bas niveau ne soit plus un problème. Dans ce cas, une solution serait d'avoir une API qui puisse faire les deux : utiliser le code machine dans un cas, ou utiliser la bibliothèque compilée avec emscripten dans l'autre, sans modification du côté du code de l'application…

Moi je clique sur les liens vers les articles originaux (quand le résumé me tente). Je ne clique par contre pas sur les liens qui pointent vers l'April, les podcasts, etc. qu'on a au début de la page.

Et c'est justement ces derniers qui sont comptés. Pas les liens sur lesquels je clique.

Finalement, on ne sait donc pas combien de personnes lisent la revue de presse, et surtout, combien vont sur les articles originaux.

Je veux bien que ce ne soit pas une appli pro et qu'on ne peut pas demander le même niveau d'exigence mais dans ce cas là il vaut mieux le garder pour soi plutôt que de le publier.

Ça c'est méchant ☹…

Plus sérieusement, le fait qu'il distribue son code permet justement de voir ces erreurs, et peut le pousser à les corriger bien mieux que s'il restait dans son coin sans partager, non ?

C'est d'ailleurs confirmé par le reste de ton message : aurais-tu critiqué son projet et proposé des solutions (même théoriques) si tu n'avais pas jeté un coup d'œil aux sources ?

C'est peut-être une mauvaise pub pour lui, et pour PHP, mais justement, on ne peut corriger la mauvaise pub pour PHP qu'en corrigeant le projet, pas en le cachant… Sinon, autant dire : « C'est un langage de merde, il n'y a personne de compétent pour éduquer ceux qui utilisent mal le langage. »…

Ce que tu proposes est aussi une « optimisation » prématurée. Ce n'est juste pas une optimisation de la même chose (optimiser la vitesse, optimiser la réutilisabilité). Rendre le système modulaire demande d'ajouter du code, d'installer des « hooks » pour gérer tout ça… Au final, tu complexifies le système, sous prétexte que « peut-être un jour » on aura besoin d'utiliser ça ailleurs. Un code non-modulaire peut-être plus simple (c'est ce qu'on cherche en n'optimisant pas à tout va, un code simple…).

C'est d'ailleurs ce qui a fait le succès de Linux sur Hurd. Linus n'a pas écrit un noyau monolithique pour la vitesse. Il l'a écrit parce que c'était plus simple. Créer un micro noyaux (alors qu'il se fichait de la portabilité) aurait été une optimisation prématurée. Le code est devenu modulaire plus tard quand ils en ont eu besoin.

C'est ce que fait stali.

J'aurais plutôt dit « c'est l'objectif de stali ».

Stali est un projet intéressant, mais ni actif ni abouti. Il n'apparait pas dans les dépôts de suckless. La nouvelle la plus récente que j'ai pu trouver à ce sujet est ici. L'image proposée en téléchargement date de 2009.

Je cite la « roadmap » de 2010 :

Prio 1: userland (nearly finished, expect early April)
Prio 2: complete system (expect late April)

Pas tenue, donc. Apparemment, ils ne peuvent pas travailler dessus, et stali est encore un projet plus qu'une distribution. Ce qui est dommage, je trouve, parce que j'aime bien ce que fait suckless, et que je serais curieux de ce que ça donnerais si ce projet aboutissait.

Mais peut-être que d'en parler va donner envie à certain d'aller proposer de l'aide ? ;-)

Le logiciel est gratuit. On peut le trouver ici. Il n'est pas libre, par contre : on a le droit de faire pas mal de choses avec, mais pas n'importe quoi – pas d'utiliser leur code pour leur faire de la concurrence – et la licence du polyForth fournit vient de Forth inc. avec encore moins de droits.

Leur business model, c'est donc de vendre les puces, pas le logiciel. Par contre, dans l'entreprise, ils codent en Forth.¹ On peut aussi s'attendre à ce que leurs clients codent en Forth (l'architecture est tellement exotique qu'essayer de créer un compilateur C pour la bête n'est pas des plus pertinents…).

Mais je ne connais pas leurs clients ;-).

¹ : Tu demandais des exemples d'entreprises qui codent en Forth. Bon, c'est pas des exemples très pertinents, mais c'est les seuls que je connais.

Mis à part Forth Inc. et Green Arrays (où travaille maintenant Chuck Moore) ? Non, je n'ai pas d'autre exemples d'entreprises qui utilisent actuellement et ouvertement Forth. Les entreprises/organisation connues pour avoir utilisé Forth ne font pas que ça (il y avait les BIOS de Sun, des projets à la Nasa…), et en font très peu.

Si vous ne connaissez pas Green Arrays et que vous êtes curieux, je vous invite à aller voir, ça vaut le coup d'œil : ils poussent le concept du processeur multi-core plus loin en créant des puces contenant 144 ordinateurs. Chaque ordinateur a sa propre mémoire, utilise très peu d'énergie, se met en veille/sort de veille automatiquement, est très rapide… Chaque ordinateur est bien sûr limité (très peu de mémoire, jeux d'instruction minimaliste), mais peut communiquer avec les autres ordinateurs de la puce.

Bien sûr, ça donne un résultat différent de ce dont on a l'habitude. C'est souvent le cas dans l'univers de Forth, je trouve : c'est différent, mais ça reste de l'informatique, et ça fonctionne. Et dans mon cas, ça me fascine ^_^

(mmmh… mais on n'est plus du tout dans le sujet du journal :-°)

Pour l'histoire des accolades : arrive-t-on réellement a un code où il n'y a jamais deux instructions dans un if/else/autre ? Si oui, alors il peut être envisageable de se passer d'accolades. Mais ça + une largeur de ligne faible, ça me semble étrange. Mais peut-être est-ce possible, auquel cas c'est intéressant ;)

C'est un exercice que je trouve intéressant. Je n'ai pas encore rencontré de cas où c'était impossible, mais je n'ai pas non plus souvent codé des trucs extrêmement complexes.

Il y a des langages où c'est beaucoup plus facile. En premier, Forth, puisque c'est de là que j'ai tiré cette pratique. Ensuite, les langages objets, parce qu'on peut passer l'information de manière peu verbeuse (le contexte de l'objet est partagé entre les méthodes, pas besoin de passer cinquante arguments). Dans un langage comme le C, ça devient plus compliqué de faire tenir le code sur une seule ligne.

Pour tenir sur des lignes courtes, il faut des noms courts. C'est facile en Forth ou on peut redéfinir un mot sans affecter le comportement des fonctions précédemment définies. C'est possible avec les langages objets, parce qu'il est possible de trouver des noms courts quand le projet est bien structuré : une variable est un nom, une méthode est un verbe, et effectuer une action consiste à écrire une phrase. Et on peut toujours découper un texte en phrases courtes. Mais là encore, c'est possible parce qu'un même mot peut avoir différentes significations (suivant le contexte, ici, l'objet dans lequel on travaille). Ceci-dit, un nom idéal est un nom composé d'un seul mot. J'atteins rarement ce stade avec les langages objets, comme on peut le voir dans le code que j'ai présenté. Mais la limite de taille m'oblige à me triturer suffisamment les méninges pour éviter le traditionnel piège du « FactoryOfSingletonFactoryOfUserComment ».

Je pense que ça aurait été plus lisible si les définitions des fonctions n'étaient pas imbriquées.

Mais les définitions des fonctions ne sont pas imbriquées, là…? Et la closure au début définit juste un espace de nom.

Personnellement, je n'aime pas non plus quand c'est imbriqué. Une de mes règles arbitraire est « pas plus de trois indentations » (de toute façon, si on limite la taille des lignes, les indentations sont très vite un problème).

je supporte difficilement les lignes avec plusieurs instructions (sauf cas très précis, et jamais sur de boucles/conditions)

Ce genre de pratiques a dû causer au moins autant de traumatismes que le goto ;-)

j'aurais peut-être dû me contenter de factoriser, et adopter un style plus courant… Là, le débat se déplace sur d'autres horizons. (ça m'apprendra à faire le malin :-°)

if (shouldNotWrite(scriptSource, loadedFromBaseJS))
  return false

Ça, de toute façon, c'est interdit. Pour la raison que tu cites. S'il y a retour à la ligne, il faut les accolades. Dans le même genre, si il y a des accolades sur le if, on en met sur le else. En général, je vote pour une règle stricte : pas d'accolade du tout (et donc conditions sur une ligne), ou toujours des accolades (et quand je dis toujours, ça veut dire même quand ça pourrait tenir sur une ligne). Et comme je l'ai dit, à moins que tout le monde soit d'accord avec ce style très particulier, j'irai sur plus traditionnel (accolades, point virgules…).

Après, sur le côté closure. Par exemple, le doc = goog.global.document est assez particulier, surtout que je n'en vois pas du tout l'intérêt. En plus, il est utilisé avant sa déclaration (ok, c'est pas forcément un problème, mais quand même).

J'ai gardé cette partie du code d'origine, parce que j'avais déjà la closure (pour pas polluer la bibliothèque autour). Je l'ai placé après (comme le reste des définitions) pour rester cohérent avec le commentaire. À la base, j'avais :

/* --- (function (goog) { */
/**
 * The default implementation of the import function.
 * Writes a script tag to import the script.
 *
 * @param {string} src The script source.
 * @return {boolean} True if the script was imported,
 *   false otherwise.
 * @private
 *
 */
/* +++ */ (function (goog) {
  goog.writeScriptTag_ = function (source) {
    if (!goog.inHtmlDocument_()) return false

    var loadedFromBaseJs = isDependency(source)
    if (shouldNotWrite(source, loadedFromBaseJS)) return false

    doc.write(tag(source))
    return true

J'aurais peut-être pu remettre le code dans l'ordre « traditionnel » après avoir passé la closure au dessus du commentaire… Il ne faut pas s'arrêter sur la closure qui est ici un détail.

Avoir des limites genre pas plus de 5 lignes, j'en vois pas vraiment l'intérêt. A part mettre chaque instruction ou condition dans une méthode qui lui est propre, mais ça revient à découper pour découper là. D'ailleurs je trouve étrange de limiter la taille des lignes et en même temps vouloir tout mettre sur une ligne…

Les fonctions de cinq lignes, ce n'est pas une règle absolue (comme j'ai dit, je fais à vue d'œil), c'est juste que quand chaque action a un nom qui indique le but de l'action, on se retrouve avec des fonctions aussi courtes. La limite sur la taille de la ligne, elle, par contre, est une vrai limite. Elle est couplée à une autre limite : ne pas utiliser d'abréviations. Enfin, mise en parallèle avec le choix fait ici de ne pas utiliser d'accolades (donc, boucles, ifs, etc. sur une seule ligne), ça oblige vraiment à réfléchir. Oui, on découpe pour découper, mais au passage, on réfléchit au but du morceau de code qu'on est en train de découper. On doit lui chercher un nom, significatif, court…

Certains langages s'y prêtent mieux que d'autre. Dans un langage objet, le résultat est souvent qu'on se rend compte qu'une partie de notre logique devrait être placée dans une nouvelle classe. En Forth, les fonctions peuvent tenir sur une ligne parce que le passage d'arguments est implicite, et elles doivent tenir sur une ligne parce que sinon on n'arrive plus à suivre l'état de la pile. Dans un langage comme le C, c'est plus difficile, parce qu'on doit passer tout les paramètres, on ne peut pas avoir plusieurs fonctions du même nom (en orienté objet, on peut tant que la méthode appartient à un objet différent)…

Pour reprendre ton exemple :

for(myIntVectorIterator = myIntVector.begin(); myIntVectorIterator != myIntVector.end(); myIntVectorIterator++) if (*myIntVectorIterator % 2) {
    cout<<*myIntVectorIterator<<" ";
    //Should output 1 3 5
}

Ce code ne passe pas selon mes règles. C'est un exemple, très abstrait, je ne peux donc pas proposer de solution, mais face à un code de ce genre, je réfléchis énormément pour raccourcir la ligne de 144 caractères. Je suppose que je mettrais justement le if/else dans une autre fonction, avec un nom qui indique ce que fait cette condition. myIntVectorIterator est un nom très long, est-ce qu'il n'y en a pas un plus court qui ait un sens dans le contexte actuel ?…

Le but de cette règle est de forcer le développeur à penser jusqu'au bout à ce qu'il est en train de faire. Si un mauvais développeur vient toucher au code, on le verra tout de suite parce qu'il sera incapable de suivre les règles (ici, mauvais est très subjectif, peut-être que je suis un mauvais développeur, après tout ;-)). Ce qui rejoint ceci :

Et les conventions de code, si elles doivent permettre d'avoir un code élégant, doivent aussi s'assurer que tout fonctionnera au mieux, en prenant si possible en compte les erreurs humaines.

En ce sens je suis totalement d'accord avec toi. Et mes règles ne sont pas fun non plus ;-). Les tiennes sont sûrement plus éprouvées, par contre, parce qu'elles sont suivies par la majorité de l'industrie. Mis à part dans mes propres projets, et dans quelque codes en Forth, je n'ai jamais rencontré un style aux choix aussi radicaux que le mien. Ah si, en smalltalk aussi (les méthodes sont souvent très courtes).

À noter qu'en smalltalk, il y a deux types de commentaires : les commentaires inline (assez rare), et les commentaires de la classe/de la méthode, présentés à part. Ceux-ci sont courants, et sont censés être précis.

Le code que j'ai présenté ne contient aucun commentaire, parce que c'est le sujet du journal. Si le sujet du journal avait été l'inutilité d'un code très découpé, j'aurais sûrement fait comme en smalltalk : indiqué ce que fait chaque fonction, pourquoi elle existe… Mais il n'y aurait pas eu plus de commentaire inline.

Je distingue la documentation et le commentaire. Un commentaire n'a pas de sens sans le code qu'il accompagne. La documentation en a. Aussi, je distingue deux types de documentation : la documentation interne au module, et la documentation externe. La documentation externe est accompagnée du prototype des fonctions, d'exemple sur comment les utiliser, etc. La documentation interne décrit le contexte d'exécution, les pièges à éviter… Mais dans les deux cas, il devrait être possible de présenter cette documentation de manière bien distincte du code (comme en smalltalk, la documentation et le code sont dans un onglet différent). Une fois le contexte connu, le code devrait pouvoir être lu sans avoir à être annoté. L'intérêt pour moi d'avoir une documentation à part est qu'elle peut être mieux rédigée, couvrir une plus grande portion de code, offrir une vue d'ensemble de ce qu'on cherche à faire… Alors qu'un commentaire est très localisé. Par contre, cela demande un travail supplémentaire (tout comme la factorisation à outrance demande un travail de réflexion et de nommage supplémentaire).

Après, quand je parle de documentation à part, je n'érige pas ça comme une règle : l'idée de la javadoc, à savoir, la documentation de la fonction à côté de la fonction, est pertinente à mon avis, puisqu'elle permet de vérifier plus rapidement la validité du code, synchroniser la documentation aux code… De la même manière, on peut envisager de mettre la documentation interne avec le code. Mais le commentaire traditionnel n'est pour moi pas la place de cette documentation. Au début du fichier, pour comprendre à quoi on touche avant même de plonger dans le code, est la place appropriée pour cette documentation. Ou bien, comme en programmation lettrée, avec le code – mais le code est alors une illustration de la documentation. Quoi qu'il en soit, on ne commente pas le code, on documente notre problème. Le code reste une information à part et auto-suffisante quand le problème est maîtrisé.

Mais je suppose que, d'une certaine manière, je t'accorde là un point, puisqu'au final, il y a une documentation. Le débat porte juste sur la place de celle-ci, et la lisibilité du code selon la place occupée par la documentation.

(Je suis rentré dans le débat pour montrer un exemple de code sans commentaire en essayant de garder le sens de ceux-ci, comme un défi. Après, je parle de mes goûts, mais comme vous pouvez le voir, mes goûts ne bannissent pas les commentaires, ils les déplacent… ;-))

Deuxième partie de ma réponse, en réaction à ce point :

Ensuite, honnêtement, je trouve ça plus lourd. Et surtout, il manque réellement des commentaires.
En fait, en lisant ton code, on ne sait toujours pas pourquoi on teste l'état du document, pourquoi un lance une erreur mais pas dans le cas de deps.js.

J'ai justement essayé de ne pas perdre le contenu des commentaires, ce qui m'a demandé un peu d'imagination. Mais, c'est vrai, le contenu est maintenant dilué et parfois implicite.

// If the user tries to require a new symbol after document
// load, something has gone terribly wrong. Doing a
// document.write would wipe out the page.

Pour ce premier commentaire, c'est vrai qu'on ne précise plus qu'écrire un commentaire pourrait effacer la page. On précise juste qu'il y a des cas où l'on ne devrait pas écrire :

if (shouldNotWrite(source, loadedFromBaseJS)) return false

Si on lit shouldNotWrite, on sait pourquoi on ne devrait pas écrire :

if (doc.readyState != 'complete') return false

Bon, là, on atteint une double négation (… faut que je réfléchisse à un meilleur nom, donc ;-)), mais une fois ce problème logique surmonté, on comprend que la condition pour écrire est que le document n'aie pas finit d'être chargé. Est-il nécessaire de préciser pourquoi il ne faut pas écrire dans un document déjà « scellé » ? (je viens d'y penser, je pourrais englober le test dans une fonction au nom plus évocateur, justement : documentSealed())

Le contenu du second commentaire est, lui, plus implicite.

// Certain test frameworks load base.js multiple times,
// which tries to write deps.js each time. If that happens,
// just fail silently. These frameworks wipe the page
// between each load of base.js, so this is OK.

Donc, on échoue silencieusement si la page a déjà été effacée ? Sinon, on déclenche une erreur ? Et pourquoi la page aurait déjà été effacée ? Parce que « base.js » a déjà été chargé ?

Tout les éléments sont dans le code, mais éparpillés et implicites :

Si notre code est une dépendance, dans ce contexte précis, il a été appelé par « base.js » (Ou bien il y a une erreur dans le code ? Je me fie au code et aux commentaires pour faire cette assomption.).

var loadedFromBaseJs = isDependency(source)

À quoi sert loadedFromBaseJS ? Et bien il est passé comme paramètre pageWiped. Donc, si le code est une dépendance, il a été chargé à partir de « base.js », et cette information est importante pour nous pour savoir si la page a été effacée.

Pourquoi veut on savoir si la page a été effacée ?

if (!pageWiped) throw Error(errorText(source))

D'accord. Si la page n'a pas été effacée, on n'a pas affaire a une opération anodine. Rien que d'avoir essayé est mauvais, on plante.

Tout les éléments sont donc dans le code. Plus que le comment, le pourquoi est là aussi. Seulement, il faut inférer le pourquoi. Le commentaire a l'avantage de prémacher le travail. Il a aussi l'inconvénient, parfois, de mettre notre cerveau sur off, ce qui peut s'avérer gênant si le commentaire et le code ne sont pas synchronisés.

Bonus : mise à jour de la partie impliquant shouldNotWrite :

goog.writeScriptTag_ = function (source) {
  if (!goog.inHtmlDocument_()) return false

  var loadedFromBaseJs = isDependency(source)
  if (!writePossible(source, loadedFromBaseJS)) return false

  doc.write(tag(source))
  return true
}

var writePossible = function (source, pageWiped) {
  if (!documentSealed()) return true
  if (!pageWiped) throw Error(errorText(source))
  return false
}

var documentSealed = function () {
  return doc.readyState == 'complete';
}

Maintenant, j'avais même commencé à mettre des bout de code « inutiles », juste « sémantiques » quand j'ai commencé à refactoriser. Un truc du genre :

pageWiped = loadedFromBaseJS = isDependency(source)

Là, l'idée n'est plus de virer les commentaires, mais bien de ne parler qu'un seul langage : javascript.

Quand on dit qu'un code bien écrit se passe de commentaires, c'est un peu comme dire qu'un texte bien écrit en anglais peut se passer de commentaires en français. On veut ne parler qu'un seul langage, et y placer toute l'information dont on dispose. Un commentaire en javascript, « it's an english citation in a french text ».

Après, j'essaye de montrer des exemples, je défend le point de vue des « sans commentaire », mais je suis un extrémiste : cela se voit dans les règles que je me suis fixé pour le style (voir mon commentaire précédent). Je suis juste un extrémiste dans les deux sens : je n'ai pas traduit la page de wikipédia sur la programmation littéraire pour rien. Je me fais aussi avocat des commentaires plus longs que le code !

Il se trouve que les deux techniques de programmations qui m'ont le plus marquées sont celle de la programmation lettrée, et celle de Forth. L'une prône des commentaires très détaillés, l'autre un code qui est sa propre définition (Littéralement. En Forth, on « définit des mots » plutôt que d'écrire des fonctions.). C'est de Forth que je tiens mon habitude des fonctions très courtes (une fonction qui tient sur une ligne de 64 caractères, un module de 16 lignes, je trouve ça magique).

Je vais répondre en deux commentaires, sur deux points différents. Pour commencer, je vais parler du style.

Au niveau du code dense et de l'absence de points virgules, c'est juste une question de style. Que je ne défendrais absolument pas !

J'aime bien, mais je ne pense pas être capable d'imposer un tel choix (si peu orthodoxe, qui plus est) dans le cadre d'une collaboration. Il vaut mieux un code lisible par le plus grand monde. Si tout le monde dans le projet est d'accord pour ce style (ou si je veux développer en autiste et filtrer sévèrement les contributions pour les limiter aux personnes pas trop bornée :-°), un style de ce genre est ok, mais la plupart du temps on préfèrera un style éprouvé.

La raison pour laquelle j'ai utilisé ce style est surtout parce qu'il est permit par la factorisation (ça vient tout seul). Sans la factorisation, difficile d'omettre les accolades, et si on les met à un endroit, autant les mettre partout (c'est plus consistant).

Pour le passage du goog, on touche à la première remarque que je me suis abstenu de faire pour éviter un pâté :

le passage de tout ce code en closure vient du fait que ce morceau de code est écrit dans un style particulier, que je n'ai pas le contexte autour, et que le style du code en question est bien différent du reste de la librairie. La closure est là pour ne pas polluer l'espace de nom (ni le global, ni le goog), mais dans un projet qui a adopté ce style de manière officielle, l'espace de noms sera adapté de manière à éviter une closure de ce genre (les fonctions sont prisonnières de ce contexte, alors qu'une partie d'entre elles peuvent être, à condition d'un nommage moins ambigüe, partagée par tout le projet).

Éviter la closure est une remarque pertinente et importante : quand on parle de l'impact de la factorization sur les performances, on pense au coût des appels de fonctions, mais la gestion des closures est très coûteuse au niveau temps, par rapport à, par exemple, un objet javascript. (source : un benchmark que j'ai la flemme de chercher :-°). Un projet qui est pensé avec un code de ce style va donc éviter les closures (dans le cas de ce morceau de code, ça demande de renommer errorText en cantWriteError, par exemple, ou quel que soit le nouveau nom trouvé, tant qu'il est moins vague que errorText qui n'est acceptable que dans la portée locale de ce code).

Une chose qui pour moi est importante, plus importante que la quantité de commentaires, est la cohérence du projet. Un projet peut avoir des fonctions qui font en moyenne vingt lignes avec quelque commentaires, ou une cinquantaine/centaine de lignes très commentées, ou cinq lignes sans commentaires. Dans tout les cas (pour moi), un bon codeur va écrire un code lisible dans chacun de ces styles (enfin, s'il est bon dans ce style en question). Et un mauvais codeur va écrire un code illisible, quelque soit les précautions qu'on lui a demandé de prendre. L'important est que quand on travaille sur un projet, une fois qu'on s'est fait au style, on n'a pas à en réapprendre un autre totalement différent.

Le style que j'ai utilisé est très exigeant : les fonctions ne doivent pas faire plus de cinq lignes (j'ai pas compté, je juge à l'œil), ne pas dépasser la soixante dixième colonne de mon éditeur (en fait, une des lignes fait un peu plus, là, mais comme c'est un exemple…), et dans la mesure du possible, éviter d'avoir plusieurs expressions après un if. Si on est habitué à lire un code de ce genre, un code mal écrit devient très vite évident : fonctions trop longues, niveau d'indentation qui s'accumule… La seule incartade permise par ce style est un choix ridicule de noms. Et quand je code comme ça, je relis sans cesse mon code en me demandant : « est-ce que ce nom est vraiment pertinent ? ».

Ça ne veut pas dire que ce style est bon pour autant. Il me force à réfléchir énormément à ce que j'écris et à son sens, et quand j'écris comme ça, je corrige souvent plein d'erreurs. Mais c'est aussi un style qui peut s'apparenter à du code spaghetti (comme tu le dis : « Je trouve ça moins lisible car cela oblige à faire des allez retour. »), et qui peut avoir un coût à force de créer des fonctions ou des variables (À supposer que ce coût ne soit pas acceptable. Ça dépend de la fréquence d'appel du code, de sa complexité, et de l'environnement d'exécution.).

L'effet spaghetti est censé se retrouver mitigé par le fait que quand on est dans une fonction, on ne devrait pas avoir à aller voir ce que fait une autre fonction pour s'assurer que cette fonction fait bien ce qu'elle dit (donc, pas d'aller-retour). Ça, c'est dans le meilleur des mondes. C'est le résultat recherché. Mais le meilleur juge est le novice qui doit se plonger dans un code qu'il ne maîtrise pas.

Un ami m'a affirmé préférer mon style pour la découverte d'un code (il avait deux morceaux de code équivalents pour juger), car il avait sous les yeux la « preuve » (à condition de faire confiance aux noms) que la fonction fait bien ce qu'elle dit faire.

your mileage may vary

La chose la plus importante pour moi reste d'avoir un seul style dans le projet : je ne proposerais jamais ce code comme patch à Google, parce que s'il est le seul de ce style dans le projet, tout le monde va faire des efforts pour le lire – même moi, peut-être, si je lis en même temps énormément de code du même projet, écrit dans le style commenté de ce journal.

J'ai essayé de factoriser le code pour en faire un code auto-documenté (à savoir, pas de commentaires, mais des noms de variables, fonctions, etc. qui parlent du problème).

Je préviens tout de suite que ça va choquer les âmes sensibles, parce que j'ai fait le choix d'un code dense (Les accolades sur les ifs ? C'est pour les nuls… ;-)), et sans point virgules.

Je ne défend pas forcément le code sans commentaires (tout comme je ne défend pas un code sans point virgule), mais je le comprend (Enfin, je comprend le principe. Quant à comprendre un code sans commentaires, ça va surtout dépendre de s'il est bien écrit).

(function (goog) {
  /**
   * The default implementation of the import function.
   * Writes a script tag to import the script.
   *
   * @param {string} src The script source.
   * @return {boolean} True if the script was imported,
   *   false otherwise.
   * @private
   *
   */
  goog.writeScriptTag_ = function (source) {
    if (!goog.inHtmlDocument_()) return false

    var loadedFromBaseJs = isDependency(source)
    if (shouldNotWrite(source, loadedFromBaseJS)) return false

    doc.write(tag(source))
    return true
  }

  var doc = goog.global.document

  var isDependency = function (source) {
    return /\bdeps.js$/.test(source)
  }

  var shouldNotWrite = function (source, pageWiped) {
    if (doc.readyState != 'complete') return false
    if (!pageWiped) throw Error(errorText(source))
    return true
  }

  var errorText = function (source) {
    return 'Cannot write "' + source + '" after document load'
  }

  var tag = function (source) {
    return '<script type="text/javascript" src="' + source + '"></' + 'script>'
  }
})(goog)

Il y a des choses à en dire, mais je n'ai pas envie de poster un gros pâté. Je répondrais à vos remarques si vous en avez, sinon, c'est que vous n'êtes pas intéressé et que j'ai bien fait de vous épargner le pâté (qui sera meilleur en plusieurs commentaires).

il y a aussi tout ce qui tourne autour du literate programming.

Par curiosité, pourquoi ne pas pointer vers la page en français ?

Je suis d'accord que souvent, les pages anglaises sont mieux fournies, mais il manque des choses à la version française ?

… Bon, je demande parce que c'est mon travail et que j'aimerais qu'il soit reconnu ;-)

(Pour ma part, quand je fais un lien vers Wikipédia à l'intention de francophone, je compare les deux articles avant de faire le lien.)

Et s'il y a une vrai raison pour ne pas avoir cité la version française (autre que « Ha oui, tiens, j'avais pas vu »), ça m'intéresse aussi : qu'est-ce qu'il manque ?

Un peu de remise en contexte pour mon commentaire :

CrEv :

Si tu ne vois pas les tabulations c'est que ton éditeur est réglé pour que la tabulation fasse la taille de 0 caractère. Donc là c'est toi qu'il faut blâmer, pas quelqu'un d'autre.

Moi (Daeldir) :

(moi, j'aime bien Python, mais je me fais avoir à chaque fois que je passe sur un éditeur de texte que j'ai pas configuré…)

Toi (oao) :

Si tu veux régler le problème en python 2, règle ton éditeur pour qu'il t'affiche → pour une tabulation en début de ligne, et · pour un espace.

En gros, je répondais qu'on pouvait ne pas voir les tabulations, sans pour autant avoir réglé la taille des tabulations à 0 caractères. Quand je passe sur l'ordinateur d'un collègue ou d'un ami, et que je doit coder un peu, le problème peut se poser. Et je vais pas changer la configuration des éditeurs d'une autre personne.

Concernant le reste du débat, implicite/explicite, je n'en parle pas. Seulement, l'argument de CrEv m'a fait réagir, parce qu'il part du principe que c'est notre configuration qui est à blâmer, alors que justement, c'est avec une configuration par défaut que le problème va le plus souvent se poser.

Mon éditeur est réglé pour gérer correctement le Python, et j'utilise Tab pour insérer les espace. Quand je dois changer d'éditeur, je me fais avoir au moins une fois. Python se plaint, puis je prend la peine soit de configurer l'éditeur si c'est possible, soit d'user la touche espace un peu plus que la normale (va configurer le notepad de Windows :-°).

Combien de CEO de grandes boites francaises ne sortent pas d'une grande ecole?

Ben, je voulais parler de ce que je connais (les patrons de Super U, Carrefour et Darty de ma région), mais ils sont pas assez connus :-° En tout cas, pour tout¹ ceux que j'ai rencontré, ils ont débuté au bas de l'échelle et ont fait leurs formations en interne. Pas de grandes écoles pour eux, donc.

Je cherche sur wikipédia dans le même domaine, pour voir. Serge Papin (PDG de Système U) et Natan Darty (cofondateur de Darty) n'ont pas l'air non plus de sortir de grandes écoles…

C'est juste des contre-exemples, bien sûr, et je ne pense pas te contredire en les pointant, mais bon… Au passage, on pourra me sortir « Oui, mais ça, c'était possible à l'époque… » : les patrons que j'ai rencontré m'ont affirmé le contraire : « Non, c'est toujours possible, chez nous en tout cas. »

D'ailleurs, juste pour embêter le monde :

Combien de personnes sorties d'une grande école sont CEO de grandes boites francaises ?

On pourra me dire que ça dépend du domaine… Pourquoi pas. Ça dépend peut-être aussi de la volonté et du travail des acteurs, non ? J'aimerais le croire, en tout cas, et dans ce cas, les études ne sont pas déterminantes (elle peuvent aider, hein, je dis pas, mais je pense que même en France, on peut encore s'en sortir très bien sans diplôme²).

¹: quatre gus, un échantillon très représentatif, donc…
²: je vous ferais un compte rendu quand j'aurais surpassé Steve Jobs et Bill Gates ;-)

Ou alors, c'est que tes tabulations font huit caractères, que tu utilises quatre espaces en python pour une indentation, et que ton code est indenté deux fois avec des espaces sur une ligne, puis une fois avec une tabulation sur la ligne suivante. Si ça arrive, tu ne le vois pas.

def buggy(a):
  if a == 5:
    print("ok")
  else:
    print("nope")

$ python3 test.py
  File "test.py", line 9
    print("nope")
                ^
TabError: inconsistent use of tabs and spaces in indentation

Ici, j'utilise des indentations de deux espaces et une tabulation de quatre caractères (les tabulations sont rendues comme ça sur LinuxFR), mais quoi qu'il en soit, le fait est : quand le code est indenté, on ne sait pas forcément si c'est une tabulation ou des espaces (moi, j'aime bien Python, mais je me fais avoir à chaque fois que je passe sur un éditeur de texte que j'ai pas configuré…).

… Aussi, comme LinuxFR rend les tabulations sous forme d'espaces (haha!), voilà une version avec les « charactères invisibles » affichée :

« ⋅ » :    Espace
« –––– » : Tabulation
« ¬ » :    Retour à la ligne

def buggy(a):¬
⋅⋅if a == 5:¬
⋅⋅⋅⋅print("ok")¬
⋅⋅else:¬
––––print("nope")¬