djano a écrit 1147 commentaires

Je suis vacciné du debugging à base de print/echo depuis l'université :)

Un facteur qui puisse expliquer ce choix: est ce que l'on peut debugguer du XSLT?
C'est une vraie question car je ne sais pas comment faire.

Je crois que tu as mal interprété le propos d'Antoine qui se voulait ironique :)

En tout cas merci pour le lien sur le talk de Julien Verlaguet, c'est en effet super intéressant!
Ils ont vraiment peur de rien chez Facebook! Convertir plus de 10 millions de lignes de code de PHP vers Hack, il fallait vraiment oser! En plus leur approche aussi automatique que possible, c'est vraiment hallucinamment bien pense. Maintenant que j'y pense, ils automatisent absolument tout ce qu'ils peuvent. Voir par exemple les notifications automatiques sur les projets Github de Facebook: vous n'avez pas signe le contributor agreement, etc.

Vraiment, cette boite c'est une éclatante réussite de l’ingénierie logicielle, voire de l’ingénierie tout court puisqu'ils font plus que du logiciel maintenant.

Sans piloter le GC, il pourrait être utile d'avoir un moyen de créer des données totalement hors du contrôle du GC. Cela permet d'éviter des scans inutiles. Voir de se passer complètement du GC dans certain cas, par exemple pour les données qui vont rester en vie, durant toute la vie du programme.

En java il suffit de faire du off-heap: toutes ces données seront hors d'atteinte du CC. C'est beaucoup utilisé pour faire du trading haute fréquence pour réduire la latence ou dans les bases de données pour faire des systèmes de cache, ou même dans NIO pour transférer des données en zéro copy.

Je ne sais pas si quelque chose d'aussi facile existe dans les autres langages à GC.

Pour les règles et transformations, je te conseille ces liens:

https://bitbucket.org/verateam/vera/wiki/Rules

https://bitbucket.org/verateam/vera/wiki/Transformations

Disclaimer: je ne fais pas partie de l'équipe de développement.

Je te conseille de lire l'introduction:
https://bitbucket.org/verateam/vera/wiki/Introduction

Apparemment ça ne comprend pas tout, en tout cas pas encore:

Collection of source file names.
Collection of source lines for each file.
Collection of identified tokens in each file.

Donc pas encore d'arbre syntaxique abstrait, ni de graphe de flot de contrôle. Ce qui limite les analyses possibles actuellement.

Que veux tu dire par "quel genre de scripts"?

En même temps ça m'est
déjà arrivé de passer 1/2 journée à debugger une erreur vraiment conne en shell ou en Perl. Parfois on croit gagner du temps avec certains langages et puis en fait non.

Mozilla a rendu les armes sur H264 en reconnaissant que leur approche n'a pas marche, alors je pense que H265 va passer.

De même pour les DRMs dans HTML5 hélas…

cauchemard

=> cauchemar

Par ailleurs, le lien sur dtstyle.net devrait pointer vers "http://dtstyle.net" et pas "http://linuxfr.org/news/dtstyle.net"

Merci pour l'interview!!!

The place to contribute to this code is via the OpenBSD CVS tree.

:)

Si je me rappelle bien, HAMMER a un design plus proche de btrfs, ou même ZFS de mon point de vue a 10000m de haut. Maintenant ces systèmes de fichiers ont des détails d’implémentation différents: comment sont stockées les inodes, etc.
Il me semble que c'est un B-Tree (voire un B+-Tree?) avec du Copy-On-Write. Je ne suis pas un expert de l'algorithmique des bases de données, alors ce que je dis est a prendre avec des pincettes.

Il est donc très bon pour la concurrence d’accès: readers et writers ne se marchent pas sur les pieds.
Il permet des fonctionnalités très synaptiques comme les snapshots a chaud, etc.

A l'oppose, quelle serait la scalabilité d'une solution récursive?
Quel serait l'impact sur le noyau?

Ils ont peut-être préféré privilégier la stabilité du noyau.

Hmmm on dirait que ma mémoire me joue des tours.
Voici la meilleure référence que j'ai pu (re)trouver:
http://thread.gmane.org/gmane.comp.version-control.git/189776

Ça parle d'un test fait par un ingénieur de Facebook avec 1,3 millions de fichiers, en se basant sur la croissance attendue par Facebook.
Bref aucun chiffre officiel ou officieux a se mettre sous la dent.

A noter aussi l'existence de Watchman: https://facebook.github.io/watchman/

Facebook l'utilise avec un Mercurial customise avec des plugins pour faire des checkout de leur frontend qui contiendrait 2.5 millions de fichiers au bas mot.

Elle est bonne! ^_^

Mais je m'attendrais plutôt a ce que ce soit une citation d'un prof de physique O_O

Bon je pense que nos visions ne sont pas si éloignées que ça.

Je pensais que tu étais plus jusqu'au-boutiste pour le single return.
Puisque j'essaie de l’éviter au maximum et que personne n'a trouve les arguments pour me convaincre du bien fonde de cette pratique, j’étais curieux de connaître tes arguments.

Ben déjà, rien que sur cet exemple simple, ça me fait chier de devoir regarder ou et quand la variable est assignée alors que des early exit me le montrent instantanément.
Alors imagine ce que je peux ressentir sur une fonction plus complexe.

Tout ce que je vois ce sont des lignes inutiles qui réduisent le rapport signal/bruit.

Mais je suis entièrement d'accord avec toi, plus les méthodes sont courtes, et plus c'est lisible.

si la fonction est grande avec de multiple return, tu as une bonne chance d’insérer du nouveau code après un return qui sera passé à cause d’une condition.

Euh, pour moi tu as autant sinon plus de chances d'avoir ce genre de problèmes avec du code qui a un single return.
Tu as aussi le problème du code qui réassigne les variables précédemment assignées.
OK, ça n'a rien a voir avec le problème dont on parle, juste que le style single return fait qu'il est plus facile de tomber dedans. Bon on peut toujours utiliser const/final pour éviter ça.

…
if (retVal != NOError)
{
    …
}
if (retVal != NOError)
{
    …
}
…
return retVal;

Pour moi c'est l'exemple typique pourquoi le single return est mauvais, parce qu'il permet d’écrire des horreurs pareille.
OK le compilateur sait éjecter ça, mais le programmeur doit a chaque fois payer la charge cognitive de comprendre ce code pour voir que non, le deuxième if ne fait rien (Le compilateur le fait aussi, mais il n'a pas mal a la tête lui).

En fait, le single return promeut une écriture de code qui peut facilement devenir non lisible. Exemple réel que j'ai refactore hier et aujourd'hui:
* http://sources.forgerock.org/changelog/opendj?cs=11264 , regardez la methode equals() de ConnectionHandlersMonitoringTableModel.java
* http://sources.forgerock.org/changelog/opendj?cs=11261 , regardez la methode equals() de ServerDescriptor.java

Le code n'est pas mois maintenable ou debuggable. Le flot de contrôle est très facile a garder en entier dans sa tête.
Bref, a mon avis, le code après est bien plus maintenable que le code avant.
Je vous accorde que c'est peut être un cas dégénéré, mais que je rencontre très (trop) souvent lorsque les gens essayent de coller au maximum a la règle du single return.

Un seul return améliore notablement la maintenabilité. Dans les cas simples en utiliser un ou plusieurs ne pose aucun problème tout est limpide, sous les yeux, mais lorsque le projet vieilli, il devient plus simple d'ajouter des fonctionnalités, de debuger au debugger, etc si tu n'a qu'un seul return.

Je ne suis pas convaincu par cet argument, ou bien je ne l'ai pas compris.

Les early exits ne t'empêchent pas de debugger.
De plus, tu n'as pas a gérer l’état de tes variables donc le code est plus facile a lire, comprendre, faire évoluer.

Et bien alors moi pas du tout!

Ici, tu te cognes entre 7 et 10 lignes de code (selon le coding style) contre juste entre 4 et 5 lignes de code pour lire la même chose.
Sans compter que dans un cas tu dois faire très attention au flot de contrôle alors que dans l'autre cas il apparaît immédiatement.

Et ça c'est sur un case simple, sur des cas plus compliques comme j'en vois au boulot, le code se simplifie très bien grâce a la technique du early exit.
Dans ce cas, le code reste relativement "plat" en évitant des indentations trop grandes et sa lecture est presque linéaire.

Quel est pour toi l'avantage d'un seul return?

Je préfère nettement ceci:

int aValue(int b, int c) {
    if (mafonction(b, c)) {
        return 4;
    }
    return mafonction2(b + c);
}

Voire même:

int aValue(int b, int c) {
    if (!mafonction(b, c)) {
        return mafonction2(b + c);
    }
    return 4;
}

Ca c'est en supposant que les enseignants parlent anglais :)

Pas de souci, un grand merci a toi et a tous les contributeurs pour les dépêches sur le noyau!

Non ça ne garanti pas que tous les bugs soit trouves ou que toutes les failles de sécurités soient bouchées.

Relis ce que j'ai écrit:

C'est comme ça que l'on arrive a une base de code morte parce que personne ne veut mettre le nez dedans parce que c'est moche / buggue / etc.
C'est comme ça que l'on arrive a avoir du code legacy que l'on ne peut plus toucher parce que l'on ne sais pas ce que ça fait, ni comment ça le fait.
Le meilleur moyen d’éviter tout cela et de faire évoluer le code continuellement.

Ce que je dis c'est que ça modernise le code, ça rend la base de code a nouveau attrayante aux yeux des contributeurs externes, et que ça permet de faire une revue de code parce qu'en l’améliore continuellement, on est oblige de le lire. Donc il y a des chances que l'on trouve et corrige des bugs.

Ça m'arrive tous les jours dans mon boulot. Je trouve et corrige des bugs parce que j'essaie de factoriser le code. Lorsque je factorise le code, j'essaie de voir pourquoi 2 bouts de codes sont différents. Parfois 2 bouts de code très similaires different d'une manière subtile. Je demande a mes collègues plus expérimentés pourquoi ces codes diffèrent, et paf! c'est souvent un bug.

Bien sur c'est possible.
Il est aussi possible que la faille ait pu être trouvée par ce biais.

Tu enfonces les portes ouvertes?