En vrais coder sur papier, ça, c'est fait pendant longtemps.
Ça peu encore se faire dalleur : https://www.youtube.com/watch?v=2XLZ4Z8LpEE
(Vidéo d'une personne qui fait marcher un typewritter des années 30 sur un GNU/linux moderne).
Il faut juste conclure le débat Vim vs Emacs, par ed.
Par contre, j'ai un doute sur l'intérêt écologique de la chose comparé à un écran, mais si Nadia le dit ¯\_(ツ)_/¯ .
Ouin-ouin, les machins, ils sont méchants.
Et vu que les machins, on dit être un peu bidules, tout ce qui ressemble aux bidules de prés ou de loin, sont comme les machins, et sont méchants.
Et donc je vais promenoir les truck raciste, car ils s'opposent aux machins et aux bidules (enfin, il ne faut pas trop regarder dans les détails non plus), et ils sont donc forcément gentils.
L'autre solution, c'est avec des longjmp/setjmp: http://groups.di.unipi.it/~nids/docs/longjump_try_trow_catch.html
Par contre, c'est lent, et une énorme source du bug.
En fait ce sont surement les fonctions les plus dangereuses de C, et c'est presque tout le temps une mauvaise idée de les utiliser.
Comparer aux exceptions C++, un longjmp ne va pas appelle les free fait entre le setjmp et le longjmp, de plus laisse ton programme dans un état qui est beaucoup plus dur à contrôler, qui si le flow du programme est linaire.
Dalleur, que ça soit le mécanisme de defer ou __attribute__(cleanup) le comportement est indéfini, si un longjmp est fait après le defer/cleanup.
Ceci dit il me semble que kantien parle de remplacer les goto, par des try/catch.
Les extensions dont tu parles servent à faire soit un genre de RAII, soie des defer.
Le seul compilateur C qui gère try/catch, c'est MSVC.
Personnellement, j'aime beaucoup les mécanismes de defer, et autres, car ça permet de gérer la libération des ressources, au moment où on les crée, et donc moins de chances d'oublier.
Le problème des goto out; c'est qu'on a le label out à la fin de la fonction, et c'est facile d'oublier de rajouter le free.
Avec les try/catch, le problème reste assez similaire aux goto.
C'est moi qui avais push la 1ʳᵉ version de attribute cleanup dans tinycc, (qui était pas mal bugué, les mainteneurs ont quand même pas mal amélioré mon code). Je n'aurais clairement pas fait le même effort pour imiter les try/catch de MSVC.
En C, t'a une erreur aussi (Vu que 1.0 est un double, il va dans le type default, donc cmpPtr)
#include<stdio.h>#define cmp(a, b) _Generic(b, int : cmpInt, float: cmpFloat, default: cmpPtr)(a,b)intcmpPtr(void*a,void*b){returna==b;}intcmpInt(inta,intb){returna==b;}intcmpFloat(floata,floatb){returna==b;}intmain(){printf("Hello, World! %d\n",cmp(1,1.0));}
Main.c: In function ‘main’:
Main.c:10:38: warning: passing argument 1 of ‘cmpPtr’ makes pointer from integer without a cast [-Wint-conversion]
10 | printf("Hello, World! %d\n", cmp(1,1.0));
| ^
| |
| int
Main.c:3:79: note: in definition of macro ‘cmp’
3 | #define cmp(a, b) _Generic(b, int : cmpInt, float: cmpFloat, default: cmpPtr)(a,b)
| ^
Main.c:5:18: note: expected ‘void *’ but argument is of type ‘int’
5 | int cmpPtr(void *a, void*b) {return a == b;}
| ~~~~~~^
Main.c:10:40: error: incompatible type for argument 2 of ‘cmpPtr’
10 | printf("Hello, World! %d\n", cmp(1,1.0));
| ^~~
| |
| double
Main.c:3:81: note: in definition of macro ‘cmp’
3 | #define cmp(a, b) _Generic(b, int : cmpInt, float: cmpFloat, default: cmpPtr)(a,b)
| ^
Main.c:5:26: note: expected ‘void *’ but argument is of type ‘double’
5 | int cmpPtr(void *a, void*b) {return a == b;}
| ~~~~~^
Si tu enlèves le default t'a aussi une erreur :
Main.c: In function ‘main’:
Main.c:10:40: error: ‘_Generic’ selector of type ‘double’ is not compatible with any association
10 | printf("Hello, World! %d\n", cmp(1,1.0));
| ^~~
Main.c:3:28: note: in definition of macro ‘cmp’
3 | #define cmp(a, b) _Generic(b, int : cmpInt, float: cmpFloat)(a,b)
|
Ce que fait cmp, c'est juste appeler une fonction qui dépend du type de b (doc ici: https://www.iso-9899.info/n1570.html#6.5.1.1).
Après si l'appelle de fonction déroulée pas la macro n'est pas bon, le compilateur va le remarquer.
Dalleur utiliser default n'est généralement pas une super idée.
si tu veux faire la même chose avec des macros en C++, ça va peu être plus compliqué.
Cette remarque n'était pas pour dire que _Generic > template, mais que si tu essayes de reproduire le comportement des template C++ en macro C++, ça va effectivement être compliqué, et hasardeux.
Bon les destructeurs, je suis d'accord que ça manque au C,
Mais gnu C, implémente une extension __atribute__((cleanup())), qui est implémenté par gcc, clang, tinycc, intel compiler, et est utilisé dans flatpak, systemd, et libvirt pour ne citer que quelques exemples.
les templates qui offrent une bonne sécurité et de bonne capacité de spécialisation en fonction des types; pour faire la même chose avec des macros, faut relire 10 fois avant de s'assurer qu'on a bien fait taff.
#define cmp(a, b) _Generic(b, int : cmpInt, float: cmpFloat, default: cmpPtr)(a,b)
Tu te relis beaucoup de fois pour un truck qui se fait en une ligne de code, et est assez explicite, je trouve.
Bon ok, c'est du C11, et si tu veux faire la même chose avec des macros en C++, ça va peu être plus compliqué.
La vidéo ne parle ni des avantages de rust par raport a C, ni de l'algo utilisé pour le scheduler en rust.
Si l'algo utiliser n'est pas le même, l'ordonnanceur aurait pu être codé en js, avec ça VM dans le kernel qui exécute le code JS, et quand méme avoir un gain de performances.
Les bons commentaires font partie du code. Les deux évoluent ensemble…
Oui, et mon point, c'est de dire que c'est plus dur d'écrire un commentaire qui ne contient pas d'erreur qu'un code qui ne contient pas d'erreur.
Car le code est beaucoup plus testé.
Le code et les commentaires évoluent ensemble, mais les commentaires ont plus de chances de mal évoluer.
J'avoue avoir déjà fait ce genre de commentaire, et ça rend assez propre.
Par contre, j'ai aussi déjà fait ce genre de commentaire, dans des fonctions que j'ai beaucoup modifiées après, et forcément, j'ai oublié de modifier les commentaires, et me suis retrouvé avec des commentaires type "/* initialize Video */", alors que le code dessous n'initialise pas du tout la Vidéo, qui a été bougé 20 lignes en dessous.
Ce qui est complètement crétin, évidemment, c'est de ne pas documenter son code. Ce n'est pas du temps perdu mais un investissement parce que, quand on se retrouve dessus après un certain temps, on perd moins de temps à comprendre ce qu'on a fait.
Je peux comprendre l'attrait de commenter son code, le problème, c'est qu'on a très peu d'outils pour aider à trouver des commentaires faux.
Si on oublie de free une variable, on a plein d'outils pour aider à trouver qu'on a oublié de free cette variable, si on fait un if (variable) à la place d'un if (not variable), on a des tests et un programme qui bugue, ce qui peut nous aider à trouver qu'on a oublié la négation.
La plupart des gros projets ont tous un tas d'outils pour trouver des bugs, et de la revue de code, et pourtant ont toujours plein de bugs.
Les commentaires, eux, n'ont pratiquement rien (juste la revue de code). Ce qui fait que les commentaires, qui eux sont très peu analysés, sont généralement la partie du code qui contient le plus de bug par ligne de commentaire. (par bug, j'entends commentaire qui ne dit pas ce que devrait faire le code)
Et si un commentaire est erroné, aucun outils ou tests ne va te dire qu'il est faux.
Et quand t'a déjà passé une demi-journée à te faire toute la Documentation d'une bibliothèque, car un commentaire te dit d'absolument appelle une autre fonction avant d'appeler celle dont tu as besoins, pour au final en lisant le code de la bibliothèque te rendre compte que le commentaire aurait juste dû être supprimé, car il concernait une ancienne version de la bibliothèque.
Bah, tu regardes les commentaires d'un autre œil.
Je ne dis pas qu'il ne faut pas commenter son code, mais c'est très facile d'oublier une négation dans une phrase, ou de changer la logique d'un code, et laisser les anciens commentaires qui explique l'ancienne logique.
C'est pour ça que les commentaires ne devrait être utilisé que pour dire ce que ne dit pas le code, ou faire de la Documentation utilisateur.
Et si un code à besoins d'être commenté, peut-être que c'est le code qui est trop compliqué et devrait être changé pour peu être avoir un code plus simple, voir qu'y s'auto-documente.
Mais étant un développeur standard, et ayant fait des math, on m'a appris à ne pas fuir, les dérivés.
Hors étant dyslexique, je lis, en la dérive ambiante, des ivres d'ambiance.
Alors étant quelqu'un de cultivé, l'ivresse me fait penser à Gin des boulots étrange. (Du manga Gintama(銀魂)).
Vu que le dernier épisode de Gintama que j'ai vu parlait de Wizardry, il me semble logique, et dans le sujet de ce thread, de parler de cette saga de RPGs, qui si on y regarde à tout l'air d'être une vielle saga de Dungeon Crawler classique, et sans peu d'intérêt,
Quand on y joue, on se rend compte que c'est belle et bien un Dungeon Crawler très classique avec assez peu d'intérêt aujourd'hui, et contient tout ce qui peut être énervant dans un vieux RPG : piège invisible, histoire très banale, mort à tous les recoins, et qui souvent paraissent injustifiés. (sans parler du manque de tuto pour bien commencer le jeu).
Et si le jeu est l'un des premiers Dungeon Crawler, la concurrence de l'époque était rude, c'est dure de voir l'influence qu'à eux ce jeu sur les JDR qui on suivit, et au final, cette saga, c'est plutôt fait oublier à côté des ultimas, Elder Scroll ou la Saga de SF inspirée de Star Trek : Might and Magic. (bon en vrais, je parle sans trop connaitre, des gents expliquent que Wizardry à inspiré tous les jeux récents)
Mais si on regarde le jeu d'un autre angle, c'est en fait l'un des ダンジョンアドベンチャー(Dungeon Crawler en japonais) les plus influant qui a existé.
Car si en Europe, et aux US, on ne se rappelle pas tant de Wizardry, le jeu à était un carton au Japon, tellement qu'aujourd'hui la plupart des Wizardry récent, sont développés par des Japonais.
La série a servi d'influences à une flopée de JRPG, et même Dragon Quest n'aurait surement pas vu le jour sans Wizardry. (qui est le JRPG qui a influencé tous les JRPG)
Vu que généralement les Jeux de chez nous ne marchent pas beaucoup au Japon, et les RPG occidentaux y sont très peu connus, je trouve ça étonnant de voir à quel point ce jeu à influencer les jeux japonais.
Dalleur, si on retrouve autant de wizardry dans un Dragon Quest 1 que dans un Elder Scroll Arena, c'est rigollot, de voir à quels points les Jeux japonais et américain, on prit des directions différentes en s'inspirant du même jeu.
Par contre, niveaux ré-implémentation Libre, je n'ai pas trouvé grandes choses : Celui-là qui n'a pas l'air finit, et abandonné, mais a la particularité assez rare, que sur la fin le dev voulait porter le code de C++ a C.
et celui-là qui a l'air d'être. Encore développée et a un beau Readme.
Mais au final, si Wizardry m'a appris une chose à travers ces Dungeon trop long, ces couloirs interminables et coupe-gorges à chaque pas, c'est qu'il ne faut pas se fier aux apparences, que l'ont peu trouvé le beau dans ce qui semble pourtant si banal, et un cus de sac peu en fait étre un téléporteur vers les plus beaux trésort, donc s'arrêter à un discours de RMS qui semble trop ambiguë pour juger le personnage est une erreur. et une preuve flagrante d'inculture. (aussi flagrant que pour faire un pavé aussi long sur Wizardry, le mettre en commentaire était une bien meilleure idée qu'un journal)
Ceci dit, RMS, est assez strict dans ça manière d'utiliser des ordinateurs, à ne s'autoriser aucun logiciel proprio.
Alors que GPL c'est juste une licence qui peu même être utilisé en dual-licence avec une autre propriétaire.
Si on me dit, il faut plus de RMS, j'entends, il faut plus de gents qui ne font aucune concession quand on parle du libre.
Si on me dit, il faut plus de GPL, j'entends qu'il faut plus utiliser la GPL, mais ça ne dit rien sur les bibliothèques utilisées, ou sur les doubles licences.
Genre faire des jeux en GPL qui utilisent Unity rentre dans l'idée de "il faut plus de GPL", mais pas "il faut plus de RMS" quand on se base sur ça.
Et il me semble que quand on écoute une personne qui développe des idées, ont peu en adapter certaines et rejette d'autres.
Si quelqu'un écrits un blog "il faut plus de Proudhon", et parle d'autogestion, je ne vais pas associer les idées du blogueur aux idées sexistes et antisémite de Proudhon. (surtout si dans le même poste la personne dit ne parler de Proudhon que pour ce qu'il a écrit sur l'autogestion)
Ceci dit, on a encore pas mal de programme, comme curl ou wine, qui sont en C89 pour être le plus portable possible.
Après pour Hare, bah, je trouve que comparer à un GNU C, qui a ces defer, bah la seule chose qu'il apporte, c'est sa gestion d'erreur, et les modules.
Et comparer à C, je n'ai pas l'impression qu'on ait de _Generic, ou de macro, ce qui a l'air d'en faire un langage moins puissant que GNU C11.
Comparer à un C11 sans GNU, on échange les macro et générique, pour du defer, et des modules, ce qui n'est pas forcément si rentable.
doas se veut vraiment minimaliste, et n'a que peu d'options de sudo.
Ça se limite à autoriser des user/groups à se lancer en tant que root. ou à autoriser/dénier certaines commandes.
Il y a 2/3 options telles qu'autoriser de ne pas mettre de mot de passe, ou ne pas redemander doas à chaque fois.
Là conf n'est pas compatible avec sudo, et ressemble à ça
Mais de mémoire sudo permet de configurer les timeout, et a plein d'autres options caché que je ne connais pas.
Mais oui sudo-rs supporte surement déjà plus d'option que doas, surtout qu'il se veut un "drop-in" remplacement.
doas c'est l'implémentation de openbsd de sudo en C.
Elle se différencie de sudo sur le fait que doas support moins de fonctionnalités que sudo.
Par contre, avec le minimalisme et le focus sur la sécurité de openbsd, si je dois prendre une implémentation safe, j'irai plus vers doas qu'un sudo-rs qui, malgré une implémentation dans un langage safe, a une base de code beaucoup plus grosse à maintenir et donc plus de chances de faille de sécu.
Bien sûr, il ne faut pas avoir besoins des fonctionnalités supplémentaires de sudo, et l'option pour se faire insulter manque à doas.
Oui, c'était de l'humour, mais j'avoie ne pas avoir fait trop d'effort pour expliciter mon 2nd degré, donc je comprends les moinssage et le message 1er degré pour expliquer mon erreur.
Ouais, j'aurais dû partir sur TLD, et pas sur TLD.
Mais je me suis limité à la page anglaise, et y'avais pas de lien vers TLD.
Après, je suis partie à chercher dans les CPUs instruction set, si il n'y a pas d'instructions qui s'appellent TLD.
Mais ça a pas l'air d'être utilisé.
Ah, ouais, ça parle de Tracking Level Detections
Mais ce n'est qu'une petite partie des capacités de l'I/O de l'ordinateur, fait dans un domaine ultra-spécialisé, ça ne rend pas tout l'I/O harmful.
Note:
Je ne viens pas de passer 10mn à chercher tous les acronymes de TLD pour creuser mon moinssage.
Normalement, c'est plus facile en crée des quiproquo débile, vu le nombre d'acronymes utilisé en informatique, des fois dans des domaines pas très éloigné.
Genre parler de comment KVM("keyboard, video, and mouse"), gère la VM(Virtual Machine) d'une VM(Virtual mémory).
Dalleur KVM ça peu aussi vouloir dire Kernel-based Virtual Machine.
Just the same, Asahi Linux has declared that people who do not actively support a specific sexual kink cannot be allowed in their project.
?
Parce que les problèmes avec cette phrase, c'est :
0 : Elle prend les propos du "lead d'Ashahi linux" sur son compte perso, et les fait passer pour la "position officielle du projet". (ça s'appelle un sophisme par association)
1 : Elle change son sens de "si vous étes anty-trans, vous pouvez GTFO", à "si vous êtes anty-trans, vous n'avez pas le droit de contribuer". (ça s'appelle un homme de paille)
3 : elle résume la transidentité à un kink, ce que ça n'est pas, mais est une manière de dénigrer les trans. (autre homme de paille, je suppose ?)
Et le truck, c'est que pour faire une phrase aussi chargé en sophisme au 1er degrée, on à généralement deux choix : être stupide ou être un connard.
Ce que Torval appelle "être une putain de honte pour l'humanité"
Après, tu fais un long post qui mélange tout, et j'ai rien comprit.
Ceci dit, tu as l'air de mélanger ce que le libre appelle le droit de modifier, qui est le droit de récupérer les sources et les repartager.
Et le fait de pas autoriser tout le monde à contribuer à un projet, ce que font apache avec leur CLA, ce que font plusieurs entreprises en mettant leurs sources soue licence libre, mais en n'acceptant pas les contributions, et de manière générale ce que fait tout projet libre qui n'a pas un mob.
[^] # Re: Code sur papier
Posté par uso (site web personnel) . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 3 (+2/-0).
En vrais coder sur papier, ça, c'est fait pendant longtemps.
Ça peu encore se faire dalleur : https://www.youtube.com/watch?v=2XLZ4Z8LpEE
(Vidéo d'une personne qui fait marcher un typewritter des années 30 sur un GNU/linux moderne).
Il faut juste conclure le débat Vim vs Emacs, par ed.
Par contre, j'ai un doute sur l'intérêt écologique de la chose comparé à un écran, mais si Nadia le dit
¯\_(ツ)_/¯.[^] # Re: Scandaleux .... ou pas, moi, j'opte pour la 1ère option
Posté par uso (site web personnel) . En réponse au journal La France crée un fichier des personnes trans. Évalué à 2 (+3/-2).
Ouin-ouin, les machins, ils sont méchants.
Et vu que les machins, on dit être un peu bidules, tout ce qui ressemble aux bidules de prés ou de loin, sont comme les machins, et sont méchants.
Et donc je vais promenoir les truck raciste, car ils s'opposent aux machins et aux bidules (enfin, il ne faut pas trop regarder dans les détails non plus), et ils sont donc forcément gentils.
Ça fait réfléchir.
[^] # Re: goto return cave
Posté par uso (site web personnel) . En réponse au journal Is return the new goto ?. Évalué à 6 (+5/-0).
L'autre solution, c'est avec des longjmp/setjmp:
http://groups.di.unipi.it/~nids/docs/longjump_try_trow_catch.html
Par contre, c'est lent, et une énorme source du bug.
En fait ce sont surement les fonctions les plus dangereuses de C, et c'est presque tout le temps une mauvaise idée de les utiliser.
Comparer aux exceptions C++, un longjmp ne va pas appelle les free fait entre le setjmp et le longjmp, de plus laisse ton programme dans un état qui est beaucoup plus dur à contrôler, qui si le flow du programme est linaire.
Dalleur, que ça soit le mécanisme de defer ou
__attribute__(cleanup)le comportement est indéfini, si un longjmp est fait après le defer/cleanup.[^] # Re: goto return cave
Posté par uso (site web personnel) . En réponse au journal Is return the new goto ?. Évalué à 3 (+2/-0).
Ceci dit il me semble que kantien parle de remplacer les goto, par des try/catch.
Les extensions dont tu parles servent à faire soit un genre de RAII, soie des defer.
Le seul compilateur C qui gère try/catch, c'est MSVC.
Personnellement, j'aime beaucoup les mécanismes de defer, et autres, car ça permet de gérer la libération des ressources, au moment où on les crée, et donc moins de chances d'oublier.
Le problème des goto out; c'est qu'on a le label out à la fin de la fonction, et c'est facile d'oublier de rajouter le free.
Avec les try/catch, le problème reste assez similaire aux goto.
C'est moi qui avais push la 1ʳᵉ version de attribute cleanup dans tinycc, (qui était pas mal bugué, les mainteneurs ont quand même pas mal amélioré mon code). Je n'aurais clairement pas fait le même effort pour imiter les try/catch de MSVC.
[^] # Re: très bonne question
Posté par uso (site web personnel) . En réponse au journal Is return the new goto ?. Évalué à 7 (+6/-0).
En GNU C, tu peux : https://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html
C'est supporté par au moins gcc, clang, et tinycc.
[^] # Re: l'article est intéressants
Posté par uso (site web personnel) . En réponse au lien Hans Peter Anvin : Kernel C++20 ? (article de qualité sur developpez.com). Évalué à 4.
En C, t'a une erreur aussi (Vu que 1.0 est un double, il va dans le type default, donc cmpPtr)
Si tu enlèves le default t'a aussi une erreur :
Ce que fait cmp, c'est juste appeler une fonction qui dépend du type de b (doc ici: https://www.iso-9899.info/n1570.html#6.5.1.1).
Après si l'appelle de fonction déroulée pas la macro n'est pas bon, le compilateur va le remarquer.
Dalleur utiliser default n'est généralement pas une super idée.
Cette remarque n'était pas pour dire que _Generic > template, mais que si tu essayes de reproduire le comportement des template C++ en macro C++, ça va effectivement être compliqué, et hasardeux.
[^] # Re: l'article est intéressants
Posté par uso (site web personnel) . En réponse au lien Hans Peter Anvin : Kernel C++20 ? (article de qualité sur developpez.com). Évalué à 2.
Bon les destructeurs, je suis d'accord que ça manque au C,
Mais gnu C, implémente une extension
__atribute__((cleanup())), qui est implémenté par gcc, clang, tinycc, intel compiler, et est utilisé dans flatpak, systemd, et libvirt pour ne citer que quelques exemples.[^] # Re: l'article est intéressants
Posté par uso (site web personnel) . En réponse au lien Hans Peter Anvin : Kernel C++20 ? (article de qualité sur developpez.com). Évalué à 3.
Tu te relis beaucoup de fois pour un truck qui se fait en une ligne de code, et est assez explicite, je trouve.
Bon ok, c'est du C11, et si tu veux faire la même chose avec des macros en C++, ça va peu être plus compliqué.
# Mouais
Posté par uso (site web personnel) . En réponse au lien Expérimentation scheduler Linux en Rust avec des promesses de gain pour les jeux. Évalué à 4.
La vidéo ne parle ni des avantages de rust par raport a C, ni de l'algo utilisé pour le scheduler en rust.
Si l'algo utiliser n'est pas le même, l'ordonnanceur aurait pu être codé en js, avec ça VM dans le kernel qui exécute le code JS, et quand méme avoir un gain de performances.
[^] # Re: Complètement crétin !
Posté par uso (site web personnel) . En réponse au journal Comment briller auprès de la gent féminine dans « le monde de la tech ». Évalué à 2. Dernière modification le 09 décembre 2023 à 14:20.
Oui, et mon point, c'est de dire que c'est plus dur d'écrire un commentaire qui ne contient pas d'erreur qu'un code qui ne contient pas d'erreur.
Car le code est beaucoup plus testé.
Le code et les commentaires évoluent ensemble, mais les commentaires ont plus de chances de mal évoluer.
[^] # Re: Complètement crétin !
Posté par uso (site web personnel) . En réponse au journal Comment briller auprès de la gent féminine dans « le monde de la tech ». Évalué à 1.
J'avoue avoir déjà fait ce genre de commentaire, et ça rend assez propre.
Par contre, j'ai aussi déjà fait ce genre de commentaire, dans des fonctions que j'ai beaucoup modifiées après, et forcément, j'ai oublié de modifier les commentaires, et me suis retrouvé avec des commentaires type "/* initialize Video */", alors que le code dessous n'initialise pas du tout la Vidéo, qui a été bougé 20 lignes en dessous.
[^] # Re: Complètement crétin !
Posté par uso (site web personnel) . En réponse au journal Comment briller auprès de la gent féminine dans « le monde de la tech ». Évalué à 4.
Je peux comprendre l'attrait de commenter son code, le problème, c'est qu'on a très peu d'outils pour aider à trouver des commentaires faux.
Si on oublie de free une variable, on a plein d'outils pour aider à trouver qu'on a oublié de free cette variable, si on fait un if (variable) à la place d'un if (not variable), on a des tests et un programme qui bugue, ce qui peut nous aider à trouver qu'on a oublié la négation.
La plupart des gros projets ont tous un tas d'outils pour trouver des bugs, et de la revue de code, et pourtant ont toujours plein de bugs.
Les commentaires, eux, n'ont pratiquement rien (juste la revue de code). Ce qui fait que les commentaires, qui eux sont très peu analysés, sont généralement la partie du code qui contient le plus de bug par ligne de commentaire. (par bug, j'entends commentaire qui ne dit pas ce que devrait faire le code)
Et si un commentaire est erroné, aucun outils ou tests ne va te dire qu'il est faux.
Et quand t'a déjà passé une demi-journée à te faire toute la Documentation d'une bibliothèque, car un commentaire te dit d'absolument appelle une autre fonction avant d'appeler celle dont tu as besoins, pour au final en lisant le code de la bibliothèque te rendre compte que le commentaire aurait juste dû être supprimé, car il concernait une ancienne version de la bibliothèque.
Bah, tu regardes les commentaires d'un autre œil.
Je ne dis pas qu'il ne faut pas commenter son code, mais c'est très facile d'oublier une négation dans une phrase, ou de changer la logique d'un code, et laisser les anciens commentaires qui explique l'ancienne logique.
C'est pour ça que les commentaires ne devrait être utilisé que pour dire ce que ne dit pas le code, ou faire de la Documentation utilisateur.
Et si un code à besoins d'être commenté, peut-être que c'est le code qui est trop compliqué et devrait être changé pour peu être avoir un code plus simple, voir qu'y s'auto-documente.
[^] # Re: Réalité
Posté par uso (site web personnel) . En réponse au journal L’avis de RMS sur les relations sexuelles. Évalué à 2.
Mais étant un développeur standard, et ayant fait des math, on m'a appris à ne pas fuir, les dérivés.
Hors étant dyslexique, je lis, en la dérive ambiante, des ivres d'ambiance.
Alors étant quelqu'un de cultivé, l'ivresse me fait penser à Gin des boulots étrange. (Du manga Gintama(銀魂)).
Vu que le dernier épisode de Gintama que j'ai vu parlait de Wizardry, il me semble logique, et dans le sujet de ce thread, de parler de cette saga de RPGs, qui si on y regarde à tout l'air d'être une vielle saga de Dungeon Crawler classique, et sans peu d'intérêt,
Quand on y joue, on se rend compte que c'est belle et bien un Dungeon Crawler très classique avec assez peu d'intérêt aujourd'hui, et contient tout ce qui peut être énervant dans un vieux RPG : piège invisible, histoire très banale, mort à tous les recoins, et qui souvent paraissent injustifiés. (sans parler du manque de tuto pour bien commencer le jeu).
Et si le jeu est l'un des premiers Dungeon Crawler, la concurrence de l'époque était rude, c'est dure de voir l'influence qu'à eux ce jeu sur les JDR qui on suivit, et au final, cette saga, c'est plutôt fait oublier à côté des ultimas, Elder Scroll ou la Saga de SF inspirée de Star Trek : Might and Magic. (bon en vrais, je parle sans trop connaitre, des gents expliquent que Wizardry à inspiré tous les jeux récents)
Mais si on regarde le jeu d'un autre angle, c'est en fait l'un des ダンジョンアドベンチャー(Dungeon Crawler en japonais) les plus influant qui a existé.
Car si en Europe, et aux US, on ne se rappelle pas tant de Wizardry, le jeu à était un carton au Japon, tellement qu'aujourd'hui la plupart des Wizardry récent, sont développés par des Japonais.
La série a servi d'influences à une flopée de JRPG, et même Dragon Quest n'aurait surement pas vu le jour sans Wizardry. (qui est le JRPG qui a influencé tous les JRPG)
Vu que généralement les Jeux de chez nous ne marchent pas beaucoup au Japon, et les RPG occidentaux y sont très peu connus, je trouve ça étonnant de voir à quel point ce jeu à influencer les jeux japonais.
Dalleur, si on retrouve autant de wizardry dans un Dragon Quest 1 que dans un Elder Scroll Arena, c'est rigollot, de voir à quels points les Jeux japonais et américain, on prit des directions différentes en s'inspirant du même jeu.
Par contre, niveaux ré-implémentation Libre, je n'ai pas trouvé grandes choses :
Celui-là qui n'a pas l'air finit, et abandonné, mais a la particularité assez rare, que sur la fin le dev voulait porter le code de C++ a C.
et celui-là qui a l'air d'être. Encore développée et a un beau Readme.
Mais au final, si Wizardry m'a appris une chose à travers ces Dungeon trop long, ces couloirs interminables et coupe-gorges à chaque pas, c'est qu'il ne faut pas se fier aux apparences, que l'ont peu trouvé le beau dans ce qui semble pourtant si banal, et un cus de sac peu en fait étre un téléporteur vers les plus beaux trésort, donc s'arrêter à un discours de RMS qui semble trop ambiguë pour juger le personnage est une erreur. et une preuve flagrante d'inculture. (aussi flagrant que pour faire un pavé aussi long sur Wizardry, le mettre en commentaire était une bien meilleure idée qu'un journal)
[^] # Re: Réalité
Posté par uso (site web personnel) . En réponse au journal L’avis de RMS sur les relations sexuelles. Évalué à 6.
Ceci dit, RMS, est assez strict dans ça manière d'utiliser des ordinateurs, à ne s'autoriser aucun logiciel proprio.
Alors que GPL c'est juste une licence qui peu même être utilisé en dual-licence avec une autre propriétaire.
Si on me dit, il faut plus de RMS, j'entends, il faut plus de gents qui ne font aucune concession quand on parle du libre.
Si on me dit, il faut plus de GPL, j'entends qu'il faut plus utiliser la GPL, mais ça ne dit rien sur les bibliothèques utilisées, ou sur les doubles licences.
Genre faire des jeux en GPL qui utilisent Unity rentre dans l'idée de "il faut plus de GPL", mais pas "il faut plus de RMS" quand on se base sur ça.
Et il me semble que quand on écoute une personne qui développe des idées, ont peu en adapter certaines et rejette d'autres.
Si quelqu'un écrits un blog "il faut plus de Proudhon", et parle d'autogestion, je ne vais pas associer les idées du blogueur aux idées sexistes et antisémite de Proudhon. (surtout si dans le même poste la personne dit ne parler de Proudhon que pour ce qu'il a écrit sur l'autogestion)
[^] # Re: scepticisme...
Posté par uso (site web personnel) . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 3.
Ceci dit, on a encore pas mal de programme, comme curl ou wine, qui sont en C89 pour être le plus portable possible.
Après pour Hare, bah, je trouve que comparer à un GNU C, qui a ces defer, bah la seule chose qu'il apporte, c'est sa gestion d'erreur, et les modules.
Et comparer à C, je n'ai pas l'impression qu'on ait de _Generic, ou de macro, ce qui a l'air d'en faire un langage moins puissant que GNU C11.
Comparer à un C11 sans GNU, on échange les macro et générique, pour du defer, et des modules, ce qui n'est pas forcément si rentable.
[^] # Re: absolument pas stable.
Posté par uso (site web personnel) . En réponse au lien The First Stable Release of a Memory Safe sudo Implementation. Évalué à 2.
doas se veut vraiment minimaliste, et n'a que peu d'options de sudo.
Ça se limite à autoriser des user/groups à se lancer en tant que root. ou à autoriser/dénier certaines commandes.
Il y a 2/3 options telles qu'autoriser de ne pas mettre de mot de passe, ou ne pas redemander doas à chaque fois.
Là conf n'est pas compatible avec sudo, et ressemble à ça
Mais de mémoire sudo permet de configurer les timeout, et a plein d'autres options caché que je ne connais pas.
Mais oui sudo-rs supporte surement déjà plus d'option que doas, surtout qu'il se veut un "drop-in" remplacement.
[^] # Re: absolument pas stable.
Posté par uso (site web personnel) . En réponse au lien The First Stable Release of a Memory Safe sudo Implementation. Évalué à 3.
http://www.tux-planet.fr/comment-se-faire-insulter-par-sudo/
[^] # absolument pas stable.
Posté par uso (site web personnel) . En réponse au lien The First Stable Release of a Memory Safe sudo Implementation. Évalué à 3.
Pardon, je viens de voir que sudo-rs ne support pas les insulte, le projet n'est absolument pas stable en fait.
# plus stable que doas ?
Posté par uso (site web personnel) . En réponse au lien The First Stable Release of a Memory Safe sudo Implementation. Évalué à 3.
doas c'est l'implémentation de openbsd de sudo en C.
Elle se différencie de sudo sur le fait que doas support moins de fonctionnalités que sudo.
Par contre, avec le minimalisme et le focus sur la sécurité de openbsd, si je dois prendre une implémentation safe, j'irai plus vers doas qu'un sudo-rs qui, malgré une implémentation dans un langage safe, a une base de code beaucoup plus grosse à maintenir et donc plus de chances de faille de sécu.
Bien sûr, il ne faut pas avoir besoins des fonctionnalités supplémentaires de sudo, et l'option pour se faire insulter manque à doas.
[^] # Re: donc on doit utiliser quoi ?
Posté par uso (site web personnel) . En réponse au lien .io considered harmful. Évalué à 5.
Oui, c'était de l'humour, mais j'avoie ne pas avoir fait trop d'effort pour expliciter mon 2nd degré, donc je comprends les moinssage et le message 1er degré pour expliquer mon erreur.
[^] # Re: donc on doit utiliser quoi ?
Posté par uso (site web personnel) . En réponse au lien .io considered harmful. Évalué à 1.
Ouais, j'aurais dû partir sur TLD, et pas sur TLD.
Mais je me suis limité à la page anglaise, et y'avais pas de lien vers TLD.
Après, je suis partie à chercher dans les CPUs instruction set, si il n'y a pas d'instructions qui s'appellent TLD.
Mais ça a pas l'air d'être utilisé.
[^] # Re: donc on doit utiliser quoi ?
Posté par uso (site web personnel) . En réponse au lien .io considered harmful. Évalué à 5.
Ah, ouais, ça parle de Tracking Level Detections
Mais ce n'est qu'une petite partie des capacités de l'I/O de l'ordinateur, fait dans un domaine ultra-spécialisé, ça ne rend pas tout l'I/O harmful.
Note:
Je ne viens pas de passer 10mn à chercher tous les acronymes de TLD pour creuser mon moinssage.
Normalement, c'est plus facile en crée des quiproquo débile, vu le nombre d'acronymes utilisé en informatique, des fois dans des domaines pas très éloigné.
Genre parler de comment KVM("keyboard, video, and mouse"), gère la VM(Virtual Machine) d'une VM(Virtual mémory).
Dalleur KVM ça peu aussi vouloir dire Kernel-based Virtual Machine.
# donc on doit utiliser quoi ?
Posté par uso (site web personnel) . En réponse au lien .io considered harmful. Évalué à -1.
Si on ne peut plus faire des appelées I/O, via stdIO ou autres, comment tu affiches des messages dans tes programmes ?
Parce que même si on s'amuse à faire les appelle système manuellement (avec de l'assembleur inline, ou la fonction syscall), bah ça reste de l'IO.
[^] # Re: Arguments et auto-doc
Posté par uso (site web personnel) . En réponse au lien raku [ex perl6] super efficace pour écrire des outils en ligne de commande.. Évalué à 2.
En native, je ne sais pas, par contre raku est compilable en JVM: https://www.raku.org/compilers/
[^] # Re: à charge
Posté par uso (site web personnel) . En réponse au lien La fondation Gnome engage une shaman comme directrice exécutive . Évalué à 4.
Tu es en train de répondre à :
?
Parce que les problèmes avec cette phrase, c'est :
0 : Elle prend les propos du "lead d'Ashahi linux" sur son compte perso, et les fait passer pour la "position officielle du projet". (ça s'appelle un sophisme par association)
1 : Elle change son sens de "si vous étes anty-trans, vous pouvez GTFO", à "si vous êtes anty-trans, vous n'avez pas le droit de contribuer". (ça s'appelle un homme de paille)
3 : elle résume la transidentité à un kink, ce que ça n'est pas, mais est une manière de dénigrer les trans. (autre homme de paille, je suppose ?)
Et le truck, c'est que pour faire une phrase aussi chargé en sophisme au 1er degrée, on à généralement deux choix : être stupide ou être un connard.
Ce que Torval appelle "être une putain de honte pour l'humanité"
Après, tu fais un long post qui mélange tout, et j'ai rien comprit.
Ceci dit, tu as l'air de mélanger ce que le libre appelle le droit de modifier, qui est le droit de récupérer les sources et les repartager.
Et le fait de pas autoriser tout le monde à contribuer à un projet, ce que font apache avec leur CLA, ce que font plusieurs entreprises en mettant leurs sources soue licence libre, mais en n'acceptant pas les contributions, et de manière générale ce que fait tout projet libre qui n'a pas un mob.