barmic a écrit 927 commentaires

On ne les gèrera pas.

Tu me reprends sur la distinction entre manager et gérer ? :)

Même si GIMP lançait des sandbox, la revue et compilation doivent être faites de notre côté. Héberger aveuglément un binaire d'inconnus complets est une aberration.

Ça se discute. Tu pensais faire des revues pour les brosses par exemple ? Ce sont des vecteurs d'attaque eux aussi. On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox et c'est régulièrement un vecteur d'attaque.

C'est la raison pour laquelle les plug-ins compilés ne seront pas acceptés tant qu'on n'aura pas l'infra. Certains bénéficieront d'exception évidente comme G'Mic. C'est expliqué dans mon article.

Je sais lire :) c'est moi qui ai mis le lien.

Je ne prévois pas de gérer le site. Je suis développeur pas animateur de communautés. Nous avons une très grosse communauté avec des gens très actifs et même pas mal plutôt techniques.

C'est cool je n'avais pas cette vision :)

Ça rend GIMP très résistant aux problèmes[…]

Alors c'est pas si simple, je sais que ce n'est même pas le début du projet, mais ça rend publique toute une politique et ça vous expose à du bad buzz (grand publique ou de communauté), des discussions interminables, etc. Même sans être community manager ça te touchera/concernera. Je n'ai aucun doute que j'aurais toujours accès au code de GIMP, mais est-ce que les développeurs auront suffisamment la foie pour ne jeter l'éponge ? Je n'espère pas. Et c'est bien pour ça que je me permet de faire mes remarques. Je préfère t'avertir de mes craintes, pour que tu sois moins surpris si (malheureusement) ça arrive.

Si Gimp ne diffuse que ses propres extensions […]

Petit spoil : ce n'est pas ce qui est prévu.

La gestion des extensions est très ambitieuse, mais ça me fait un peu peur pour vous. Quand tu gère des extensions du deviens responsable au moins en parti d'elles. Regarde l'actualité récente de Mozilla… De plus ça demande une infrastructure de pki. Actuellement rien ne cloisonne les extensions, donc tu veux faire de la revue et le build chez toi.

C'est super comme idée, mais je crains que ça ne consomme toute ton énergie (je serais heureux de me tromper !)

Ça fait bizarre de comprendre tes commentaires… :)

Du coup ils ont tellement eu peur d'Azul qu'ils ont créé GraalVM, c'est ça ?
Ça devait vraiment leur faire peur pour en arriver à publier ça sous licence GPLv2 :)

Je passes plus de temps à lire le code des autres qu'à en écrire et vraiment, la notation hongroise aide. Je suis bien plus efficace sur ce genre de code que sur le code sans cette notation.

On appelle ça l'habitude, je te sors de ta nomenclature et tu va beaucoup moins aimer. Si tu as à trouver un bug qui nécessite de s'intéresser à autre chose que ce que tu encode dans tes identifiants et ça va tout de suite être moins drôle. Tu semble être particulièrement attaché aux overflow en arithmétique, mais ce n'est qu'une classe de bug parmi d'autres (en plus elle se détecte très facilement).

Tu as surtout omis OpenJDK de ton analyse…

Le JDK Oracle est une distribution d'OpenJDK. Il en existe 2 autres assez connues : celle de RedHat et celle d'IBM. Ces derniers ont des supports déjà plus long que ce que permet Oracle. Mais surtout l'air post-JDK8, s'annonce très chamboulé. Le projet adopt OpenJDK est une distribution libre de ce dernier. Il est soutenu par des entreprises tel qu'IBM. Et devrait intéresser quelques acteurs par exemple avec leur API simple REST et documentée pour récupérer un JDK. IBM semble particulièrement investi vu que l'on peut y trouver une version avec leur gc maison.

Après pour faire tourner une prod, je ne vous pas ce que la distribution d'Oracle apporte (pour les dev il y a des outils qui peuvent être utiles sans pour autant être nécessaires).

Les entreprises beaucoup n'ont pas la vision de ce qu'est un runtime pas à jour et font tourner du java7 ou inférieur. Ça ne changera rien pour eux. Pour les logiciels un minimum maintenus le passage à jigsaw n'est pas insurmontable.

Je n'aime pas particulièrement Oracle, mais dire qu'ils font ces changements juste pour diminuer la période de maintenance c'est aller un peu vite. Ils ne sortirai pas une version tous les 6 mois, mais ce contenteraient de la version tous les 18 mois (LTS). Ce serait bien plus simple.

Je ne suis pas qu'Oracle est un saint et qu'il n'y a rien à regarder, mais qu'il faut garder la tête froide et s'intéresser à ce qui se passe aussi dans les communautés avant de crier au loup.

Ben je pense que c'est vraiment plus à rapprocher de l'architecture Flux décrit par Facebook. Il n'y a pas de binding du model dans la vue. L'objectif c'est que la donnée a un chemin unidirectionnelle. En tout cas c'est pour ça que Flux a était créé.

Là il faut this.value, ou nommer autrement le parametre, mais on perd en expressivité.

Devoir faire ça pour des getters, setters ou accesseurs c'est tout de même dommage. C'est les trucs les plus triviaux possible (on parle d'une ligne ou d'une affectation) que dans une bonne partie des cas on génère. Teinter tout son code pour ça je trouve ça vraiment dommage…

Et il y a plein de cas ou on utilise un nom de variable membre simple, qui peut être source de conflit avec un argument d'une méthode : "name", "type", "value", "enabled", etc.

Ça m'arrive et généralement c'est qu'il y a quelque chose de mal nommé. Si tu as un champ de ta classe qui s'appelle name, c'est bizarre qu'il possède une méthode foo(std::string name) mais qui ne représente pas la même chose. C'est probablement que l'un des 2 pourrait être nommé de manière plus clair (par exemple en explicitant de quoi est-il le nom).

Mais pour moi, du code propre et bien rédigé doit pouvoir se lire sans coloration syntaxique.

Je suis un peu d'accord, mais je dirais la même chose pour tout ce que l'on cherche à encoder dans les identifiants.

La recherche de la simplicité devrait réduire fortement la charge cognitive et donc limiter le nombre de variables manipulées, le nombre de variable mutée, le nombre de scopes parcourus, la taille du code,…

Mais il reste les cas de code très technique qui sont moins là pour la propreté de l'algo que comme boilerplate autour des techno que tu utilise par exemple.

La coloration, c'est pratique pour essayer de démêler un code illisible.

Donc tu peux t'en passer si tu n'a aucune dette technique et si toutes les pull requests sont parfaites à la première revue :)

Perso je préfère y mettre la sémantique, parce que c'est la seule chose que mon éditeur ne peux pas me présenter.

Je compare à la notation hongroise, mais justement tu met quoi dans tes identifiants :

• leur type ? est-ce que c'est un entier ? le quel ? virgule flottante double ou pas ? un tableau ? un vecteur ? une liste chaînée ? une instance de ta classe A ? une lambda/fonction qui prends 1, 2 ou 3 paramètres ? Les paramètres c'est des références ? des copies ? ils peuvent être null ? ils ont des valeurs par défaut ?…
• son scope ? local, global, dans une fonction, un paramètre de ta méthode, un champ hérité de ta classe ?
• s'il est static ? si c'est une constante ? s'il est volatile ?
• s'il est partagé entre des threads, tu fais quelque chose ?
• s'il est thread safe tu as un marqueur pour le dire ?
• s'il a une chance d'être null ou pas tu le marque comment ?
• …

Si tu encode tout ça dans tes identifiants, d'une part tu essaie de réécrire ton système de type, mais en plus tu va totalement surcharger ton algo. Le seul qui peut me donner toutes ces informations c'est mon éditeur. Que tu fasse le choix de présenter certaines informations plutôt que d'autres dans la liste non exhaustive que j'ai donné est un choix subjectif qui n'a rien de global. Tu as des contexte où on se fout de connaître la porté, mais savoir ce qui est volatile ou pas est critique.

Comment vous en sortez vous quand vous devez lire du code hors de l'éditeur ?

barmic dit :

Et oui si on me passe un snippet de code je vais le mettre dans mon éditeur pour le lire. Je ne lis pas les pdf avec cat, mais un lecteur pdf. C'est pareil pour le code.

J'utilise mon éditeur préféré. Tout le temps. S'il peut m'arriver de lire du code hors, il faut vraiment qu'il soit trivial.

C'est une habitude à prendre, mais sincèrement, j'ai autant besoin de savoir qu'un identifiant représente un champ non statique mutable que de savoir que c'est un tableau ou un vecteur par exemple. Je suis donc vraiment trop limité quand je ne suis pas dans un éditeur adapté. Du fait que, je n'ai pas les helpers (des tooltips qui te montrent la déclaration par exemple) ni la navigation dans les sources. Si je n'ai pas besoin de ça, alors le code est suffisamment concis pour ne pas avoir besoin d'ajouter des bidouilles aux identifiants pour les comprendre.

Et en soit ça va très vite. Je n'ai aucune difficulté à prendre un bout de code et à l'ouvrir avec mon éditeur, ça ne représente pas de gros overhead. Pour upsource, que j'utilise aussi, mon intellij a un plugin vraiment pratique et je n'ouvre plus l'interface web.

Je trouve aussi que le fait d'être dans un environnement habituel permet de plus facilement y passer du temps. Quand tu regarde du code avec ed à travers une connexion série depuis un serveur au milieu de la zone interdite de Tchernobyl, tu va être moins enclins à approfondir ta lecture.

Perso je n'aime pas du tout. C'est une surcharge cognitive qui va encore ajouter des caractères augmentant la taille des lignes pour une info que mon éditeur est tout à fait en mesure de me restituer via la couleur. Et oui si on me passe un snipet de code je vais le mettre dans mon éditeur pour le lire. Je ne lis pas les pdf avec cat, mais un lecteur pdf. C'est pareil pour le code.

C'est pareil d'ailleurs pour les INomDeClass et les NomDeClassImpl.

Je ne me suis pas penché sur les autres que je ne connais pas, mais ELM n'implémente pas MVC.

Le contrôleur de MVC manipule le modèle souvent, le modèle est représenté par les données membres d'une classe contrôleur. Le contrôleur possède l'état, on appel l'une de ses méthode et il modifie l'état. Ici l'Update va prendre l'état courant en paramètre + un message qui est généré par la vue et il va en ressortir un nouvel état (+ éventuellement un message). L'Update ne possède pas l'état, c'est quelque chose qui lui est donné en paramètre et qu'il ne peux pas modifier. Un paquet de frameworks MVC obligent la vue à passer par le contrôler pour accéder au modèle (c'est lui qui le possède), alors que dans cet architecture ça n'est pas le cas.

Ça paraît anodin mais conceptuellement c'est très différent et ça a pas mal d'impacts.

Je n'ai pas touché ni à Elixir, ni à Erlang, mais de ce que j'en sais les gros points forts :

• grâce au runtime (entre autre) la possibilité de faire de la mise à jour à chaud de ton logiciel en prod
• un système à acteur qui permet une programmation parallèle efficace et plutôt souple

AMHA ça permet de trouver un endroit où tout reste à faire. Loin des vieux BSD, Linux, Windows ou MacOS où tout a déjà était fais ou tenté. Haïku est terre en friche où pleins de choses restent à faire. Une conquête de l'ouest pour développeur. Le fait qu'il possède quelques concepts différents d'unix et qu'il s'adresse uniquement au bureau lui confère un aspect particulier bien à lui. Ça lui permet de faire des choix différents. Il y a quelques années Linus avait du trancher entre 2 ordonnanceurs de tâches, il a choisi celui qui est fait par un contributeur payé plutôt que celui qui se vanter d'être plus efficace sur informatique personnelle (là où appartement celui qui a était choisi était très bon à partir d'un grand nombre de CPU). Pour trouver des infos, il s'agissait de BFS.

Ça va les sophismes…

Tu commence bien en coupant ma phrase… M'enfin bref…

La norme a été finalisée en 2011 mais elle a été discutée pendant des années et une grosse partie des fonctionnalités était déjà implémentée dans les compilateurs.

C'est exactement ce que je dis dans ce que tu as remplacer par "…".

Non, le C++ est juste un outil avec des avantages et des inconvénients.

Si il l'est et Serge sans paille nous le montre régulièrement.

Cet interfaçage demande à faire une couche de translation C ou C++98 vers C++11. Hors ces 3 langages sont presque totalement compatibles donc il est assez subtile de s'assurer que l'on ne leak pas du C dans le reste de ton programme.

Oui c'est le principe de la compatibilité. Si tu veux compiler du C ou du C++98 directement dans du C++11, tu peux. Si tu veux interfacer proprement, tu peux. Tu aurais voulu quoi ? Que le C++11 interdise tout code antérieur et demande de tout réécrire en Rust ? Quand tu appelles du code C depuis le FFI, Rust ne vérifie pas non plus magiquement que ce code est sûr.

Il pourrait très bien me permettre de compiler certains fichiers dans un mode compatible C/C++98 et compiler le reste dans un mode strict. J'ai pas besoin que ce soit le compilateur ça peut être un outil qui répond 1 ou 0 et ça me permettrais de maitriser où est-ce que j'utilise ou non des fonctionnalités particulièrement dangereuse (soit pour m'assurer que c'est limité soit pour switcher progressivement de l'un vers l'autre). Ça ne casse en rien la compatibilité le code généré peut être identique c'est juste dans les étapes de vérifications qu'il y a une différence.

Je ne sais pas ce que tu appelles bugs mais cppcheck est capable de détecter des problèmes comme les fuites mémoires. Je ne pense pas que ce soit fiable à 100% cependant.

Il ne te dis pas que là tu devrait utiliser du RAII.

Interdire des fonctionnalités n'est pas la "façon de penser" de C++ et ça casserait la compatibilité.

C'est ce que les développeurs font ! Les développeurs C++ s'interdisent des pans de la norme pour certains les exceptions pour d'autres les pointeurs nus. Que ce soit fait par le compilateur ou un quelconque outil d'analyse statique je m'en fous, mais si ça n'est pas outillé c'est à la responsabilité des développeurs et c'est forcément moins fiable que si c'était un outil.

De plus les compilateurs ne se gênent pas pour ajouter de nouveaux warning ce qui peu potentiellement ça suffirait amplement. Toujours pas besoin de casser la compatibilité.

Oui c'est vrai. Et c'est le cas de tous les langages qui autorisent du bas niveau, même de Rust en unsafe. Maintenant on peut en discuter des heures mais il n'y a pas de langage parfait (à part haskell installé par nix sur minix, bien-sûr), il faut forcément faire des compromis qui forcément ne plairont pas à tout le monde.

Bla bla bla. Les autres aussi ne sont pas parfait donc on a le droit de… Bref

La gestion de la mémoire en C++ est dangereuse particulièrement car l'utilisation correcte du RIAA est à la charge du développeur, s'assurer qu'il le fait bien est un travaille continue de l'équipe. Là où un énorme paquet de langage vont faire quelques trucs pour te contraindre (être plus sécurisés par défaut, t'obliger à écrire juste avant « attention je suis peut être entrain de faire une grosse connerie ici ! », etc). Si tu ne souhaite pas voir l'importante différence qu'il y a entre ces approches, c'est dommage.

Mais se poser la question de comment industrialiser la qualité d'une base de code ce n'est pas insulter le langage, hein ?

Là, tu racontes absolument n'importe quoi.

Si tu as :

struct foo {
    struct bar *bar_create();
    void add_bar(struct bar *b);
};

struct foo *foo_create(int foo_param);
void foo_delete(struct foo *f);

void foo_do_something(const struct foo *f);

Ton héritage continuera d'exposer les méthodes que tu veux cacher. Pire encore si cette classe foo évolue tu va récupérer du code de manière totalement transparente.

Mais surtout, j'ai parlé d'un potentiel overhead. Je dis qu'il faut y faire gaffe.

Pff j'ai abandonné l'utilisation du pattern singleton. Le fais qu'il n'existe qu'une seule instance qu'une classe n'en fait pas un singleton.

[…] c'est la galère pour […] créer une instance locale avec des paramètres différents.

C'est précisément ce que tu cherche à interdire avec un singleton.

Si tu veux juste permettre d'avoir différentes instances de la même classe, mais réutiliser les précédents s'ils ont des paramètres compatibles ce qu'il te faut c'est une factory et c'est ce qu'est ta méthode creatA(). Pourquoi tenter de contraindre à ce qu'une classe soit singleton ? Si tu ne peux la construire que via sa factory, cette dernière peut faire tout le job.

Ensuite, le "C++ moderne" c'est C++11 et ça fait déjà 7 ans.

Oui, mais un écosystème ça met potentiellement un temps encore plus important à se mettre en branle. 2011 c'est la date de sortie de la spec, il faut que les compilateurs arrivent (ça arrivent assez vite parce qu'ils font le travaille en avance de phase), que c'est compilateurs soient dispo dans les distrib' et ensuite il faut faire évoluer l'écosystème et ça n'est vraiment pas un problème trivial quand le changement demande à casser la compatibilité (l'intérêt du C++ c'est sa compatibilité à toute épreuve ?).

Et si vraiment tu dois t'interfacer avec du vieux C++ dégueu ou même du C, bah tu fais comme tout développeur normal et tu codes une classe ou quelques fonctions qui l'encapsule proprement et limite le couplage de code.

Dans la liste des arguments comme quoi le C++ est cool il y a :

• depuis C++11 on a plus de problème de gestion de la mémoire
• on peut s'interfacer avec du C++ comme du C nativement donc réutiliser un écosystème très large

Cet interfaçage demande à faire une couche de translation C ou C++98 vers C++11. Hors ces 3 langages sont presque totalement compatibles donc il est assez subtile de s'assurer que l'on ne leak pas du C dans le reste de ton programme. Une méthode C++98 qui te retourne un objet dont les méthodes manipulent des pointeurs nus. Tu va devoir proxifier l'ensemble de l'objet en tenant potentiellement compte de l'overhead que tu introduit (c'est important pour un langage dont l'un des principaux arguments c'est la performance).

Pour la gestion mémoire, en statique : cppcheck, en dynamique : valgrind;[…]

cppcheck se contente de voir les bugs, non ? Tu peux lui dire d'interdire l'utilisation des pointeurs nus par exemple ? De bien déprécier tout ce qui a était rendu smell par C++11 ? Ça me paraît compliqué parce que la RAII est de l'ordre du design. Mais s'il le fait c'est génial :)

---

Je sais que j'ennuie au plus haut point ceux qui aiment bien le C++ et qui disent que depuis C++11 le langage est devenu vraiment cool (on pouvait faire des smart pointer intelligents avant), mais pour moi tant qu'un projet tel que C++ Core Guideline n'aura pas véritablement diffusé au sein de la communauté ça restera en langage dangereux. La plupart des fois où on en parle j'ai comme réponse qu'il faut suivre les bonnes pratiques, mais chacun a un peu les siennes et les rendre contraignantes (que le build ne passe pas si on les viole) est nécessaire. J'ai pas de doute que vous écrivez du code de qualité, que vous connaissez les bonnes pratiques, que vous suivez l'évolution du C++, mais il y a des fois où vous êtes fatigués, des fois c'est juste un truc qui vous a échappé, une subtilité dans le code qui ne se voit pas facilement,…¹

Salut,

Je ne comprends pas bien ton journal. D'un point de vu du besoin, je ne connais pas la durée de vie de ton runtime (quelques secondes en CLI ou des mois sur serveurs par exemple).

Mais personnellement j'ai abandonné définitivement tout singleton en utilisant de l'injection de dépendance. Avec ce pattern tu n'a plus à faire des pieds et des mains pour être thread safe, te poser la question de l'API, devoir retoucher tout le code appelant quand tu décide que quelque chose devient un singleton, tu normalise la manière de faire du lazy loading et ton code reste testable.

Le coût ne me parait pas si grand et ça apporte beaucoup de choses intéressantes.

Son seul "gain" en terme de sûreté face à C++ concerned l'absence theorique de memory leak… Au prix d'un GC aux latences linéaire au nombre d'objets…. Problème qui est par ailleurs pratiquement éliminé en C++ avec la RAII

L’absence (réel) de buffer overflow. J'imagine que ça n'arrive pas si on utilise les bonnes pratiques (rien arrive quand on utilise les bonnes pratiques) de la version suffisamment à jour du C++, mais comment s'assure-t-on que notre base de code est bien passé à ces pratiques ?

une gestion plus pratique (et sûre) de la mémoire

Cette remarque classique est surtout valable pour du C++98. Aujourd'hui avec le RAII et les pointeurs intelligent, ce n'est plus tellement le cas.

On lis continuellement cette rengaine « faut regarder le C++11/14/17/… », mais tu ne peux pas nous dire que C++ c'est bien parce qu'il a un écosystème qui est là depuis super longtemps et demander de ne pas juger les anciens standards. Si tu t'interface avec du code qui est en C++98, alors tu peux pas te permettre d'oublier cette version.

D'autre pars comment est-ce que je peux savoir que mon code est bien en C++XX (XX étant la version que tu préfère évaluer) ? Il existe des linters qui te permettent de t'assurer de faire de la RAII par exemple ? Parce que sinon tu viens juste de nous dire qu'il n'y a pas de problème de gestion non sûre de la mémoire parce que si les développeurs font attention il n'y a pas de problème…