Dring a écrit 1211 commentaires

Je l'ignorais, mais je ne sais pas encore si ça change grand chose. Entre "ça existe" et "c'est utilisé et suffisamment répandu pour que je puisse m'en servir", il y a un pas.

Je vais creuser, merci pour la piste. Ca pourrait permettre de sortir des erreurs plus propres.

Il ne faut pas perdre de vue que, en l'état, le toolkit n'est prévu que pour réaliser du prototypage, donc, à priori, l'application finale n'utilisera pas ce toolkit, rendant, il me semble, ce genre de questionnement superflu.

Un bon prototype c'est - entre autres - un prototype qu'on peut reprendre en grande partie pour construire l'application cible.

Du coup, dans ton modèle, si le proto rend les utilisateurs heureux et qu'on veut aller plus loin, qu'est-ce qui est réutilisable ? Ou, est-ce que de toute façon tu penses faire évoluer ton framework pour fournir à la fois une version "développement/lab/proto", et une version "prod" ?

Autre question. Sur le fond, j'aime bien le principe de framework tout intégré, mais à quel point ton framework est plus intégré que l'existant ? Côté Front, comment je gère la zolie interface graphique ? Côté Back, comment je me connecte à des ressources de type bus de message et base de données ?

D'accord pour dire que "très chiant" c'est exagéré.

Cela dit, XML reste pénible à utiliser/taper/lire, et perso, partout où j'ai le choix pour de la configuration, c'est JSON ou YAML/INI, en fonction de "contexte web ou pas web, complexe/simple".

YAML a l'avantage d'être également utilisé par d'autres outils type Ansible qui ont potentiellement la même base utilisateur. XML reste rare pour tout ce qui est setup du système de base.

Je garde XML pour de l'échange de données inter-systèmes et quand une validation formelle en entrée ou en sortie est nécessaire.

Pas vraiment, Antédiluvien ça veut juste dire que ça date d’avant le déluge.

Ça fait des décennies que l'on développe des application avec une interface native,

Comme pour la prose, des fois on fait du MVC sans le savoir. Il y a plein de bibliothèques de création d'interfaces "natives" qui font du MVC. Mais si c'est pas écrit dessus, tu peux passer à côté de l'info.

Plus généralement, pour gérer des listes de très grandes tailes, ça reste la solution la plus simple. Pour réutiliser un max de code, ça reste la solution la plus simple.

Merde, j'ai plussé. Ca ne peut vouloir dire qu'une seule chose… :'-(

…à quand la réécriture en J2EE ? Depuis le temps, je commence a vraiment m’inquieter.

Sur un système financier, j'ai créé une boucle infernale en livrant un bugfix, qui est monté en production. Il a fallu bosser 3 jours et 3 nuits avec les ops pour corriger toutes les données et éviter tout impact pour les clients.

Sur un autre système financier, j'ai voulu livrer en environnement dev une mise à jour du paramétrage de contrôle de position titres que j'étais en train de modifier. Je l'ai livré en production. J'ai mis 15 minutes à m'en rendre compte ; le contrôle de position n'a pas été très efficace ce jour-là, puisqu'il a fallu réinitialiser tout et attendre le jour suivant pour retrouver des chiffres corrects.

Tout ça, c'était y'a 15 ans. Maintenant on peut plus faire des livraisons en production à la sauvage, et c'est pas plus mal…

Pour la référence cachée je pense à un morceau de Megadeth. « Captive honour » si ma mémoire est bonne. Mais il est possible qu’elle-même fasse référence a quelques.

Verdict ?

Ce journal aurait sa place dans les liens !

…

Bon en fait il est un peu trop long pour être complètement qualifié de bookmark, mais quand même, l’occasion était trop belle.

Cela aurait pu être pire, et être ass-bean. Déjà que j'aime pas les haricots…

En effet, ça ferait un OVNI difficile à diffuser. Je vais réfléchir à la question cette nuit, puis ma procrastination naturelle fera le reste pour oublier tout ça.

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.