Je pense que pour un jeu de poker qui ne cherche pas à gérer de l'argent, on s'en fout un peu de l'algorithme de mélange
Il est évident que dans ce contexte précis, en effet, on s'en fout pas mal. Mais c'est du code libre ; il peut être réutilisé par les distributions, éventuellement inclus dans des CD de jeux libres, et réutilisé dans des contextes différents, y compris peut-être des cas où il y a un enjeu un peu plus important. Évidemment, on peut toujours dire qu'il faut relire le code en fonction de l'enjeu, mais c'est un argument foireux : on ne relit pas le code de libreoffice même quand on calcule ses impôts dans le tableur, parce qu'on fait quand même confiance au gars qui l'a programmé.
D'une manière générale, bricoler un algo à la va-vite, on l'a tous fait. La réinvention de la roue est un processus très important dans l'apprentissage de la programmation, et je ne pense pas qu'on puisse devenir un bon programmeur sans avoir réécrit dans l'ignorance la plus totale des algos naïfs de tri, d'échantillonnage, etc. Mais ça, c'est l'étape n°1. On ne va pas rester toute sa vie avec son algo de tri en O(n2). La partie intéressante commence quand on étudie les "vrais" algorithmes, quand on comprend leur logique, et quand on les réimplémente. On s'aperçoit de ses progrès quand on relit son vieux code et qu'on voit à quel point on était mauvais et naïf 10 ans avant. Et ça ne s'arrête jamais, on doit chercher à progresser toute sa vie.
Du coup, je pense qu'il n'y a aucune honte à avoir sur du code pourri. Évidemment, on peut se moquer gentiment des gens qui réintentent tout tous seuls, surtout quand il existe du pseudo-code partout : c'est une forme de naïveté de ne pas imaginer que d'autres avant ont pu rencontrer le même problème et consacrer du temps à le résoudre. Par contre, je pense que c'est une erreur de ne pas vouloir apprendre, et d'avoir une position arrogante face aux critiques. Ici, non seulement l'implémentation est pourrie, mais en plus elle est est bugguée (les cartes ne sont pas mélangées correctement). Quand on pond 200 lignes de code pour faire quelque chose qui devrait tenir en 3 lignes, et qu'en plus ça fait n'importe quoi, on a quand même de la marge de progression.
Sans blague, je ne pense pas que Linuxator sache ce que "for (cc=0 ; cc < get_rand(32) ; cc++ )" fait. Si c'est volontaire, il manque un commentaire sur la loi sous-jacente (binomiale négative?). En tout cas, il existe une différence entre "mélanger les cartes" et "faire n'importe quoi avec le paquet", même si le résultat final pourrait ne pas être totalement différent...
[^] # Re: Mélange des cartes
Posté par arnaudus . En réponse au message Jeu de poker pour Linux.. Évalué à 3.
Il est évident que dans ce contexte précis, en effet, on s'en fout pas mal. Mais c'est du code libre ; il peut être réutilisé par les distributions, éventuellement inclus dans des CD de jeux libres, et réutilisé dans des contextes différents, y compris peut-être des cas où il y a un enjeu un peu plus important. Évidemment, on peut toujours dire qu'il faut relire le code en fonction de l'enjeu, mais c'est un argument foireux : on ne relit pas le code de libreoffice même quand on calcule ses impôts dans le tableur, parce qu'on fait quand même confiance au gars qui l'a programmé.
D'une manière générale, bricoler un algo à la va-vite, on l'a tous fait. La réinvention de la roue est un processus très important dans l'apprentissage de la programmation, et je ne pense pas qu'on puisse devenir un bon programmeur sans avoir réécrit dans l'ignorance la plus totale des algos naïfs de tri, d'échantillonnage, etc. Mais ça, c'est l'étape n°1. On ne va pas rester toute sa vie avec son algo de tri en O(n2). La partie intéressante commence quand on étudie les "vrais" algorithmes, quand on comprend leur logique, et quand on les réimplémente. On s'aperçoit de ses progrès quand on relit son vieux code et qu'on voit à quel point on était mauvais et naïf 10 ans avant. Et ça ne s'arrête jamais, on doit chercher à progresser toute sa vie.
Du coup, je pense qu'il n'y a aucune honte à avoir sur du code pourri. Évidemment, on peut se moquer gentiment des gens qui réintentent tout tous seuls, surtout quand il existe du pseudo-code partout : c'est une forme de naïveté de ne pas imaginer que d'autres avant ont pu rencontrer le même problème et consacrer du temps à le résoudre. Par contre, je pense que c'est une erreur de ne pas vouloir apprendre, et d'avoir une position arrogante face aux critiques. Ici, non seulement l'implémentation est pourrie, mais en plus elle est est bugguée (les cartes ne sont pas mélangées correctement). Quand on pond 200 lignes de code pour faire quelque chose qui devrait tenir en 3 lignes, et qu'en plus ça fait n'importe quoi, on a quand même de la marge de progression.
Sans blague, je ne pense pas que Linuxator sache ce que "for (cc=0 ; cc < get_rand(32) ; cc++ )" fait. Si c'est volontaire, il manque un commentaire sur la loi sous-jacente (binomiale négative?). En tout cas, il existe une différence entre "mélanger les cartes" et "faire n'importe quoi avec le paquet", même si le résultat final pourrait ne pas être totalement différent...