groumly a écrit 3282 commentaires

Après la blockchain n'est pas inintéressante en soi

Pas vraiment, non. En 2010, peut être. Plus maintenant. Ce qui définit une blockchain, c’est un gros réseau sans intérêt direct à tricher sur les écritures. C’est ça qui garantit l’intégrité de ce qui est écrit dessus.

Ce qui par définition cantonne les blockchain a des données fondamentalement publiques: si t’es sur des données privées, tu as par définition des acteurs énumérables et identifiables, qui vont à priori avoir un intérêt direct à tricher. Ou s’ils n’ont pas un intérêt à tricher, on appelle ça 🥁 un tiers de confiance 🥁! Le truc que la blockchain est censé éliminer. Et donc, ben, retour à la case départ.

Mais même sur des données publiques, t’as un problème fondamental. Toute cette validation, ca coûte cher. Faut bien payer les mineurs. Ah oui, mais ils ne peuvent pas être payé par les parties de la transaction, sinon on retourne au problème initial, ils ont un intérêt à tricher. Ils peuvent pas être rémunérés par un tiers non plus, par définition on n’en a pas. Alors on les rémunère via la blockchain elle même. Et hop, on vient de créer une crypto monnaie! Cool, donc on a résolut le problème initial, mais maintenant on a un appeau a arnaqueurs, attirés qu’ils sont par de l’argent virtuel, et on a finalement créé plus de problèmes qu’on en a résolu.

Le concept initial était honnêtement intéressant. Ça valait clairement le coup de le tenter. Mais ca fait bien une dizaine d’années que n’importe qui avec un esprit critique a compris que la technologie est fondamentalement cassée.

Le problème des mod de caisses enregistreuses qui grugent est à la source: tu ne peux pas faire confiance à l’entité qui émet la transaction. Si tu ne peux pas lui faire confiance, pourquoi ferait tu confiance à ses écritures sur une blockchain?

Plutôt que de réécrire le log à la fin de la journée, la caisse oubliera d’émettre une transaction sur 3. Ou émettra une transaction pour 75% du montant réel.

La seule chose que garantit une blockchain, c’est l’immutabilité des données une fois écrites. Des données immutables mais fausses, restent fausses. Qu’elles soient distribuées, 0 trusts ou signées par le pape, si la caisse prétend avoir reçu 5 euros quand elle a reçu 50 euros, c’est pas une blockchain qui va résoudre le problème.

Je n'ai donc jamais compris ce que ça apportait.

Des ennuis juridiques quand tu te fais gauler. Et de la bureaucratie. C’est important la bureaucratie.

C’est pas un tiers, c’est l’entité qui a délivré le diplôme.

On peut retourner la question, quel intérêt aurait les banques à prouver que leur argent ne vaut rien?

Faut être un peu cohérent à un moment, soit le problème de confiance est réel, soit il ne l’est pas.

Mais dire « Bitcoin resoud le problème de confiance » pour ensuite dire « en fait, non, mais c’est pas grave parce que personne ne va faire ça », c’est un peu facile.

Faut peut être se calmer un peu la, on est très loin du « c’est une pute, un rabin et un noir dans un ascenseur » quand même.

La blague initial ne se moque pas des non binaires, c’est juste une association absurde entre la non binarité des genres et la binarité des booléens. Le suivi étant juste la blague vieille comme le monde sur dix/deux en binaire.

Renvoyer un optionnel, par exemple, va m'empêcher de chaîner les appels, et va me forcer à écrire beaucoup de boilerplate moche, à moins de n'avoir que des optionnels partout (bonjour la complexité pour vérifier chaque optionnel au début de chaque fonction, sans compter l'impact sur les perfs).

Heu, ouais, mais si t’as pas d’élément le plus grand, il va bien falloir gérer ça quelque part quand même. Soit tu gères ça au call site (voir le call site du call site), soit tu laisses ça remonter en mode « quelqu’un d’autre peut pas l’faire?!? ».

Dans le premier cas, t’es pas dans une semantique d’exception, mais de gestion de code d’erreur. Le compilateur peut t’aider si le langage a un support avancé de ce genre de choses, mais au final, la problématique est surtout « cosmétique »: comment écrire le code de facon concise et lisible. Utiliser des exceptions parce que ça te permet de try/catcher au call site plutôt qu’un if return, c’est un peu bourrin. Et surtout, ça va pas fondamentalement résoudre le problème si le call site risque de se prendre plus d’une exception. Même topo si tes call stacks sont très profondes: t’as un très probablement un problème architectural. Si tu viens me dire qu’un if/return est trop cher, ma réponse va être: j’en doute, en tout cas pas sans un benchmark sérieux montrant un impact concret (pas un benchmark qui cherry pick « 50% mieux », en omettant de dire que les 50% mieux, c’est 2ms, ou 0.1% du temps d’exécution total).

Dans le deuxième cas, c’est très précisément ce qu’il ne faut PAS faire avec des exceptions. Les laisser remonter dans une couche qui n’est même pas au courant que les couches inférieures existent.

Comme tu dit, les exceptions doivent être exceptionnelles. Ne pas trouver un élément dans une collection n’est pas exceptionel, c’est attendu, et ça doit absolument être géré au call site. Pour être tout à fait honnête, pour du code métier, c’est très dur de trouver un exemple ou les exceptions sont justifiées. Ton code métier, il a des cas d’erreurs, et ils sont spécifiés clairement (ou devraient l’être, à l’ingénieur de bosser avec ses stakeholder quand il en découvre). Les erreurs techniques, dans leur immense majorité, elles sont plutôt predictibles, et se ramènent très souvent à une erreur métier. Ta db est en carafe? Est ce que c’est si différent que ne pas trouver ton élément? Probablement pas.
Ton dao/repository/whathaveyou, lui va probablement vouloir faire la différence entre « pas trouvé » et « bestel il a pété la db et elle a fait pfft », pour ton logging/monitoring notamment. Mais la encore, y’a des façons beaucoup plus élégante de représenter ca. Tu reçoit soit le résultat, soit une erreur. Ça se modèle très bien avec un tuple, et des enums vont rendre le code de gestions d’erreur beaucoup plus simple à écrire parce que ca se découvre tout seul.

Je ne mettrais pas plus de disque dans un cas exceptionel non plus. Les I/O ça peut foirer pour un paquet de raisons tout à fait légitimes et courantes. Idem pour le réseau. C’est pas vraiment un cas exceptionel, et si le call site par du principe que l’io va passer, ben le code est très fondamentalement buggé (et a probablement des problèmes plus gros que de savoir s’il faut lancer une exception).

Plus de ram, je mettrais ça effectivement dans une exception. Essentiellement parce que si t’as plus de ram, c’est potentiellement très difficile de s’en sortir, vu que tu risques d’avoir besoin de ram pour libérer de la ram. Disons que c’est un peu la branche sur laquelle t’es assise, si elle pete, ça devient tout de suis plus compliqué.

Bref, de mon point de vue, les exceptions posent 2 gros problèmes:
- perte complète du flow de contrôle ou tu vas de la à de la d’un coup sans crier gare
- problèmes des performance lié au stack unwinding etc

Le deuxième point s’applique surtout à des très gros projets, donc rarement pertinent pour le commun des mortels. Ça se mitige bien si le compilateur transforme le type de retour pour un tuple (typeDeRetour, Erreur) de façon transparente, et ajoute le sucre syntaxique à la volée. Genre ce que fait swift. Bon courage pour introduire ça en c++ par contre, le train a quitté la gare, comme on dit outre quebin.

Le premier, ça devient plus compliqué. Déjà, les unchecked exceptions, c’est vraiment de la merde. Ça sort de nul part et paf, pastèque. Forcer à les déclarer aide. Forcer un try léger au call site aide aussi. Ça évite de faire un appel qui peut lancer, et le rater parce que ta signature inclue l’erreur lancée.

Alors, certes, ta fonction peut aussi lancer, et celle qui l’appelle aussi, sur 50 niveaux, retour à la case départ, on a un goto déguisé. Pour être tout à fait honnête, si tes exceptions bubblent sur plus de 2 niveaux, t’as un très très très gros problème de leaky abstraction. Les couches ne sont pas isolées du tout si tu peux remonter plus de 2 niveaux. Et ça, c’est un bien plus gros problème que de savoir si les exceptions sont autorisees ou pas.

ça nous laisse avec des cas réellement exceptionnels, qui se comptent sur les doigts d’une main. Genre « on a plus de ram » ou « un des core du cpu a disparu à la volée » et autres cas tarabiscotés du genre. J’ai pas de réponse pour ce cas là. Mais disons que c’est très très très loin d’être courant, et si ce genre de gestion représente plus de 0.00001% du code écrit, je serais surprit. Je serais déjà surprit si ne serait ce que 1% des projets gèrent ce genre de problèmes.

Bref, au final, c’est un faux débat. Le concept même de l’exception (une erreur opaque que tu rebalance au niveau supérieur) est plutôt un anti pattern, et se gère beaucoup mieux avec un type result, ou un tuple syntaxique. Et vu le pot de pus que sont les exceptions en c++, je trouve pas ça délirant de les interdire.

« Pas toujours vraiment de travail de composition » est probablement plus correct :)

Recopier la partition c'est une chose. La deviner à l'écoute s'en est une autre.

Je doute que la façon de reproduire ait une quelconque incidence sur le fait que ça soit une contrefaçon. Si je fait une copie à la main d’un album de Gaston Lagaffe, plutôt que de le photocopier, ça reste une contrefaçon.

Dans l’ensemble, je suis d’accord que beaucoup de partitions vont être des contrefaçons. OLGA à du fermer à cause de ça. Mais ils donnaient des partitions exactes d’œuvres, avec les riffs, les solos, et la tablature complète qui collait à la chanson. La composition complète était reproduite (et oui, la composition écrite est une œuvre).

La ou je voit du flou, c’est sur un milieu comme le jazz (ou le blues), ou il n’y a pas vraiment de travail de composition. Les mecs partent sur une grille d’accord qui est dérivée d’une gamme, qui est elle même dérivée d’une sous division précises des fréquences audio + une note de départ, et partir de la, c’est 99% de l’interprétation. Ces sous divisions ont été choisi y’a des siècles, et ont tendance à être stable à travers différentes culture. Je cherche pas à diminuer le travail/talent, mais dans l’ensemble, les progression d’accords, c’est un truc un peu mécanique, pas vraiment créatif.

Pour faire un parallèle (probablement douteux), imagine que je mette en place en site d’inspiration pour les DM de jeu de rôles. Et que dedans, j’ai des trucs du genre « le seigneur des anneaux: un mec plutôt pas très grand reçoit la visite d’un magicien, et se met en tête de jeter un anneau dans un volcan, récupérant quelques potes en chemin ». J’ai clairement pas commit une infraction au droit d’auteur. C’est un peu du même tonneau ici.

Ok pour les paroles, ça c’est clairement couvert et pas ambigu du tout. Miles Davis ne chante pas, donc j’avais pas de paroles sur celles que j’ai regardé :)

Le plan de missile est un plan très détaillé de la centrale, et le suivre te donnera exactement le meme missile.

Pour le jazz, c’est plutot différent. Les mecs ne jouent pas « un morceau ». Ils jouent leur inspiration du moment d’une progression d’accord. Le concept de composition devient plutôt flou quand la composition se limite à « une demi douzaine d’accords choisi parmi 2 douzaines, suivant les règles usuelles de gamme etc ».

Ça me parait beaucoup plus difficile de protéger quelque chose d’aussi abstrait et sujet à 99% à interprétation. A ce compte la, je peux protéger 100% des créations musicales a venir en générant toutes les variations raisonnablement écoutables de 12 mesures (y’en a pas tant que ça au final). Ce qui ne parait pas être l’esprit de la loi en la matière.

Bref, j’irais pas parier mon déjeuner dessus, mais quand je voit all blues, je suis pas convaincu qu’un juge enverra Jean Michel en prison pour contrefaçon.

Je suis pas avocat, et je sais pas lire une partition. Par contre, j’ai des oreilles, un peu de jugeote, et quelques albums de jazz.

Quand je voit sa partoche d’all blues, il a 12 mesures et la grille d’accords qui va avec. Le morceau de miles davis fait 11 minutes, et bon, c’est pas comme si le père miles jouait le même couplet/refrain en boucle pendant 11 minutes. Sa partition est clairement pas une transcription fidèle du morceau

Vu le milieu, je suis même pas convaincu qu’il y’ait une composition formelle à la base, sorti de « tant que ça colle à peu près sur la si do re mi, c’est toi qui voit comme tu le sens ». Même si je pense que t’as plutôt raison dans l’absolu, je suis pas convaincu que l’ayant droit puisse dire qu’il est interdit de poster ces 12 accords. Ça serait la partition complète du morceau tel qu’enregistre sur kind of blue, je dit pas, mais la je serais pas surpris si ça passe vu que tu peux vraiment pas faire grand chose avec cette partoche sans avoir beaucoup d’expérience à jouer du jazz.

Faut voir ça comme une opportunité, pas un problème. Ca donne une certaine latitude à l’implémentation.

Vu qu’il est grosso modo garantit d’être 7h00 dans une timezone dans moins d’une heure (peut être même 30 minutes!), il suffit d’exécuter la tâche un 31 juillet, à l’heure pile, et paf, ça reste correct!

Honnêtement, tu craques complètement la dessus.

Tous les pointeurs sont super doués! 💪

Je trouve que prendre tous ces gens qui ont largement contribué à la plateforme de haut en leur disant que leurs usages "bof OSEF lol" est un manque de respect total.

Il dit pas osef, lol. Il dit que des classes clairement annoncées comme ne faisant pas partie du standard avec 0 garanties de maintenance ne peuvent pas être utilisée comme exemple de cassage d’api/abi. Tout comme je peux pas dire “le c++ casse les apis parce que qt a pété pleins de trucs avec le passage à qt5”.

Idem pour les enums.

C’est ce que je me disais. Tout recompiler à chaque fois, ça resoud des problèmes, mais ça en introduit d’autres aussi. Et surtout, ça devient très compliqué pour ceux qui ne font pas l’open source.

Je veux bien croire que ça marche très bien pour le marché de go, mais ça n’en fait pas une solution universelle.

Non, python va compter le même nombre de méthodes que tu soit dans l’objet ou à l’extérieur.

C++ voit ici une taille d’objet différent en fonction de si tu es dans la lib ou au call site.

t’as des exemples concrets? Dans l’ensemble pour peter une abi en java, faut vraiment se lever tôt et faire des trucs très très bizarres. Le bytecode a un peu été conçu pour ça, et sun/oracle ont toujours refusé d’y toucher (ce qui donne des conneries genre un Integer boxé en int qui te pete une npe, parce que c’est juste du sucre syntaxique).

Oracle s’est même retrouvé bloqué après avoir spécifié leur algo de hash pour les hashmap, ce qui leur a causé des soucis avec des DoS à cause de collisions dans les requêtes http. ckyl avait expliqué en long en large et en travers le problème ici même. Ils tiennent la route avec leur api publique.

Les changement d’api/deprecation arrivent, mais dans l’ensemble, à moins d’aller taper dans les classes “privées”, ça continue à tourner. Après, oui, c’est facile de se tirer une balle dans la jambe et se peter une runtime exception avec des jars qui ne sont pas les bons, mais ça c’est plutôt un problème de gestion de dépendances touffu qu’un problème de compat abi/api.

Oui, c’est ce que j’impliquais par “tant que ça pete pas en vol non plus”. C’est juste que c’est long et chiant a expliquer, mais comme tu l’as fait, j’ai pas à le faire :)

Et sinon, rien à voir avec la choucroute, mais vendor, ca veut dire fournisseur, pas vendeur.

Si je peux changer ma représentation interne d'une classe, ne pas recompiler ceux qui utilisent cette classe et tout de même linker avec c'est qu'il n'y a pas de problème d'abi ?

Oui, tant que ça pete pas en vol non plus. Java est abi compatible aussi, un .class de 1993 tournera sans problème dans une appli écrite en 2022 en java 17 sans rien toucher.

Java (et actes associés donc kotlin aussi), swift/objc, c, .net aot ou jit, et un petit peu en c++ si tu plisses les yeux sont abi stable. Pas rust et go. Go essaye d’esquiver le problème en linkant tout en statique, mais je sais pas ce que ça donne en pratique pour la distribution de librairies?

Les languages de script ne sont pas distribués sous forme binaire, ce qui aide pas pour le b d’abi, donc le problème ne se pose pas pour eux.

Après pour ce qui est de l'ABI, est-ce vraiment une mauvaise chose que de vouloir éviter de casser l'existant ?

De mon expérience avec Swift (0 compat abi jusqu’à la version 4 ou 5), c’est très très très chiant. Ça veut dire que toutes tes dépendances doivent être rebuilt au grand minimum à chaque update du compilo. Et même avec ça, ça veut dire que toute l’équipe doit updated son compilo en même temps. Ce qui est compliqué sur un projet distribué. Ou alors tu passes ton temps à tout recompiler à chaque build, ce qui devient très vite chiant au quotidien, à plus forte raison en c++ vu les temps de builds. Ça a aussi vite fait de complexifier les builds CI et bouffer du temps pour pas grand chose. Surtout vu le merdier que sont les build tools en c++.

Dans le cas de Swift, l’effet c’est que très peu de projets sérieux se lançaient dans un framework en Swift. Une fois qu’Apple a déclaré l’abi stable, ça a ouvert les vannes.

On a beau aimer l’open source, le fait est que distribuer des binaires prebuilt est quand même plutôt pratique, au minimum, et obligatoire pour du code closed source, au pire. De ce que j’en voit, sortis de languages récents et relativement peu répandu, une abi stable est un peu la base de la base. Peter l’abi d’un coup me parait être un gros problème.

Les raisons de Google me paraissent plutôt justifiées. C++ était déjà un monstre de complexité y’a 20 ans. Ça n’a fait qu’empirer depuis. Vu leurs objectifs, ça me paraît raisonnable de faire ce qu’Apple à fait avec swift et objc: créer un language next gen de remplacement, en incorporant des ponts du nouveau vers l’ancien pour permettre une longue transition en douceur.

Je suis pas journaliste, donc à prendre avec des pincettes.

Mais se battre sur l’aspect quantitatif quand t’as en face google News ou Twitter, ça me parait être une bataille perdue d’avance si tu veux pas faire du putaclic. A plus forte raison quand ton public est assez prône à utiliser des bloqueurs de pubs.

Se concentrer sur ses abonnement et la qualité me parait pas forcément délirant.

Je suis resté calme. Et en l’occurrence, c’est parce que c’est pas sa première offense. Et 60% de ce qu’il dit n’a absolument aucun sens, et n’est explicable que par de la mauvaise foi crasse ou une méconnaissance abyssale des acteurs.

Le pire c’est qu’il a pas forcément tord sur les 40% qui reste. On parle d’un acteur qui a construit plus d’un milliard de téléphones, donc les jugements à l’emporte pièce, ca va quoi.

Et on peut pas vraiment dire qu’il ait prit un ton neutre/objectif en parlant de pomme non plus. Donc, oui, je maintiens mon qualificatif de clown et d’âneries (et je tire mon chapeau à pbpg au passage pour ceux qui ont remarqué la référence).

Je suis vraiment confus. Soit tu mens comme un arracheur de dents, soit t’es vraiment stupide. Surtout que c’est pas la première fois que je me prend la tête avec toi sur ce sujet.

Apple ont déjà, dans le passé, changé de connectique. Le fait que ça arrive à nouveau ne surprendra aucun utilisateur, ou alors seulement ceux qui ont la mémoire très courte.

Oui, ils l’ont déjà fait. La grosse différence est qu’Apple a vendu autant de téléphones cette année que ce qu’ils avaient vendu de téléphone en tout au moment de cette transition. Dit autrement, le parc existant fait pas loin d’un milliard de téléphone. Avec des cycles de renouvellement beaucoup plus long (le matos est arrivé à maturité depuis 2-3 ans), et avec un marché complètement saturé (a savoir, en 2012, une grosse part des ventes étaient le premier smartphone de l’acheteur, maintenant c’est du renouvellement). Si tu vois pas en quoi ça change complètement le problème, je sais vraiment pas quoi te dire.

Choisir Apple, ce n'est pas un choix de pérennité de la connectique

Avec plus d’un milliard de devices vendus, je pense qu’on peut dire sans trop s’avancer que Lightning ne va pas disparaître comme ça. Y’a des câbles de partout, des adaptateurs de partout. Les câbles officiels viennent en usb, et pour l’instant, apple est le seul constructeur de téléphone à avoir tenu plus de 10 ans sans changer de connectique. Donc tu repasseras.

tandis que l'intégralité des autres fabricants n'ont changé que pour passer à une connectique unique, la même pour tous, l'USB-C.

Ben voyons. La raison pour laquelle l’Europe bosse sur cette histoire depuis 2009, c’est précisément parce que les constructeurs de téléphone sortaient une nouvelle connectique par téléphone. Parfois du mini usb, parfois du micro usb. Si ce que tu dit c’est “les autres ont pas changé de connectique depuis la dernière fois qu’ils ont changé de connectique, forcément, on va pas être d’accord.

Racheter du matériel, ce n'est à l'évidence pas un problème pour les gens qui compte mettre un bras dans un téléphone Apple.

Ben voyons. Apple fait du milieu de gamme aussi. Un SE fait presque un tiers du prix d’un Samsung haut de gamme, et presque 30% de moins qu’un pixel 6a. Apple occupe les meme segments de marché que les autres gros constructeurs android.