arnaudus a écrit 5604 commentaires

Bref, pour l'utilisateur lambda, ce n'est pas franchement plus compliqué à mon sens.

Ce qui est compliqué, c'est d'avoir une procédure différente pour chaque machin que tu veux compiler, en fonction des préférences du développeur. Ton raisonnement pourrait être poussé à l'extrême; si le dev a mis au point son propre système de build et qu'il te faut taper "gogo-gadget o compilateur", tu vas trouver ça débile, même si c'est marqué dans le README.

Ça n'est pas non plus pour rien qu'il y a des standards de facto, et je trouve que la compilation se prêterait justement pas mal à avoir une procédure un peu normalisée (avec un certain nombre de cibles standard: clean, make, install, etc). J'imagine aussi que ça simplifierait pas mal la vie aux différentes distributions, et que ça réduirait la fragmentation.

Tu réalises que Ninja est un remplaçant à Make ?

Non, ça n'est pas un remplaçant, et c'est bien ça le problème. systemd est un remplaçant à sysVinit, mais ninja est une alternative à make. Tu es donc exactement dans la situation décrite par le xkcd ; tu crées un système alternatif avec l'espoir qu'il remplace à terme l'existant, mais tu crées juste une nouvelle syntaxe qui s'additionne aux systèmes de build alternatifs qui existent.

Si au lieu de remplacer une brique par une autre équivalente tu préfères rajouter un wrapper et une nouvelle dépendance, t'es pas sorti de l'auberge…

Une dépendance à GNU make sur une distribution linux? C'est le genre de dépendance qu'on peut certainement assumer, non? En plus, la dépendance peut très facilement sauter si ton système de configuration fait en sorte de tester la présence de make sur le système.

Je pense justement que le coût d'une dépendance à un logiciel qui est installé par défaut sur la quasi-totalité des distributions et un wrapper trivial est minime par rapport au coût d'être dans l'inconnu total quand tu télécharges un .tar.gz.

Je crois que je comprend un peu ce que veut dire l'OP. La réalité, c'est que la diversité dans les systèmes de build est incoutournable, et qu'il n'est pas réaliste de faire comme si elle n'existait pas. L'avantage avec les autotools, c'est que quand on téléchargeait un tar.gz, on savait qu'il fallait faire ./configure && make && sudo make install. Là, chaque système de build vient avec une syntaxe à lui. Bien sûr, la réponse évidente, c'est "il suffit de remplacer make par ninja, et truc par machin, et de rajouter l'option --bidule = target, rien de bien sorcier. Sauf que chaque système de build concurrent va venir avec sa syntaxe, et que connaitre les syntaxes des 12 systèmes de build courants, ça va être possible pour un admin sys, mais pas pour quelqu'un qui installe un truc hors paquet de sa distrib tous les six mois.

Moi je trouve que les trois étapes "configuration", "compilation", "installation" sont très claires, et qu'il existait déja une syntaxe (pas forcément très logique, pas forcément intuitive, mais elle avait le mérite d'exister). Pourquoi ne pas s'être débrouillé pour que tout système de build génère par défaut un exécutable "configure" dans le répertoire, un Makefile minimal de trois lignes qui appelle ninja ou n'importe quoi d'autre, avec une cible "install" qui installe le truc? C'est ça le problème, c'est l'apparition de nouvelles syntaxes pour faire la même chose qu'avant.

Wikipédia semble lister un grand nombre de langages compilés et reflexifs (Go, objective-C, etc). Je ne les pratique pas, donc je ne sais pas vraiment de quel type de reflexivité on parle, mais j'ai quand même l'intuition que la reflexivité ou la méta-programmation doit empêcher la plupart de l'élimitation de code mort ou de code non-utilisé.

J'imagine que comme toute grande entreprise, les compétences initiales sont noyées dans la lourdeur, la bureaucratie, les décisions de décideurs qui ont une formation top-moumoutte en prise de décisions décisionnelles… Parce que ça ne date pas de Gmail, la "mise à jour" de Google maps d'il y a quelques années ont transformé un site incoutournable en quelque chose de quasi inutilisable. À se demander si Google ne se reconvertit pas dans le minage de bitcoins…

Je ne suis pas sûr qu'il soit aussi simple de détecter les bouts de code qui ne seront jamais appelés (et quand tu compiles statiquement, est-ce que tu veux vraiment que le compilo choisisse ce qui est lié et ce qui ne l'est pas?). Mais de toutes manières, ça pose une énième fois la balance entre la liaison dynamique et la liaison statique, c'est toujours aussi compliqué.

Sur le fond, c'est dur de lui donner tort, sur la forme, il y a des trucs douteux. L'exemple des compilateurs, par exemple. Pourquoi compiler du C++ prend des plombes? En grande partie, parce que c'est une tâche hyper complexe, du fait de l'évolution du langage vers de plus en plus de trucs à faire au moment de la compilation (y compris l'optimisation). Pourquoi afficher des trucs prend des plombes? En partie, parce que le nombre de pixels n'a pas augmenté linéairement dans le temps, en partie aussi parce qu'on a amélioré les algorithmes d'affichage (sub-pixellisation, etc), en partie parce qu'on a complexifié les choses à afficher (transparence, coins arrondis…). Nier que les ordinateurs d'aujourd'hui font aussi des tâches beaucoup plus complexes, ça rend quand même l'argument moins pertinent.

Tout grossit aussi parce que les briques de base s'améliorent en terme de fonctionnalités. Ça me semble être une évolution difficile à enrayer pour les bibliothèques de base, par exemple : "et si vous faisiez ci, et si vous faisiez ça", avec l'argument de "mais votre concurrent X le fait!". Un exemple tout con, c'est par exemple d'avoir besoin de fonctions mathématiques pas complètement courantes (je ne sais pas, la fonction probit dans un programme en C, par exemple). Idéalement, il faudrait quoi? apt install lprobit-dev et #include "probit.h", chacun contenant quelques lignes de code? Ça ne marche pas comme ça. Il va falloir installer un gros paquet contenant des centaines ou des milliers de fonctions (boost?), puis appeler un gros .h qui va inclure d'autres .h qui vont inclure d'autres trucs, et voila, ça y est, on a bloaté son système et son logiciel. Honnêtement, j'ai du mal à imaginer de vraies alternatives.

Ça permet de pouvoir le poursuivre. D'une manière générale, c'est de toutes manières le seul but des licences, non? Je ne connais pas de licence qui empêche physiquement quelqu'un de faire ce qu'il veut avec le code.

Après, tu peux diffuser sous copyright strict ; le code ne peut être reproduit ou diffusé de quelque manière que ce soit. Ajouter des termes de licences non-libres mais garantissant la libre diffusion offre la possibilité de contrôler ce que les gens ont le droit de faire ou non avec le code. Je ne prétends pas que c'est bien ou que c'est mal (en l'occurrence je crois que ça n'a que peu d'intérêt dans le cas dont on discute).

Ceci dit, pour revenir à ta remarque de départ, il faut bien se rendre compte que dans la très grands majorité des cas, les licences, libres ou pas, sont principalement de l'esbrouffe. Quand tu développes un bout de code sur tes week-ends et que tu le diffuses sous GPL, tu espères que la GPL dissuade éventuellement les gens peu scrupuleux de s'approprier le code. Ça n'est qu'un espoir, parce que si quelqu'un le fait, alors il faudra faire valoir tes droits (avocats, expertises, procès…). Tout le monde sait qu'il n'est pas très rationnel d'investir des dizaines de milliers d'euros dans une procédure judiciaire complexe (et assez incertaine vu la jeunesse de la jurisprudence sur ce genre de sujets) pour faire valoir des droits symboliques. Si tu attaques une grosse entreprise et que par miracle tu gagnes au tribunal contre une armée d'avocats spécialisés, tu vas pouvoir prétendre au remboursement partiel de tes frais de justice, et éventuellement un dédommagement à la hauteur réelle du préjudice subi (c'est à dire, de rien du tout à pas grand chose). Au mieux du mieux, le tribunal t'offrira l'équivalent du prix du logiciel que l'entreprise t'a pompé, si tu l'avais développé pour eux. S'il s'agit d'un utilitaire un peu marginal, ça ne va pas aller chercher loin. Et tout ça, c'est si ton adversaire est une entreprise française. Si c'est un groupe d'adolescents Biélorusses, tu vas te marrer rien qu'à savoir quelle institution judiciaire est concernée…

Du coup, comme toute licence, oui, c'est principalement du flan. Ça te donne juste la possibilité éventuelle de faire valoir tes droits contre un méchant, et tu espères que ça va faire suffisamment peur au méchant pour être dissuasif.

Pour garantir l’intégrité d’un document on le signe numériquement. Ce n’est pas le rôle d’une licence.

Ça n'est pas du tout la question, je pense. L'objectif est de laisser tout le monde distribuer un bout de code en rendant la distribution d'une version modifiée illégale. La signature numérique peut permettre à un tiers de s'assurer que le document est exactement le document d'origine au bit près (si ce tiers s'en donne la peine). Tu peux distribuer du code GPL et signé (dans ce cas, les versions modifiées ne seront plus signées et tu pourras éventuellement prouver que tu n'as pas certifié les versions modifiées). Bref, la signature numérique ne répond pas du tout à la question «je souhaite distribuer un document de manière à ce que chacun puisse à son tour le distribuer librement, éventuellement en changeant de format ou en appliquant des modifications mineures qui ne remettent pas en cause les droits d'auteur sur le document, mais sans pouvoir en modifier de version modifiée».

À la limite, je trouve que ça pourrait justifier d'une licence de type "CC-ND": la seule raison légitime de diffuser un code modifié pourrait être de falsifier un document historique. Bon, je joue l'avocat du diable, parce que je ne suis pas convaincu moi-même, et qu'il me semblerait intéressant que des passionnés puissent faire tourner ce code éventuellement patché sur du vieux matos. Mais bon, sur le fond, dès qu'on touche à des documents historiques, la question du "verbatim" me semble défendable.

J'imagine que c'est surtout l'intérêt historique du truc qui est prépondérant dans ce cas. Une sorte d'archives pour les historiens. Après, libre ou pas, ça n'est peut-être pas si important.

J'imagine que ça peut éventuellement être important, par exemple si un suspect a été pris par une caméra de surveillance à une certaine distance. Il y a des cas où ça doit pouvoir faire la différence, même si la plupart du temps ça n'a aucune importance.

Oui, je suis sûr de mon coup. De nombreux musiciens ont mis leurs enregistrements sous licence libre (souvent CC-BY-SA ou équivalent), et de manière surprenante, les œuvres orchestrales aussi. Tu peux commencer par wiki commons, par exemple, il y en a des milliers, et c'est plutôt propre au niveau des licences. Il y en avait énormément sur Jamendo avant le drame de l'affaire StMaclou, j'imagine que tout est encore sous licence libre, et doit être téléchargeable quelque part.

Pour les musiques de jeu, il y a un catalogue plétorique. La plus grande partie du répertoire classique est disponible sous licence libre, et pour ce genre de jeu, c'est plus que suffisant pour trouver des heures de musique d'ambiance adaptées. La qualité de l'exécution et de la composition sont d'ailleurs extrêmement supérieures à ce qu'on peut trouver en musique de jeux libres, et je crois que je ne comprendrai jamais comment on peut livrer des jeux libres avec une musique insupportable, alors que la musique symphonique libre est tellement facile à récupérer! Et qu'on ne parle pas de la personnalisation des jeux, le catalogue est tellement vaste qu'on peut trouver n'importe quoi qui corresponde à n'importe quelle ambiance…

Il y a aussi une gradation entre les raisonnements fallacieux (sophisme != raisonnement fallacieux). Il y a aussi certains raisonnements qui sont logiquement faux mais socialement vrais. Par exemple, l'argument de la pente glissante est assez frappant, puisqu'en effet, c'est un raisonnement fallacieux, sauf que l'organisation de nos sociétés humaines fait qu'il est souvent valide, puisqu'on fonctionne beaucoup par des raisonnements relativistes (on perçoit l'évolution d'une situation par rapport à l'existant, par exemple).

je suis pas persuadé que le gain en performance soit considérable quand on utilise des templates.

J'imagine que ça dépend du code, comme tu ne passes pas par une vtable, ça te fait sauter les indirections.

Moi, c'est plus la béatification des calculs par le compilateur qui me fait douter. Attention, je ne prétends pas que ça n'est jamais utile, c'est juste qu'il y a tellement de manières plus ou moins élégantes de le faire, mais qui ont le mérite de ne pas brainfucker du code… Déja, tu peux très bien calculer tes trucs au runtime et stocker les résultats en mémoire si les calculs ne sont pas trop longs (de toutes manières, s'ils sont trop longs, ta compilation va durer quinze plombes, ça n'est pas intéressant non plus). Par ailleurs, si ce que tu veux c'est une grosse base de données sur des séries mathématiques (un million de décimales de pi, les nombres premiers entre 10 et 20 millions, etc), alors une solution équivalente serait de les calculer une fois et de les mettre dans un .h (éventuellement généré automatiquement lors de la compilation?). Si c'est quelque chose de plus spécifique à ton soft, c'est certainement tout à fait raisonnable de coller tes trucs dans un fichier ou une base de données et de lire dedans la première fois que tu en as besoin (typiquement, ouvertures aux échecs, etc). De toutes manières, il arrive forcément un moment où la recherche dans une bdd prendra plus de temps que de recalculer, donc c'est toujours un compromis.

Ça ne retire en rien des capacités impressionnantes des dernières évolutions du C++, mais c'est juste que j'ai du mal à trouver ça exceptionnellement intéressant.

Mouais…

static constexpr frozen::map<T, decltype(F{}(v)), sizeof...(Vs)> cached = {{Vs, F{}(Vs)}...};

Franchement, rien qu'à parser ça, c'est chaud. Il y a deux qualificateurs (static et constexpr), avec static qui est hautement polysémique en C++ et constexpr qui vient d'être introduit dans la norme. Ensuite, on a visiblement une map, à dimension ésotérique. Et ensuite, on a une syntaxe pour l'initialisation qui est hyper obscure. J'ai l'impression qu'avec un peu de doc, je pourrais m'en sortir avec une connaissance du C++ "normale". Par contre, il faut comprendre aussi ce que bien peut faire decltype(F{}(v)), sizeof...(Vs), et {{x}...}, et dans mon cerveau, c'est un gros "syntax error". Ça ne ressemble en fait même pas à un truc compilable, en fait. On est vraiment en présence d'un nouveau langage, mais ça ressemble autant que C++ que perl ressemble à java…

À mon avis, il faut voir les templates pour ce qu'ils sont : des outils au service des développeurs de bibliothèques. Si tu regardes le main, la syntaxe n'est pas trop affreuse.

Par contre, j'avoue que j'ai vraiment un doute sur cette tendance à remplacer le polymorphisme par la programmation générique. Bon, c'est toujours un peu compliqué de reprocher aux développeurs de chercher le gain de performance, mais le coût associé est, à mon avis, terrifiant. Pensez par exemple aux logiciels libres : de combien de contributeurs potentiels se prive-t-on avec un code truffé de variadic templates qui s'apparentent au brainfuck? Ça n'est même pas un problème de lisibilité, c'est avant tout un problème d'abstraction, de syntaxe obscure, et de normes tarabiscotées, qui transforment la méta-programmation en exercice complètement élitiste, réservé aux professionnels du domaine. C'est quasiment un autre langage, en fait.

C'est un peu tendancieux quand même, parce que la licence mentionne souvent des clauses supplémentaires (typiquement, no warranty) qui couvrent également l'utilisation.

Tu y vas fort quand même, une grosse partie de la publicité revient, au sens étymologique, à partager avec le public des informations sur le produit que tu veux vendre : si vous cherchez une voiture neuve, j'en vends pour 14999€, et regardez comme elle est belle. Dans l'absolu, je ne vois pas vraiment de mal à ça, impossible d'avoir une activité économique viable si tu n'as pas de moyen d'informer des clients potentiels de ton existence.

Après, tu as la partie qui consiste à présenter des truc sous leur meilleur jour, mais dans un certain sens, c'est pareil que de mettre du déodorant avant un rendez-vous galant. L'objectif n'est pas non plus forcément de pousser l'autre à un acte irrationnel. Là où le marketting est nuisible, c'est (i) quand il est agressif (on t'abreuve d'informations alors que tu n'en as pas demandé), (ii) quand il est mensonger (prix, qualités du bien, etc), ou (iii) quand il utiliser des techbiques de manipulation pour provoquer des achats compulsifs qui seront regrettés.

Dans les faits, c'est fou le nombre de gens qui ne comprennent pas comment fonctionne le système d'imposition, et qui sont prêts à tout un tas de comportements irrationnels pour éviter de «sauter une tranche». Y compris chez des cadres sup, ou tout un tas de gens qui ont le bagage culturel pour comprendre ce qu'est un taux d'imposition marginal. Mais non, tu as toujours dans ton entourage quelqu'un qui est fier de t'expliquer qu'il a dû faire quelques centaines d'euros de dons pour ne pas sauter une tranche (*).

On trouve un truc un peu similaire avec la déclaration frauduleuse de frais réels quand on est dans les taux d'imposition les plus bas. Là, c'est sûr qu'il y a un peu d'argent à la clé, mais très peu en comparaison des risques qu'on prend (bon, les risques sont tout relatifs, mais c'est plutôt la honte d'être affiché lors d'un contrôle fiscal qui me semble rédibitoire).

Pour revenir à la défiscalisation, je me demande si ça n'est pas le même biais cognitif que celui qui semble inciter certaines personnes à acheter des objets dont ils n'ont pas besoin parce qu'ils sont en promotion.

(*) le cas des seuils est un peu particulier, mais les seuils pour les allocations familiales ou autres prestations sont différents des seuils d'imposition (j'imagine que c'est volontaire, d'ailleurs, ces seuils sont tous différents les uns des autres ce qui, globalement, limite l'effet total). En tout cas, même si on est bien renseignés, les seuils s'appliquent sur les revenus de l'année N-1 ou N-2, avec des montants réévalués tous les ans, c'est bien difficile de prévoir en 2018 quel sera le seuil qui sera retenu en 2020…).

pas du tout bien pour le vrai cote pro

Attends, le but n'est pas non plus de ne jamais rien dire. Il s'agit juste de réagir de la manière la plus à même d'avoir des effets positifs sur le boulot. C'est différent de parler du politiquement correct (qui, en effet, consiste à ne jamais rien dire) et de l'optimisation de la communication (qui peut par exemple consister à toujours foutre la pression sur certains bons éléments pour tirer le meilleur d'eux, et de manière injuste à épargner les moins bons qui réagiraient mal à la pression).

Pour eux cela aurait forcement du finir en guerre!

Le truc, c'est qu'il n'y a jamais eu de discussion politique menée un verre à la main autour d'une table remplie de bouffe qui n'ait jamais incité personne à changer d'opinion. Ces espèces de joutes verbales peuvent être considérées, d'un certain point de vue, comme une sorte de jeu d'imitation des éructations des hommes politiques en plein débat. Sauf que les politiques font ça parce qu'ils sont regardés par des gens qu'ils veulent influencer. Quand tu as un débat entre deux politiques à la télé, ils n'essayent pas de se convaincre l'un l'autre, ils communiquent à leur électorat potentiel. Tonton Dédé, il fait ça parce qu'il veut te donner son point de vue, dont tu te fous éperdument ; c'est surtout ça qui montre que les gens «singent» un exercice qu'ils n'ont pas vraiment compris. Du coup, l'idée d'éviter ce genre de confrontation stérile, je la trouve intéressante, c'est vraiment du temps perdu.

De toutes manières, dans un contexte professionnel, tu n'es souvent pas vraiment en mesure d'adapter le fond de ta réponse, tu peux seulement adapter la forme. Et le problème avec l'empathie, c'est que ça peut aussi modifier ton propre comportement, et ça, c'est plutôt néfaste, voire catastrophique. J'ai l'impression que dans un milieu pro, la meilleure(*) attitude reste de «simuler» l'empathie tout en restant totalement étanche aux sentiments que la situation pourrait provoquer. C'est donc quelque chose de très complexe, qui demande probablement beaucoup d'effort, de formation, et d'entrainement ; la plupart d'entre nous sommes assez nuls dans ce domaine, et c'est probablement ça qui cause le plus de problèmes en milieu pro. On n'ose pas dire les problèmes, ou on attend trop longtemps, on reposse les décisions désagréables, on les prend en «oubliant» d'en parler aux gens, ou on leur en parle trop tôt, ou trop tard, on est trop francs ou pas assez, on est trop autoritaire ou pas assez, on est trop vindicatif ou pas assez… Au final, ça n'est positif pour personne, mais si c'était facile, ça se saurait.

(*) meilleur au sens utilitariste, probablement. Je ne suis pas non plus convaincu qu'il serait forcément agréable de vivre dans une société ou tout le monde ait un parfait contrôle de l'expression de ses sentiments, de manière à ce que tout le monde soit le plus satisfait possible de ses relations sociales avec d'autres êtres humains. Ça me semble même assez effrayant.

• Apprendre à poser une question de manière à obtenir une réponse pertinente.

Et ils ont torts, la Terre à une forme de patate

Pas moins que les pyramides Égyptiennes sont pyramidales, ou que les anneaux de Saturne sont plats. Quand quelqu'un affirme qu'un objet physique a une forme mathématique, on accepte forcément une certaine approximation, puisqu'aucun objet physique ne peut être parfait.

La forme de la Terre est sphérique à 0.3% près, c'est une excellente approximation dans la vie de tous les jours. Et la "patatoïdie" (écart à l'ellipsoïde de révolution) est infinitésimale. Il est donc parfaitement pédant de prétendre que la terre est patatoïde, même si c'est évidemment vrai.

Au passage, la Terre est une boule, pas une sphère. J'ai écris "sphérique" parce que je ne connais pas l'adjectif pour une boule (boulique?).