barmic 🦦 a écrit 5823 commentaires

Et comme on en parlait c'est tout à fait possible c'est juste que tu dois exprimer dans ton code cette sémantique. Tu disqualifie un peu vite les choses comme indécidables. Il est tout à fait possible d'écrire un programme qui vérifie qu'aucun dénominateur est égale à 0. Si vraiment tu as besoin de t'en convaincre c'est le même problème que vérifier la nullité des références ou pointeurs.

Du coup le théorème de Rice ne s'applique pas.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

À noter d'ailleurs que scp est en cours de déprécation au profit de sftp (la commande scp elle est entrain de migrer vers sftp).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pourquoi la division par zéro serait plus un bug que la division par 42 ?

Parce qu'elle n'a pas de sens mathématiques. De la même manière que tu n'adresse pas un tableau avec des nombres imaginaires. Le Not A Number n'est qu'une représentation d'une erreur. Tu peux faire des choses avec comme avec une erreur ça n'en est pas moins une erreur.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour le titre, s'il ne voulait pas comparer les langages entre-eux à la base, il aurait du choisir un truc du genre : "Performance comparison in counting words, study cases in various languages.", sinon c'est ce qu'on appelle un titre putaclick.

Qu'il soit possible de trouver un titre qui préserve mieux ta sensibilité n'indique pas que ce titre est putaclick.

Quand à la conclusion, la moitié est consacrée au tableau de comparaison entre langages, et ensuite viennent quelques pensées qu'il en tire, avec en premier : "I think it’s the simple, idiomatic versions that are the most telling. This is the code programmers are likely to write in real life.", alors que j'ai prouvé ci-dessus que ce n'est pas le cas, les developpeurs ne ponderont pas tous le même code dans la vie réelle, il existera des versions différentes avec des performances elles aussi bien différentes.

Je ne suis pas d'accord. Oui il y a des façons différentes pour autant peu vont réellement diverger (sur un sujet aussi simple) et la version idiomatique va logiquement être la solution la plus fréquemment utilisée. Le fait que tu ai montré qu'il y a d'autres façons de faire n'invalide pas cela.

Plus de la moitié du billet montre comment on mesure la performance dans chacun des langages et comment les choix fait impactes ses métriques, il n'y a aucun endroit où il parle de la performance comparer des langages. Ce n'est pas un point de vu.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ce que tu dis revient juste à étendre la sémantique de la division pour donner un comportement différent à la division par zéro. Au lieu d'un crash, on aurait une valeur particulière, c'est-à-dire grosso-modo la solution numéro 2, sauf qu'en version explicite (écriture explicite de la condition) et potentiellement plus flexible (genre retourner autre chose que zéro si le dénominateur est nul, mais je vois pas trop à quoi ça servirait).

Pas forcément, là c'était des exemples, mais ça peut être pour afficher des messages d'erreur par exemple. Il n'est pas question la division devienne une fonction totale, mais que tes fonctions qui utilisent la division soient totales. Ça peut d'ailleurs s'implémenter aussi si on considère que la division ne renvoie pas un nombre, mais un type double|NaN qu'il faudra traiter.

Enlever ces vérifications est un problème indécidable en général et je ne pense pas qu'il y ait d'heuristique efficace pour cela dans un compilateur actuel.

Je pense qu'il fera très bien ce que tu lui demande c'est à dire produire un code proche de l'optimal avec les sécurité que tu lui demande. C'est juste que ça peut demander de ne pas laisser le CPU faire un calcul de bout en bout sans vérification intermédiaire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je veux bien entendre tes arguments, mais quand le titre est "Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust", le but du jeu est clairement de comparer les perfomances entre ces langages, ce n'est pas "tiens, vu qu'on a déjà fait le truc dans plusieurs langages, on pourrait aussi les comparer tant qu'on y est".
L'optimisation, le profilage, c'est visiblement plus un bonus que le but du jeu.

Ce n'est pas du tout comme ça que je lis le titre ni le billet. Il ne parle pas de comparer la performance entre les langages mais dans chaque langage. Et s'il produit une liste multi langage il montre pour chacun le gain entre idiomatique et optimisé.

Il suffit de regarder la conclusion pour s'en convaincre. Il parle même de quel langage est le plus performant, mais du fait que C++ donne des messages d'erreur affreux, qu'en C ça vaut le coût d'utiliser une bibliothèque pour ça et que python et awk sont les plus rapide (pour la partie écriture du code et pas pour la partie exécution).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La première solution est impossible dans un langage généraliste, car dans ces langages, c'est un problème indécidable.

Si c'est possible, c'est juste que le compilateur t'interdit une division s'il ne peut pas s'assurer que le dénominateur n'est pas 0.

Donc

a = b / c

ne compile pas dans le cas général, il faut écrire des trucs du genre :

a = c != 0 ? b / c : 0

Et oui ça peux devenir relou dans tu as un truc du genre :

Ça t'oblige à déstructurer ton calcul et si le langage et le compilateur sont pas au poil tu peut perdre en performance (il faut qu'il puisse virer les vérification à la compilation pour reconstruire l'opération).

Sachant que de base tout ce qui va cacher pour toi (en attrapant l'interruption ou en faisant la vérification pour toi) va consommer de la ressource.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Bravo pour le jeu :)

Autre amélioration : depuis une échelle, si on est pas exactement au bon niveau on a pas le droit de descendre. Souvent les jeux acceptent ce genre d'imperfection (c'est ce que l'on appelle les coreloops).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les nouveautés de 2004 ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Super pratique quand tu as besoin d'avoir un comportement spécifique par type plutôt que de mettre des if moches.

Je suis pas sûr que ce soit bien sans sealed class ce qui est entrain d'arriver dans java.

Mais je suis d'accord que le type erasure pose problème par exemple si on veut construire un objet de la classe du type effectif de ta méthode. C'est pour ça que l'on passe la classe à ce genre de méthode :

A a = build(A.class);

Par contre, c'est pas mal mitigé avec l'utilisation de lambda (pas dans tous les cas, mais dans une partie).

Mais oui C# qui a implémenté les génériques un an après java est mieux sur ce point là. Je pense que c'est dû au fait qu'ils ont implémenté la généricité dans la vm là où sun se l'ai interdit (probablement pour ne pas casser l'écosystème des jvms qui était foisonnant à l'époque).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu es trop troll est cryptique pour être compris par la populasse. Tu reproche à go d'avoir des Panic et tu voudrait que ce soit comme les Exceptions de java hors ça n'a rien à voir. Les Panic correspondent plus aux Errors de java. Je me doute qu'avec ta comprehenssion des langages il n'y a pas besoin de t'expliquer plus pourquoi tu ne catch pas d'Error en java.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ce qui est le cas de bon nombre d'exception en java. Tu n'es pas sensé catcher Throwable, Error, Exception ou RuntimeException (les 2 premiers sont à proscrire, les 2 suivants il faudrait être plus spécifique).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Alors git ne permet pas les dépôts sans branche et je ne serais pas surpris que ça soit pour une raison assez profonde (donc assez couteuse à mettre en place).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça aurait gueulé de la même façon pour les même raisons.

Si tu regarde rien que dans les commentaires ici, tu as très peu de reproche au fait d'utiliser main comme nom par défaut. Les gens reproches qu'il y ai un changement pour des raisons qui ne leur conviennent pas. Que tu change d'une façon ou d'une autre ils auraient eu les même raisons et auraient dû avoir les même comportements (c'est à dire configuré leur github/gitlab pour remettre master).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'était bien mon point initial.

Ce que j'ai repris depuis le début c'est le fait d'associer cela à un groupe de SJW et surtout d'invalider cela par le fait que ce serait un petit groupe non concerné qui serait à l'origine de ça.

Il y a bien une pression sociale[…]

Il y a une énorme différence entre dire « c'est la faute des SJW » un petit groupe qui manigancerait (la définition même du complot) et c'est la pression social, aujourd'hui ça n'est plus socialement accepté. Je crois pas que quelqu'un puisse dire le contraire pour cette seconde assertion.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Bien sûr qu'il y a des discussions, tu n'a jamais travailler en groupe ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est toi qui affirme sans argument des raisons, moi je dis simplement que ce que tu dis ne tiens pas debout.

Je ne suis pas quelqu'un de particulièrement intéressé par ces sujets. Je ne sais pas si c'est oppressif ou pas, mais je ne vois pas comment ne pas donner de crédit à tant de projets différents.

Je ne connais pas tous les processus de décision, mais je lis les annonces et je n'ai vu personne parler de ce dont tu parle. Il n'y a que des gens extérieurs aux projets qui poussent des cris d'orfraie.

Je ne connais pas toutes les raisons des décisions, mais ça ne fais pas de tes élucubrations quelque chose de possible, pas tant que ça ne peux pas être rattaché à quelque chose de tangible.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Toujours pas le moindre argument. Si ça te pose un souci, il est possible d'en discuter directement avec les projets concernés à moins que tu ne crois en une omerta ?

Bref tu invente un monde avec quelques bouts de ficelles et tu fais ton possible pour ne pas le confronter aux faits (il existe des sjw donc tout ce qui ne me convient pas vient d'eux…).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu avance bien des choses. L'IETF par exemple, son fonctionnement rend peu probable ce genre de pression, sinon ils aurait corrigé une précédente RFC. Pour qu'un groupe de travail se mette en place qu'il ponde un document qu'il soit soumis à commentaires puis accepté, il va commencer à falloir beaucoup de travail.

Tu présente une logique complotiste avec comme la plus part ces théories pas le moindre début d'arguments. Tous le monde est entrain de tomber aux mains des SJW et ils font ça en mettant des coups de pression invisibles à des projets communautaires (ou alors tu pense que l'IETF et la LKML se soumet à 3 gus sur twitter ?).

Évidemment ce n'est pas en te présentant des faits que tu va changer d'avis, mais si les gens qui nous lisent peuvent, eux, comprendre que, qu'ils le ressentent ou non c'est une question qui fait son bonhomme de chemin depuis plusieurs années dans divers groupes éparpillés dans le monde et n'ayant pas de lien particulier entre eux.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le problème, c'est d'accorder de l'importance a des SJW qui se sentent offusques par tout et n'importe quoi.

Le problème c'est de surréagir à une info sans prendre de recul ni s'intéresser à d'où ça vient. Les gens ici régissent à l'annonce sans prendre en compte que ça s'inscrit dans un mouvement qui est bien plus large.

Penser que l'entreprise gitlab, l'entreprise github, les développeurs de git, les développeurs de jenkins, les développeurs de python, Linus Torvalds, l'IETF, mais aussi des papiers de recherche,… sont des SJW c'est soit ne pas connaitre ces gens, soit ne pas savoir ce qu'est un SJW :)

Tu as le droit de croire que ce sont tous des idiots, mais quand on affirme quelque chose comme ça il faut avoir des arguments sérieux.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

De l'autre coté, pour les warnings TRES nombreux (je pense en particulier au signed/unsigned mismatch), le soucis c'est qu'il sont à 99,99% inoffensifs, et que si je les coupe, je risque de rater LE vrai positif le jour ou je bosse sur un fichier spécifique et que du coup, en ne compilant que lui, je m'attarde un peu sur les warnings que j'ai.

Ce qui marche bien pour ça, c'est d'avoir des outils comme sonar qui vont permettre de définir une "gate", c'est à dire un ensemble de propriétés que doit remplir ton code (pas de warning sur le nouveau code, un certains niveau de test, un certain nombre de revues,…).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ai dû mal à retrouver le lien, mais il me semble que php avait eu un problème du genre. Ils ont corrigé un bug 2 fois alors que ça réintroduction avait levé un warning et ce serait à la suite de ça qu'ils auraient fait un effort pour supprimer tous les warnings.

Et là, je retombe dans les travers de discussions avec des collègues qui me donnent envie de m'arracher leur arracher les cheveux, à savoir, éliminer les warning OUI, c'est IMPORTANT et pas que pour le style, la beauté du geste et du code, car quand on en a 469356 (valeur non contractuelle) pendant la compilation complète du logiciel, on rate ceux qui sont vraiment important et cachent de vrais bugs.

Il faut retirer ceux qui ne sont pas considérés comme important. C'est généralement configurable.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu entends plus les gens qui crient ?

Sur un marché, tu entends plus le marchand de poisson qui crie, ou celui qui se contente d'attendre?
C'était ça, l'image.

Et mon commentaire cherche à te faire comprendre que le fait que tu entends beaucoup de crie ne permet pas de déduire :

on y crie plus qu'autre chose

N'est pas cohérent.

Que j'utilise au minimum, nuance.

Et tu peux aller changer le nom par défaut de tes branches. Ça a l'air vraiment horrible comme changement…

Je suis loin d'être horripilé.

Tu fais des références nazis tout de même.

Je m'amuse notamment dans le message auquel tu réponds du fait que, la personne qui semble avoir introduit le terme "master" à un nom qui m'évoque plutôt l'europe de l'est, que le far west, tout en lisant que le changement est fait pour résorber un problème typiquement nord-américain.

Le projet git a mis en place la possibilité de ce changement à la suite du Black Lives Matter, github et gitlab exposent cette nouvelle configuration aux utilisateurs et en profitent pour changer la valeur par défaut. Il ne s'agit pas d'un gars dans son coin qui a fait un changement.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ce dernier changement fait sans doute plus d'écho car trouvé ridicule par bon nombre d'individu

Ça va plus loin que ça quand on parle de 1984, de novlang, etc.

une grande avancée sociale de la catégorie congé payé par les autres

Je n'ai pas vu ce genre de réaction, tu as un lien ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

En fait le problème avec ce renommage, c'est qu'il se base sur des problèmes intrinsèquement locaux aux USA mais touche tout le monde.

Mais ce sont des services américains. Il est logique qu'ils soient teinté par leur culture.

Tu remarquera que le logiciel phare du quel ils dépendent va aussi dans ce sens. Il est probablement principalement développé par des américains, mais dans tout les cas ils sont arrivé à ce point d'entente.

Mon code n'est pas organisé par des trucs comme github ou gitlab: ces machins ne sont que de stupides outils, que j'évite d'ailleurs au maximum tant je trouve coûteux en temps le fait d'utiliser ces «forges», qui sont en réalité bien plus proches de «places du marché» tellement on y cause et on y crie plus qu'autre chose.

C'est un énorme biais. Tu entends plus les gens qui crient ? Comme c'est étonnant. Si ne serait-ce que 20% des utilisateurs de github "criaient", on s'en rendrait compte.

Mais du coup des plateformes que tu n'utilisent pas changent la configuration par défaut d'un nom de branche et ça a l'air de t'horripiler ? C'est pas un "chouia" une surréaction ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll