rewind a écrit 3412 commentaires

Toute la dette a t-elle pu être renégociée avec les faibles taux d'intérêt actuels ou bien seuls les nouveaux emprunts en bénéficient ?

On ne renégocie pas la dette, la dette de l'État n'est pas comme la dette d'un ménage (malgré les sottises qu'on entend souvent). L'État peut racheter ses titres de dette, mais ça arrive très rarement.

Les titres de dettes sont en roulement (on en rembourse tous les jours et on en crée tous les jours). L'échéance moyenne pour les titres de dette française est d'environ 8 ans. C'est-à-dire que nous remboursons actuellement des titres émis il y a 8 ans en moyenne, à des taux proches de 2,5%. Et nous émettons des titres à 10 ans à des taux de 0,5% actuellement.

D'autant plus dans le cadre d'activités fortement liés à la conjecture politique, économique et énergétique que sont Engie et ADP. Rien ne dit qu'ils ont un avenir radieux même à moyen terme.

Autant pour ADP, il est souhaitable que le trafic aérien stagne ou baisse et donc, effectivement à long terme, peut-être d'ailleurs par la force des choses, ça ne sera pas la joie. Mais à moyen terme, ce n'est pas le cas. Autant pour Engie, je crois au contraire qu'elle a un avenir radieux parce que l'énergie est déjà un enjeu majeur de notre civilisation. Et l'État aurait tout intérêt à garder la main sur une telle entreprise et, en tant qu'actionnaire majoritaire, la faire bifurquer vers une production bien plus renouvelable.

Un autre journal évoquait donc que l'État percevrait 630 millions d'euros par an (sans tenir compte de la dette) donc on est bien au dessus des 250 millions que Le Figaro évoque.

L'article que tu cites dit quand même que, même dans le moins pire des cas, l'État perdra quand même 150 millions. C'est pas délirant mais en ce moment, on nous dit qu'on n'a plus de sous, c'est con de cracher sur 150 millions d'euros.

Bref, je ne dis pas que le scénario envisagé par le gouvernement est le meilleur, mais il ne faut pas non plus exagérer son impact au delà du raisonnable pour défendre son point de vue.

Je maintiens. Avec les données économiques actuelles (on pourrait aussi parler de la croissance actuelle d'ADP, on pourrait parler de l'augmentation du trafic aérien, etc), c'est un non-sens économique de vendre ADP. Ce n'est pas du tout rationnel. C'est une preuve de plus du dicton qui dit qu'on nationalise les pertes et qu'on privatise les bénéfices.

Si tu es ironique, et j'ai bien l'impression que tu l'es, c'est vraiment mal placé.

Ce n'est pas mal placé. Ce qui est mal placé, c'est d'une part de répondre à côté de la plaque (ce que fait _kaos_, j'explique après), et d'autre part d'étaler sa science pour pas grand chose.

Pourquoi il répond à côté de la plaque ? Parce que la crise de représentativité est un problème politique, et pas du tout technique. D'autre pays ont des systèmes de votes tout aussi «défaillant» que le notre sans avoir de crise de représentativité. Donc, le problème est bien politique. Est-ce qu'une solution technique pourrait changer quelque chose ? Je ne le pense pas, et il n'y a aucune raison de le penser parce qu'on a jamais résolu aucun problème politique par de la technique (sinon, ça ferait longtemps qu'on aurait résolu tous les problèmes politiques). Donc invoquer le théorème d'impossibilité d'Arrow ou la méthode de Condorcet ne répond pas du tout à la remarque sur la crise de représentativité, ça fait juste passer celui qui répond, à mes yeux, pour quelqu'un de pédant. Surtout quand le même n'arrête pas de nous dire dans ce journal qu'il ne comprend pas à quoi sert ce RIP, et donc qu'il ne comprend pas le problème politique posé par la privatisation d'ADP (même quand on lui explique).

En prime, si référendum il y a, alors notre méthode de vote est parfaite puisque c'est une alternative (oui ou non) et donc, ce vote ne souffrira d'aucun paradoxe.

Je suis allé un peu vite. Renseignement pris dans un journal communiste bien connu, les privatisations envisagés (ADP mais aussi la FdJ et Engie) vont rapporter à l'État 15 milliards d'euros. Il va en dépenser 5 pour la dette (hérésie en ce moment où le crédit ne coûte rien), et il va placer les 10 autres sur les marchés financiers pour un rendement d'environ 2.5% et donc ça va lui rapporter 250 millions d'euros par an. Les trucs privatisés rapportent en dividende 700 millions d'euros par an. Économiquement, ça n'a aucun sens.

Je veux bien me rendre aux urnes pour les trucs un peu importants. Là, c'est juste un tout petit truc, ça va me faire suer.

C'est l'arbre qui cache la forêt. Macron pratique une politique qui rend service à ses soutiens financiers. ADP est l'archétype. Ça rapporte tous les ans la somme qu'on va le vendre : ça n'a aucun sens économique. En première année d'économie, on apprend que ce genre d'entreprise, ça s'appelle une vache à lait, ça rapporte sans faire énormément d'investissement. Et donc, on ne les vend pas ! Si Macron veut vendre ADP, c'est pour faire profiter de tous ses bénéfices à quelques uns plutôt que d'en faire profiter le budget de l'État. C'est l'organisation de la pauvreté de l'État. Et en prime, il confie la vente à Bank of America où son copain de promo, auparavant son conseiller, vient d'être nommé directeur.

D'autre part, d'un point de vue pratique, les aéroports de Paris, c'est une des frontières de la France sur le monde, c'est par là qu'arrivent et partent des millions de gens. Or, une des missions régaliennes de l'État, c'est de surveiller qui et quoi traverse ses frontières. On va se retrouver à demander à une entreprise privée le droit pour la police et la douane d'être présent pour faire le travail de l'État, c'est ubuesque. Ils seraient bien capable de faire payer un loyer !

Oui, ils connaissent aussi la théorie de la relativité générale et peuvent refaire la démonstration du théorème de Fermat. À partir de là, on peut vraiment discuter entre gens sérieux.

Développer du logiciel libre, c'est l'intérêt général. Or, les fonctionnaires œuvrent pour l'intérêt général, par définition même. Donc moi, ça ne me choquerait absolument pas que des fonctionnaires développent des logiciels libres.

En particulier LibreOffice, parce que ce genre d'outils est très utilisé dans l'ensemble des administrations françaises (mais souvent, c'est le concurrent qui est utilisé).

Actuellement, l'État paye des sommes gigantesques à des SSII pour développer des monstres logiciels qui ne marchent pas (Louvois, etc). Là, on jette l'argent public par les fenêtres.

À la base, les modules étaient censés remplacer les headers et apporter plein d'avantages (dont des temps de compilation plus rapides). Déjà, dès le début, ça s'est mal passé parce qu'il y a eu un consensus pour conserver le préprocesseur (même s'il est isolé au sein d'un module, ça a aboutit à une absurdité, voir plus loin). Ensuite, il y a eu la question des headers déjà existants qu'il fallait gérer. Et puis Google est arrivé avec sa propre solution (dite Atom) concurrente de la solution déjà en place et implémentées par certains compilateurs. Au final, il y a eu des réunions à l'arrache juste avant la deadline pour que tout le monde se mette d'accord sur un truc commun. Ce qui en sort est, de mon point de vue, très bancal. Et surtout, aucune implémentation n'existe, ce qui veut dire qu'on a absolument zéro retour sur une utilisation concrète de cette fonctionnalité fondamentale (alors que généralement, même pour un truc trivial, le comité de normalisation souhaite une implémentation).

Les concepteurs d'outils (build, IDE, etc) ont alerté le comité que la proposition finale allait sans doute poser des problèmes. En particulier, quand on fait un import foo, on n'a aucune information sur où pourrait se situer ce module foo. Et il pourrait très bien être n'importe où parce que la norme n'impose aucun schéma de nommage. Et même si on scanne tous les fichiers, il peut être très compliqué de savoir qu'on a trouvé le bon module puisque la directive module peut très bien être le résultat du préprocesseur. Ce qui veut dire que pour détecter de manière sûre l'emplacement d'un module, il faut 1) scanner tous les fichiers, 2) parser les fichiers comme le ferait le préprocesseur. Bref, on nage en plein délire.

Les concepteurs d'outils ont aussi alerté sur le fait que la compilation des modules allaient être beaucoup moins parallèle que celle des fichiers actuels. En effet, les modules forment un DAG et il est nécessaire de compiler dans l'ordre topologique, alors qu'avec les fichiers actuels, on peut tout compiler en parallèle et ça passe. Donc, adieu les temps de compilation améliorés. Les concepteurs d'outils ont monté un groupe de travail pour essayer de résoudre tous ces problèmes.

Et cerise sur le gâteau, comme la proposition est arrivée très tardivement, la bibliothèque standard n'a pas été modularisée. Donc en C++20, on fera import <vector> à la place de #include <vector>, mais concrètement, ça ne changera rien. De toute façon, pour les templates, il faudra toujours lire la définition quelque part pour l'instancier. Là encore, pour l'instant, il n'y a pas d'amélioration prévue.

Pour en savoir plus:

• C++ Modules Might Be Dead-on-Arrival
• Are C++ Modules Dead-on-Arrival?

Sur ce blog, on trouve aussi une sorte de tuto pour expliquer comment ça va s'utiliser (et ça ne va pas améliorer la réputation de C++ sur sa complexité).

J'ai beaucoup de mal à croire qu'il suffise de bien typer pour supprimer tous les bugs…

Ça tombe bien, personne n'a dit ça, et c'est une bêtise. Ce que beaucoup disent (dont moi), c'est qu'un typage explicite permet d'éviter des bugs à la compilation parce qu'il y a une vérification du typage correct. Donc pas tous mais certains.

il n'a pas tort de pointer le problème, le compilo ne bronche pas, même pas un warning, ça fait partie des pièges à la con du C++ avec d'autres pièges à la con, et c'est bien dommage que C++ garde ces pièges.

Ben pourquoi broncherait-il ? La même expression deux lignes plus haut est tout à fait valide (puisque l'objet temporaire disparaît à la fin de l'instruction donc pendant le printf, il est toujours là).

Ceci dit, il y a des gens qui réfléchissent à améliorer les diagnostics dans ce genre de cas. Vu l'auteur du bouzin, ça devrait arriver dans quelques temps dans tous les compilateurs.

#include <string>
#include <stdio.h> // (1)

int main()
{
        std::string s("++123");

        printf("%s\n", s.substr(2).c_str());

        const char *c1 = s.substr(2).c_str(); // (2)
        printf("%s\n", c1);

        std::string s2 = s.substr(2);
        const char *c2 = s2.c_str();
        printf("%s\n", c2);
}

En (1), on ne dit pas stdio.h, mais cstdio.

En (2), tu joues avec le feu. Tu crées un objet temporaire, tu récupère un pointeur sur les données de cet objet temporaire et après, tu les utilises. C'est une erreur de programmation. KABOOM!

Ce que tu décris est la réalité actuelle. Elle vient aussi du fait qu'il n'y a pas vraiment de «chef de projet» (ou de dictateur bénévole) dans C++ et qu'il y a des intérêts fortement contradictoires au sein du comité de normalisation. Et ce n'est pas près de changer.

On peut pas satisfaire toute la communauté C++ mais on pourrait très bien satisfaire 90% et laisser les 10% restants sur le côté. C'est d'ailleurs ce que fait std::string ou std::vector qui satisfont 90% (voire plus) de la communauté et les autres (notamment dans les jeux vidéos) et bien ils refont leur propre roue et tout le monde est content. Même std::function, ça convient quasiment à tout le monde.

Mais en ce moment, on n'est plus dans le même schéma. Pour le réseau, plutôt que de standardiser un truc simple (genre ouvrir une socket et envoyer des données dessus), le comité est en train de se prendre la tête sur les exécuteurs. Sur les modules, pareil, je pense qu'ils ont fait de la merde et qu'au final, tous les bénéfices attendues auront disparu tellement le résultat est complexe parce que tout le monde y a mis son grain de sel.

il est beaucoup plus simple d'écrire des tests, mais vraiment beaucoup. Le duck typing (ou le typage structurel) est un bonheur pour ça

Il y a tout un tas de test que tu fais en python qui sont simplement inutiles en C++ du fait du typage statique de C++.

il existe un outillage autour de python beaucoup plus riche que pour C++. Par exemple pour reprendre mon premier point, tu es beaucoup plus aidé pour passer de python2 à python3 que pour passer mettre à jour ta base de code C++ vers le nouveau standard.

Il existe aussi des outils pour t'aider à améliorer ton code (il te propose même de patcher ton code directement).

Pour moi, ça prouve surtout que la bibliothèque standard ne satisfait pas les développeurs C++

Ça, c'est un fait. Il y a une tension entre les développeurs qui aimeraient bien qu'il y ait plus de choses dans la bibliothèque standard, parce qu'elles existent dans d'autres bibliothèques standard et que ça simplifierait tout un tas de code, et les éditeurs de la norme (principalement les développeurs de compilateur) qui estiment que ce qui peut être dans une bibliothèque externe n'a rien à faire dans la bibliothèque standard. Dit autrement, ils estiment que si le support du compilateur est nécessaire, alors ça peut rentrer dans la bibliothèque standard mais sinon ouste du balai.

Par exemple, le fait qu'il n'y ait toujours rien dans la bibliothèque standard pour faire du réseau basique est juste un scandale pour un langage comme C++ (cette fonctionnalité avait été envisagée pour C++20 mais est finalement repoussée pour C++23, au mieux).

Cependant sur des classes comme std::string ou std::vector, hormis dans certains cas très particuliers qui ne concernent quasiment personne, il n'y a aucun besoin de réimplenter la roue carrée. Parce que les implémentations dans les bibliothèques standard sont éprouvées et optimisées mieux que n'importe quelle autre implémentation.

Non mais reprenons ton paragraphe initial.

Il se base, sur l'idée de partage et de communauté, qui est foncièrement communiste.

Le communisme n'est pas synonyme de communautaire. La seule communauté que reconnaîtrait le communisme, c'est la communauté humaine.

Mais pour autant le communisme, c'est associé à l'égalité, chose que n'est pas vraiment l'Open-Source même s'il ne rejette rien en soi.

Au contraire, le libre revendique l'égalité d'accès au logiciel pour tous. Les licences libres copyleft empêche même qu'un logiciel puisse à nouveau subir une restriction d'accès.

Et surtout librisme va avec l'esprit de décentralisation, d'anonymat, de non contrôle étatique qui s'oppose au communisme…

Ce n'est pas le communisme que tu décris, c'est l'URSS. Je rappelle aussi que nos sociétés moderne capitaliste glissent tout doucement mais sûrement vers la centralisation (en particulier en France où l'état a toujours été très centralisé), d'absence d'anonymat et de contrôle étatique.

Le librisme est donc d'une gauche mais décentralisé, peut-être un peu anarchique.

En quoi les idées de gauche sont-elles liées au centralisme ? Le socialisme revendique, par définition, la socialisation des moyens de production, donc une décentralisation totale.

Bref, c'est le bordel dans ta tête. Lis au moins les pages wikipedia des concepts que tu cites, ça t'évitera d'énormes contre-sens.

Une floppée de mini jeux me semblent plus faciles à maintenir

Erreur ! Ce n'est pas parce que les jeux sont minis que c'est plus facile, bien au contraire. Ça te fera autant de jeux à coder/tester/régler, chacun ayant ses caractéristiques propres, et donc ça va accroître la difficulté par rapport à un jeu seul.

Quand mes étudiants me disent qu'ils vont faire un jeu avec plein de mini-jeux, je les mets en garde, mais souvent ils ne m'écoutent pas et à la fin, il n'y a même pas un seul mini-jeu. Parce que faire un jeu, même un truc simple genre casse-brique ou pong, ça demande quand même pas mal de temps, surtout si tu l'intègres dans un tout plus grand avec lequel il devra être en cohérence.

En très vieux (mais qui mériterait un bon coup de jeune) et en réseau, il y a XBlast.

L'ISO ne se contente pas d'un travail d'éditeur (qu'il faut aussi financer, mais dont les coûts sont liés au support final).

Je ne sais pas ce qu'il en est pour les autres normes, mais pour C++, tout le travail est fait bénévolement. Ça veut dire que ce sont les entreprises intéressées qui financent les réunions IRL, chaque participant vient à la réunion avec ses propres moyens (ou ceux de son entreprise pour ceux qui sont sponsorisés), les principaux responsables de la norme ont un vrai travail dans leurs entreprises respectives et participent quasiment sur leur temps libre, et tout le travail d'édition est fait sur github par un bénévole. Au final, l'ISO fournit juste un cadre d'organisation et un label, mais pas grand chose de plus.

Dès la naissance, avant même qu'une quelconque histoire de construction sociale ne puisse exister, on sait que selon son sexe, un bébé réagira différemment à un même stimuli.

Source ?

L'égalité est une utopie dangereuse, la nature n'a jamais, jamais, différencié les sexes pour qu'ils soient égaux, mais complémentaires. Ça s'observe et se vérifie depuis que les sexes existent, quelque soit l'espèce animale.

Sérieusement ? Tu sais, les féministes ne revendiquent pas l'«égalité» telle que tu sembles la définir, à savoir être exactement pareil. Elles revendiquent l'égalité en droit, c'est-à-dire être traité de la même manière qu'on soit un homme ou une femme. Autrement dit, une «inégalité» (ou plutôt une différence) physiologique ne devrait pas provoquer de différence de droits.

Après, le sujet, ce n'est pas de faire que les femmes soient tout pareil à des hommes, c'est comment expliquer qu'on les retrouve moins dans la discipline informatique. Dire que ça vient de leur nature physiologique est complètement absurde vu les exemples déjà cités qui montrent que suivant les époques et les lieux, cette situation peut varier du tout au tout. C'est juste logique. Donc, ça doit venir d'autre chose, comme l'environnement social.

ça n'intéresse pas les filles.

Ça, c'est un constat, pas une explication. La vraie question, c'est plutôt : est-ce que ce constat est la conséquence de la présence d'un chromosome X chez les garçons (ou d'un deuxième chromosome Y chez les filles) ou est-ce la conséquence d'une construction sociale ? Dans le second cas, ça peut se corriger (mais ça sera long). Dans le premier cas, ce n'est pas perdu d'avance parce que ça peut se corriger socialement. Dans tous les cas, ce n'est pas une fatalité à accepter.

Mon avis personnel sur la question, c'est que c'est la conséquence d'une construction sociale. Le fait que la situation varie suivant les pays et les époques est une preuve assez éloquente à mon sens.

Il n'y aurait pas moyen de préciser uniquement les paquets sources et de tout recompiler sur une Debian testing ? Ça éviterait de devoir installer des paquets Ubuntu.

La résolution mesure la densité, le plus souvent en dpi, soit en pixels par pouce.
Alors que 400x300 ou 1024x768 correspond à la définition, en pixels.

Ha merde, il va falloir mettre à jour la blague du 1er janvier : «ma résolution pour la nouvelle année, c'est 96 dpi»

ce qui est génial pour le français et très chiant pour certains langages de programmation

Mais qui a eu cette idée saugrenue? Autant certains traitement de texte transforment automatiquement l'apostrophe droit en vrai apostrophe, autant mon éditeur de texte ne me transforme pas le vrai apostrophe en apostrophe droit quand je code.

Typiquement, la STL regorge de définitions de templates qu'on peut utiliser en les instanciant dans son propre code. Du coup, je veux bien un petit exemple :)

La STL est presque complètement définie dans des .h, pas dans la bibliothèque, justement à cause des templates.

Petit exemple, imaginons que j'ai une classe template dans un .h

template<typename T>
class Foo {
public:
  void doThis();
  void doThat();
private:
  T m_data;
};

Après avoir écrit ça, j'ai alors deux choix pour implémenter les deux méthodes : soit les mettre dans le .h, soit les mettre dans le .cc (ou .cpp suivant les crémeries). Si tu les mets dans le .h, tu pourras instancier Foo avec n'importe quel type puisque tu auras accès aux définitions des méthodes (pas juste leur déclaration). Si tu les mets dans le .cc, tu ne pourras instancier que ce que le concepteur de la lib aura lui même instancié explicitement parce que tu n'auras pas accès aux définitions.

Après, si tu mets les définitions dans le .h, tu peux soit les mettre directement dans la classe, soit séparément après la déclaration de la classe et même parfois dans un fichier à part (parfois suffixé .inl) que tu inclueras dans ton .h.

Je tiens donc à souligner la grande distance qu'il y a entre des passionnés qui suivent les évolutions de l'informatique et des entreprises qui restent avant tout consommatrices d'outils en l'état.

Ce n'est pas une histoire d'être passionné ou pas, c'est une histoire de faire évoluer ses outils pour pouvoir bénéficier des avancées qu'ils proposent. Ce n'est pas propre à l'informatique, c'est comme ça partout. C'est juste plus facile en informatique puisque les outils sont pour la plupart logiciels (c'est moins contraignant que de changer de machine-outil).

Côté Visual Studio, on utilise la version … 2011 Professional. Et je crois pas que C++11 soit bien supporté dans cette version. :-)

Effectivement, mais le problème ici, ce n'est pas le langage, c'est l'âge de l'outil qui est utilisé. Neuf ans en informatique, c'est une génération voire plus. Depuis 2011, Debian a sorti quatre versions !

C'est juste que le C++, globalement, je ne l'utilise pas. Et je sais que c'est un langage complexe, dont la complexité ne fait que grandir au cours du temps.

Tu ne l'utilises pas mais tu sais. En fait, tu crois savoir et tu répètes des choses que tu as entendu dans les couloirs sans jamais avoir fait l'effort de te mettre dedans pour avoir ton propre avis.

Alors maintenant, de savoir que la complexité du langage a augmenté (ce que je vois quand je lis des exemples dans quelques journaux, je comprends juste rien), ça me motive pas vraiment à m'y mettre.

La complexité du langage n'a pas augmenté, il y a juste des nouvelles fonctionnalités, comme dans beaucoup d'autres langages qui évoluent. Et tu n'as juste pas pris le temps de comprendre. Ce n'est pas un problème du langage (parce que plein de personnes ont pris ce temps et trouvent que finalement, c'est bien pratique ces nouvelles fonctionnalités), c'est un problème de ton envie par rapport à ce langage. Tu as le droit de ne pas l'utiliser, tu as le droit de te donner de mauvais argument, mais tu peux aussi admettre que ton avis n'est pas le plus éclairé pour parler de la complexité de ce langage, notamment dans ses versions les plus récentes.