barmic a écrit 927 commentaires

Alors… Euh… Comment expliquer ?

Qui à dit qu'il ne fallait pas avoir de standard de code? Tu peux choisir ce que tu veux si tu ne le standardise pas au sein de ton projet ça va être la galère. Dans ton standard, il faut indiquer :

• le manière d'indenter (tabulation ou nombre d'espaces)
• les alignements (où est-ce que tu ouvre les accolades? Taille maximale d'une ligne ? Sur quoi tu fais tes alignements ? Etc)

Si tu ne défini pas ça quelque soit l'outil tu va souffrir, si tu le fais quelque soit ce que tu va choisir ça va fonctionner.

Je suis par contre entièrement d'accord sur le modèle de threads. Je me bats régulièrement contre des new Thread().start() en java.

Go et erlang sont très différents. Je ne pense pas qu'on puisse considérer go comme un système à acteurs. Les systèmes à acteurs sont théorisés depuis les années 70.

Pour le map redduce beaucoup plus récent mais pas très novateur. Il est de plus en plus délaissé car il ne fonctionne que pour des batchs là où on arrive maintenant à faire le boulot en continue avec tous les stream processing.

Les modèles de programmation (qu'ils soient parallèles, asynchrones, architecturaux,…), ne sont pas bons ou mauvais. Ce sont juste des outils efficace dans certains contextes.

Tu confond avec l'absence de règles de codage.

En quoi c'est un problème cette histoire de macro ? Ajouter CR+LF quand tu appuie sur entrée c'est douloureux ? De même pour les diacritiques ? Fait arrêter la mauvaise fois de temps en temps. Ton ordinateur fais toujours pleins de choses pour chaque événement qui lui arrive et c'est plutôt cool (c'est pour ça que c'est fait !).

L'option s'appelle smarttabs dans intellij qui le gère très bien.

Akka ? Je ne suis pas certain c'est un modèle de programmation parallèle. Oui il génère beaucoup de communication entre les acteurs, mais les acteurs ne sont pas mappés sur des threads système. Du coup c'est le runtime qui fais tout le boulot de communication. Je ne suis pas un spécialiste, mais je ne crois pas qu'il y ai une entrée ou une sortie du processus (ou du thread système) lors d'un passage de message simple (mais je peux totalement me tromper).

Avoir une garantie de sûreté d'un code threadé avec Rust est un leurre puissant mais qui, au fond, ne sert pas à grand chose.

De ce que j'ai compris de ma discussion avec un développeur Mozilla qui bosse sur Firefox. Ça leur a permis d'implémenter ce que l'on trouve depuis Firefox 57. Ils ont longtemps essayé de gèrer leur thread en c++, mais ils n'ont pas réussi a avoir un résultat sans trop de bug. Comme quoi ça a dû leur servir à quelque chose.

Non tant que tu utilise une police monospace.

while (true)
    foo (a,
         b);

Tu place foo a une tabulation et le paramètre b à une tabulation et 5 espaces (l'exemple est mouche mais ça illustre bien le propos). Que tu utilise une tabulation à 1, 4, 8 ou 11 caractères ça ne posera pas de problème.

Quand tu fais ce genre de choses le nombre de tabulations décrit ton niveau d'indentation et les espaces servent uniquement à aligner. Comme l'alignement se fait par rapport à des caractères qui ont une taille fixe (hypothèse : on utilise du monospace et par définition on n'aligne pas par rapport à un niveau d'indentation mais par rapport à la gueule de la ligne précédente). Dans tout ça la taille de ta tabulation n'entre pas en jeu.

Ça fait bizarre de le changer. Ce qui fait qu'on peut être sortis du on lui le code dans une sortie autre que son éditeur, mais la forme du code ne sera pas cassé pour autant.

Après moi j'utilise des espaces parce que c'est ce qui est utilisé dans les équipes où je travaille (et que je me fou de ce détail). Mais je n'ai vu de problème que lorsque des tabulations étaient utilisé pour faire l'alignement et là oui ça ne marche pas. C'est logique.

Je n'ai pas utilisé de vraies tabulations dans mon exemple car je suis sur téléphone.

C'est très bizarre comme principe. Si tu utilise des tabulation c'est justement pour pouvoir changer sa taille. C'est le principe de ce caractère et il est tout à fait possible de coder et que ça reste lisible quelque soit la taille de ta tabulation et c'est tant mieux parce que 8 c'est énorme et qu'avec make tu n'a pas vraiment le choix.

De plus, parmi les appli ou lib qui ont besoin de performances, j'en connais beaucoup qui sont codées en C++ (tensorflow, v8, electron…) mais très peu en Java.

Netty, lucene, vertx, ratpak, lagom, énormément de l'écosystème big data (Cassandra, hazelcast, hadoop, spark, storm,…). Kafka et akka sont écrits en scala et utilisent donc la même jvm et le même jit.

Une licence ? Ou tu fais du non libre :-P

Et malgré ça personne n'a trouvé le moyen de builder un Firefox pour la précédente version de Debian à cause de rust. Tri-vial

Rust comme C ou C++ ont une grande intrication avec le système. C'est un enfer dès que tu sors des chantiers défini par ta distribution. Avoir plusieurs versions utilisables du compilateur et/ou plusieurs versions de bibliothèques n'est pas quelque chose de simple et AMHA la meilleure solution reste d'utiliser un container docker qui va avoir ton outillage.

Alors qu'en C++17 c'est facile ?

Mais je pense qu'en fait il ne faudrait plus jamais évaluer le C++ dans son ensemble qui pour des raisons de compatibilités est en vrai une chose infâme. Si tu utilises le C++11 / C++14 en évitant les vieilleries (ce qui est largement possible, si tu n'utilises pas Qt du moins) tu gagnes largement en cohérence et en puissance. Si un projet mélange les vieilles structures avec les nouvelles, c'est en effet hideux, mais c'est à éviter en réalité.

Il existe _une manière de s'en assurer ? Parce que tant que l'on ne peux pas garantir qu'une base de code ne le fais pas il faudra pour moi évaluer le langage dans son ensemble.

Tous les langages ont des fonctionnalités bizarre et tu peux trouver un sous ensemble à tous les langages qui est propre, mais pour que ça ai du sens il faut pouvoir l'évaluer. De la même manière que ce demander si on peut en rust s'interdire tout unsafe.

Codendi de XeroX ;

Puis de Viseo. Par contre c'est effectivement https://www.codendi.com/accueil/…

Il y a aussi novaforge de Bull Atos. L'idée de novaforge c'est qu'une forge est une collection d'outils et que c'est dommage de refaire tous ses outils. Ils font donc un travail d'intégration d'outils par exemple ils utilisent mantis comme gestionnaire de bug. Une fonctionnalité qu'ils mettais en avant pour la version 3 (il y a 4 ans maintenant), c'est une gestion des releases. Cela permettait d'avoir comme une gestion de release maven, mais en plus global (construction automatique de release note depuis le gestionnaire de ticket, tag de tous les documents, tag des sources, passage de l'intégration, mise à jour des liens de téléchargement sur le site et ajout de la documentation de la nouvelle version,…).

Ça ne convient probablement pas à tout le monde, mais c'est une façon différente de voir les choses que le point de vu minimaliste qu'on voit partout (et qui pour beaucoup est minimaliste uniquement parce que les projets sont jeunes et développé par peu de gens.

Sur l’inaccessibilité en HTTPS, là en revanche, pour moi en 2018 c’est inexcusable.

C'est clair.

Excellente !

Ou juste réutiliser le parseur qu'ils ont fait.

n'est il pas possible d'avoir accès à la source qui génère les pages (genre une base de données)

Il faut pour ça que les admins de linuxfr nettoient la base de données. Ils peuvent le faire, mais ça prend du temps (et ce n'est pas particulièrement amusant).

mieux à l'application qui écrit ces données en base ?

L'objectif c'est d'avoir des données, le code qui les produit ne sert à rien dans ce contexte.

---

Pour répondre à la dépêche, je ne trouve pas que le problème est pris dans le bon sens. AMHA il faut limiter le crawling de linuxfr.

Il vaut mieux le faire une fois et fournir une archive (ça pourrait même être mis à dispo par l'équipe de manière (bi ?)mensuelle). À partir de là tout ceux que ça intéresse peuvent monter leur propre solution.

Comment se passe l'interaction avec le reste de la communauté ?
Par exemple :

• est-ce-qu'il existe un document simple regroupant la description des règles pour ne pas avoir besoin de cet outil ou pour en simplifier son déploiement ? Par exemple sous la forme d'un linter
• est-ce-qu'il est envisageable de voir certaines fonctionnalités arriver directement dans le PHP standard ?
• php n'est plus vraiment tout seul est-ce que cet outil adresse aussi hip-hop ou hack ?

En tout cas merci pour le partage c'est super intéressant

[…] tu pourrais t'intéresser à leurs arguments […]

J'veux bien, mais je n'ai trouvé que des assertions (y compris dans le liens que tu donne d'ailleurs).

[…] au hasard […]

Au hasard quelqu'un qui parle de maven 2 et qui dit clairement qu'il n'a pas essayé maven 3 et que ça a peut être changé (en même temps l'article a 8 ans…).

Une partie de ses critiques sont vraies, je dis simplement que les plugins sont simples.

Les plugins sont peut-être triviaux à écrire, mais je préfère avoir l'option de ne pas avoir à en écrire[…]

La question n'est pas d'avoir à les écrire, mais à les comprendre. J'ai expliqué qu'il était facile d'en écrire simplement pour expliquer que si vraiment tu as un problème avec l'un d'entre eux, tu peux télécharger son code source et le lire, ça n'est pas incroyable.

[…] ce que me permettent par exemple CMake ou Gradle.

En terme de mélange de choux et de carottes… CMake ne fait pas de build donc effectivement tu n'a pas à écrire de plugin (je ne sais même pas si cette notion existe pour eux), tu va par contre peut être devoir écrire une macro spécifique pour certaines dépendances. Gradle si tu as plus de quelques lignes de groovy, je pense qu'il est plus sage d'écrire un vrai plugin qui sera testé plutôt que de fourrer un gros bout de code directement dans ton fichier de build. Tu as un plugin maven connu qui permet aussi d'utiliser du scripting ant (les scripts ant c'est pas fou, mais ça fait le taff).

la compréhension des pom.xml requiert la compréhension des plugins utilisés, qui s'assimilent parfois à de la magie

Euh… Il faut comprendre ce qu'on fait. Que tu veuille utiliser un truc que tu connais pas trop pour apprendre c'est cool, mais alors tu ne peux pas reprocher que c'est magique. Les plugins maven sont triviaux. En écrire est vraiment très simple. Si ça reste de la magie c'est que tu ne cherche pas à en savoir plus sur ton outil. Ce n'est pas forcément grave, mais ne va pas reprocher à l'outil d'être magique.

La question n'est pas de savoir si tu as tort ou pas, mais plus tôt si tu as compris la démarche du journal. Serge nous présente toujours des aspects pointus du c++. Soit parce qu'il les utilise dans sa génération de code (c'est alors du code généré donc les besoins ne sont pas les même) soit juste des choses possibles du langage part amusement ce qui me semble être le cas ici.

Ce genre de choses permettent de voir des mécanismes des templates, c'est cool.

Si tout le monde peut sortir sa petite technique pas piquée des hannetons en mode remède de grand mère c'est justement que ça n'a qu'une influence faible. Les constructeurs n'ont pas grand intérêt à fournir des CPU bruyants voir qui se downclock tout seul sous l'effet de la chaleur et ils fournissent une méthode bateau. De la même manière les vendeurs de machines complètes n'ont pas un intérêt flagrant à te fournir une machine bruyante et ils font ça à l'arrache.

Il y a un moment où il faut arrêter de croire que tout le monde est idiot sauf sois-même.