Dring a écrit 1149 commentaires

J'avoue que c'est pas mal cool, et avec une syntaxe moins barbare.

Le truc chiant avec les devises, c'est qu'elles n'ont pas toutes 2 décimales. Du coup, est-ce que dans ce code la valeur du delta peut être une variable ? Je crains que non.

J'ai l'impression que ton commentaire porte uniquement sur la deuxième partie de la citation ; corrige-moi si je me trompe.

Cela étant dit : note bien que de mon côté je ne proposerai jamais de modifier un langage avec un changement d'une telle ampleur : je pense plutôt au choix fait à la création du langage. Pourquoi tous les nouveaux langages fonctionnent avec, à chaque fois, une interprétation des litéraux à virgules comme étant des floats ou des doubles ?

Pourquoi aucun langage "orienté business" n'est apparu depuis le début du déclin du COBOL ? Et pourquoi on se contente de librairies/paquetages pour supporter les décimaux sur des langages dits généralistes ?

Pourquoi même PHP fonctionne ainsi ? Il y a plus de gens qui font du calcul "scientifique" en PHP que de personnes qui font des calculs "comptables" ? Je ne pense pas - ou alors je vis dans un monde parallèle.

Tes exemples sont intéressants, mais je ne vois pas où tu veux en venir.

En général, si tu appliques une remise, dans une application de gestion, soit :
- tu stockes le montant initial, le taux, et tu recalcules à chaque fois
- tu stockes le montant initial et le montant de la réduction
- tu stockes les 3 informations
Tu ne cherches pas la réversibilité de l'opération ; tu dois juste garder le détail de ce qui a mené au résultat. Pour que ta piste d'audit soit recevable juridiquement et exploitable, entre autres.

Si tu dois couper 100 € en 3, tu divises en 3, et tu fais 100 - (les 3 montants), et soit le reliquat (0,01) va dans un compte spécial, soit il est réaffecté à un des 3 montants suivant une règle pré-déterminée.

Sans cela, je me retrouve avec 3 lignes à 33,33, donc 99.99 et un total à 100, ce qui pose un problème comptable, fait échouer la réconciliation, gueuler le client, pleurer le comptable.

Quand tu fais ton arrondi sur les résultats finaux, tu as régulièrement un problème à l'affichage, avec une incohérence entre le détail et le total. Quelque chose que le client ne comprendra pas ; et quand tu as des milliers de clients, tu ne veux pas avoir à expliquer cette différence.

Mettre l'exactitude mathématique comme but ultime, ce n'est pas toujours ce qui est attendu du programme informatique.

Pour ce type de fonctionnalités, il me semble évident que le modèle objet prend tout son sens.
(…)
La tâche est ardue, mais avec assez d'argent à la clé, quelqu'un le fera sûrement.

Les librairies existent, elles sont là, mais non, ça ne suffit pas. Il y a encore plein de monde qui privilégie les floats, doubles et autres. Notamment parce qu'un litéral représentant un nombre décimal, c'est directement interprété comme un float ou un double.

Je veux un langage qui permette d'exprimer un litéral décimal. Et que ce soit la forme par défaut. Qu'il faille rajouter un "f" ou un "d" pour dire "ah non, là c'est un float/un double".

Le pire (enfin, en Java), c'est les gens qui écrivent ça :

BigDecimal bd = new BigDecimal(5.5);

Bref, qui initient un BigDecimal avec une valeur double ou float, quand le mal est déjà fait. Et alors, on fait quoi ? Ben on passe par une chaîne de caractère, pour dormir sur ses deux oreilles…

BigDecimal bd = new BigDecimal("5.5");

Le truc super économique… Surtout que si on utilise pas une chaîne, il faut préciser séparément le nombre de décimales qui nous intéresse. Si au lieu d'un taux de TVA on manipule un montant, avec une chaîne je précise directement le nombre de chiffres de précision. Avec un double, sachant qu'en plus BigDecimal est immutable, je me tape un :

BigDecimal bd = new BigDecimal(100000);
BigDecimal amount = bd.setScale(2);

// ...vs...

BigDecimal bd = new BigDecimal("100000.00");

Quand je vous dis que les décimaux sont le parent pauvre, et que c'est au détriment de nou'z'aut', les développeurs financiers.

J'avoue que la référence à l'article était juste un prétexte pour placer ma petite fiction à deux sous.

Tiens, un petit commentaire à propos des "mathématiques de CE2". En CE2, point de nombre à virgule. Et même en CM1, on découvre surtout les fractions ; les virgules n'apparaissent que plus tard. Je me base sur la scolarité de mes enfants (donc les programmes actuels) - je ne me souviens hélas plus du programme de mon enfance.

j'espère que personne n'a traité quelqu'un d'autre d'idiot

D'un côté comme de l'autre, il y a eu des mots un peu durs à mon avis. Mais bon, on est sur Internet… Ce qui me désole, c'est de tout ramener à des notions de mathématiques, en faisant abstraction du besoin de millions de codeurs.

Et puisque je prends un ton sérieux, je peux relancer de 2 et le fer à repasser sur le croissant à la rue du genou gauche.

Dans le monde de la finance, de l’assurance, de la gestion de stock, de la gestion commerciale, des ressources humaines/paye, de la comptabilité (société ou personnelle), la quasi-totalité des calculs sont faits en utilisant le type décimal.

Je serai bien en peine de dire ce que ça représente sur l'informatique mondiale (comparé à toute l'informatique système, mathématique, recherche, graphique, jeux, …), mais je ne pense pas que ce soit négligeable, et je ne suis pas sûr que ce soit minoritaire.

Dans les années soixante, on avait un langage qui était conçu pour tout ça : le COBOL. Depuis, plus rien. Et on se retrouve à travailler avec des langages où il faut passer son temps à instancier une classe dès qu'on veut faire un calcul de base pour contrôler l'arrondi pour soit être cohérent avec les règles légales/réglementaires, soit éviter les centimes perdus.

A quand un nouveau langage spécialisé pour ces usages ? Où une expression litérale genre "123.50" serait interprété comme un type décimal, et pas un float ? Même l'autoboxing de Java, implémenté longtemps après que ce langage soit sorti de la niche de l'embarqué pour lequel il avait été conçu, ne supporte pas le BigDecimal qui reste cloîtré dans son package.

Alors je pousse ici le cri de désespoir partagé par tous les développeurs de la finance ou de la compta : "je veux un langage qui fait ce dont j'ai besoin !". Je m'en fous des intervalles ; je manipule des sous. Un centime, c'est un centime. Je veux pas qu'il prenne son indépendance même si "il y a une bonne raison mathématique" derrière. Je veux que le langage (le compilateur ou l'interpréteur) me force à me poser la question dès que je risque de créer un problème d'arrondi ou de dépassement.

J'en ai marre de corriger toujours les mêmes bugs après toutes ces années, du code qui génère une facture dont le total n'est pas égal à la somme des lignes qui la compose, et provoque la consternation de nos clients, et crée des problèmes de réconciliation qui font perdre du temps, et créent parfois des paniques (rigolez, mais quand deux lignes de plusieurs centaines de millions d'euros ne correspondent pas exactement, et qu'en plus il n'y a pas de seuil de tolérance, y'a de la sueur sur les claviers avant de comprendre d'où ça vient).

…je me lance aussi.

Alors, je lis plein de gens dire que ce serait super coûteux de tout faire en décimal ((au sens type Decimal python). Ben, c'est ce qu'on fait dans la plupart des applications financières et/ou comptables. Et curieusement, ça tient la route. Le type BigDecimal (et son pendant NUMERIC en SQL) sont quand même "pas mal" utilisés si on m'autorise cet euphémisme. Et l'exemple du COBOL est également rafraîchissant dans cet esprit.

Je lis que ce serait une connerie de passer par défaut l'interprétation des litéraux avec une partie décimale comme des décimaux. Pour les langages de bas niveau (C, C++, Rust, Go), je suis 100% d'accord. Pour les langages orientés débutant ou script, c'est moins évident. Pour le python, c'est encore plus difficile : il est aussi bien utilisé par des débutants pour son côté "je tape et je vois tout de suite le résultat" que pour des applications scientifiques avancées.

Mais au final, je pencherais quand même pour un statu quo ; et si c'est vraiment super perturbant pour les débutants de se retrouver avec un résultat qui parfois surprend, il suffit peut-être de simplement revoir les tutoriels pour soit aborder ces notions plus tôt, soit commencer avec les types décimaux fixes.

Tu m'intrigues avec TransferWise et CurrencyFair ; pour moi c'est surtout des trucs de virement. Certes ils font du change, mais avec des taux "garantis 48h", tu imagines bien qu'ils ne collent pas du tout au marché. Ou alors il y a d'autres produits accessibles via ces plateformes ?

Pour revenir à la question initiale…

Une place boursière (bon, une bourse), c'est ça : https://fr.wikipedia.org/wiki/Bourse_(%C3%A9conomie). Tu remarqueras l'absence des termes monnaies/devises dans les biens échangeables. Ce n'est pas un hasard. Je résume : une bourse est une institution, qui confronte l'offre et la demande, et est surveillée par le régulateur pour garantir sa neutralité (l'égalité de traitement entre les différents intervenants).

Un marché de gré à gré, c'est quand les échanges ne passent pas par une place centrale, mais se concluent directement entre deux intermédiaires financiers.

Le marché du change, c'est un marché de gré à gré. Ouvert 24/24, 7/7, puisqu'il suffit que tu trouves quelqu'un (personne morale ou physique) prête à échanger avec toi. Note qu'il y a des devises où le jeu est un peu plus compliqué du fait de contraintes réglementaires ou fiscales (va tenter de vendre de la roupie indienne à 18h heure de Paris, par exemple, ou de l'échanger contre du won koréen sans crosser par une autre devise).

Tu ne trouveras pas de bourse dédiée au marché du change. Ca n'existe pas.

Dans les commentaires d'autres personnes, je vois aussi des "tu peux constituer une réserve de USD blah blah blah". Les acteurs financiers ne "consistuent pas une réserve d'USD" si ils veulent se protéger contre une forte volatilité. Ils passent un contrat à terme ("FX Forward") qui revient techniquement à faire 3 opérations : un change comptant, le prêt de la devise qu'on achète, et l'emprunt de celle qu'on vend. Cela permet de garantir le prix d'achat de revente à une échéance donnée, et c'est utilisé soit à des fins spéculatives, soit à des fins de couverture de risque.

Une place boursière met en relation l'offre et la demande ; il y a donc un intermédiaire qui gère un carnet d'ordre et la cotation est basée sur ce carnet d'ordre.

Une opération a lieu à chaque fois que l'ordre d'achat avec le prix le plus élevé croise le prix de l'ordre de vente au prix le plus bas.

Conséquences (entre autres) : les différents investisseurs ne choisissent pas leur contrepartie. Il y a un prix de cotation par instrument et par marché.

Pour le change c'est un peu (beaucoup) différent : il n'y a pas de place centrale ; tu t'adresses directement à ta contrepartie. Il n'y a pas de cotation universellement reconnue (rien que chez Reuters tu as une quinzaine de sources différentes pour un cours EUR/GBP qui sont le résultats d'infos publiées par différents établissements - banques et brokers).

Il y a bien un marché du change pour les devises mais c'est un marché en gré à gré, pas une place boursière comme pour les actions ou les obligations.

D'une part, et comme indiqué par wismerhill, ce n'est pas le standard, (je rajoute que Sybase ne le prend pas en compte non plus et il est encore très répandu le bougre, surtout dans la finance).

D'autre part, dans la plupart des cas, un LIMIT 1 ne va pas être très efficace ; un index unique avec des statistiques à jour sera déjà suffisant pour ne pas continuer à lire la table "pour rien".

Se restreindre à la norme quand on code du SQL, c'est garantir que le code ne sera pas optimisé.

C'est pour ces raisons que les ORMs implémentent la notion de dialecte, permettant un certain niveau de généricité avec des performances honorables. Et encore, l'ajustement des paramètres du serveur est parfois plus efficace que la réécriture du code…

Pareil ici : un interrupteur. Quand j'ai changé tous mes volets, j'ai demandé au vendeur comment sa télécommande fonctionnait, si elle était sécurisée, etc. Vu la réponse, je n'ai pas hésité une seconde !

Juin 2015 pour moi, juste après l'achat de la machine. C'était quelle version à ce moment là ? Fedora 22 d'après Wikipedia, donc déjà 4 versions.

Je vais tenter la 27 dans quelques jours.

Quant aux IDEs… bah, ce sont des IDEs quoi, perso, ça me gave de devoir créer un fichier projet juste pour debugguer un binaire qui est de toute façon déjà (fraîchement) compilé.

Ben c'est sûr que si tu n'installes l'IDE que lorsque tu as un bug c'est un peu lourd, mais la plupart des êtres humains ne s'en servent pas que pour débogguer : c'est aussi utile pour le refactoring, par exemple.

Du coup tu fais tout dans l'IDE. On me signale même que ce serait le concept du truc.

Alors, pour ma part, tout ce qui tourne autour de UML : c'est de la merde. Les diagrammes peuvent être intéressants, mais dès lors qu'ils sont utilisés par un spécialiste ça tourne au cauchemar. La grammaire peut être assez sournoise et ce qui devait être un langage "universel" devient alors un nid à piège ("mais si regarde : le bout de la flèche est comme ça, donc c'est une relation qui se lit dans l'autre sens !"). Et au final, je préfère largement écrire une spécification en langage naturel…

Pareil pour la génération automatique de code avec cette horreur : ça ne tient jamais au delà de la génération initiale. Je n'ai jamais vu personne faire vivre un logiciel avec ça, et au final le code généré fait chier tout le monde.

Pour BPMN, je n'ai pas d'expérience directe, et j'attends vraiment de savoir comment ça se tiendra dans le temps. Mais le premier cas que j'ai pu voir, c'est jBPM+Drools, et ce que j'entends c'est : "tout est en drools, du coup c'est à la main du métier, et du coup c'est le gros merdier, personne ne comprends plus rien".

Bref, tous ces trucs me font très peur, et à part pour des petits trucs tout simples pour lesquels de toute manière n'importe qui peut sortir un truc en quelques jours, je n'ai rien vu qui ne parte pas en cacahuète.

Après c'est quand même beaucoup une question de goût, et surtout d'expérience.

Quand je lis ça :

[ -d $REP ] || mkdir $REP

Je me dis : OK, je vais créer un répertoire, mais c'est quoi le truc avant ? Ah oui, la syntaxe shell permet de "tester" en utilisant une syntaxe qui fait penser à un argument (le "-p"). Évident pour celui qui fait du shell depuis 15 ans, cryptique pour celui qui en fait peu ou prou.

En bon développeur java, le code code java correspondant (comme celui fourni par Sufllope plus bas) me semble infiniment plus clair, et donc plus maintenable.

Et puis, $REP c'est quoi ? Une simple chaîne, ou une liste de fichiers/répertoires ? Et comment se comporte mkdir si tu lui passes plusieurs répertoires ? Tout ça, un expert shell va le savoir sans avoir besoin d'aller consulter man ; là où un développeur java va préférer itérer sur une liste et tester pour chaque répertoire ce qui se passe, et comment se comporter en cas d'erreur.

Alors, comme dit également plus bas, java n'a pas été pensé pour l'écriture rapide de scripts. Mais en ce qui me concerne, l'écriture rapide de script est souvent une mauvaise solution à un problème. Mauvaise solution qui peut quand même être la meilleure par manque de temps, du coup je sais quand même faire du shell…

Quel est selon toi la contrainte à faire un langage de script avec un langage fortement typé ?

Beurk. Un wiki ou un bug tracker intégré ? Pourquoi ?

À la rigueur, faciliter l'usage de ces outils, rajouter des moyens pour simplifier l'interfaçage, voir s'associer pour distribuer des packs complets, mais surtout pas une application fourre-tout.

Bon, en me relisant je me rends compte que ma question peut sembler débile et mérite elle aussi un éclaircissement.

L'auteur indique qu'in fine il tague tout avec le même label, ce que je traduit en : on ne gère qu'une seule version globale de tout ces repos.

Je vois très bien l'intérêt de l'outil si on gère plusieurs softs certes distribués ensemble mais avec chacun son rythme de livraison. Si tout est livré par définition d'un bloc, alors un repo central semble plus adapté, et on fait les ajustements nécessaires sur la partie build

J'ai (encore) raté un truc ?

Ok, j'ai raté cette partie, mais je ne connais pas assez GO pour comprendre. Avec un répertoire par langage tout en haut de l'arborescence on a le même résultat non ?

Et pour le point sur la doc pareil je ne vois pas.

À ce stade tout ça ressemble à une solution bien compliquée au niveau SCM pour régler un problème qui se trouve en fait au niveau outil de build.

C'est quoi exactement qui vous empêchait de tout mettre dans le même repo ?

Ah, cool. Dans le précédent journal, j'étais déçu par Rust, mais là c'est de la balle.

Rust est un langage qui m'attire vraiment beaucoup, mais par manque de temps je ne m'y suis pas encore mis. Jusqu'ici je n'ai vu que des belles choses, et le seul reproche que je lui trouvais, c'était la difficulté à trouver un librairie mature pour faire une application graphique.

Mais là, je trouve que le message d'erreur est… comment dire… Cryptique. Verbeux. Inutile. Décevant.

Curieusement, ça m'a décidé à enfin l'installer et commencer à m'amuser avec.

Je lis ça :

Toujours dans le domaine des journaux, Yum et NetworkManager augmentent leur verbosité par défaut.

Et je me rend compte que RHEL est toujours sur Yum. Quand est-ce que le passage à dnf est prévu du coup ? Je soupçonne que la réponse soit RHEL 8, mais je n'ai rien trouvé sur ce sujet. Non pas que ça change grand chose pour l'utilisateur final, hein… Moi je ne fais aucune différence.

On voit bien que tu n'as pas de smartphone. Et je parie que ton T9 est désactivé sur ton vieux mobile. Ça explique pourquoi tu tapes encore en SMS ("tjr") :-).