L'article est vraiment très long. Je ne l'ai pas non plus lu en entier, mais je l'ai survolé jusqu'au bout. Je ne sais pas à quel point le milieu décrit est différent d'autres milieux, notamment les autres milieux « masculins ». Dans la restauration, en cuisine, c'est pas facile non plus d'être une femme (c'est ironique, non ?).
C'est vrai qu'on a beaucoup de journaux sur le féminisme ces temps-ci, mais celui là ne mérite pas d'être moinssé comme il l'est déjà, ne serait-ce que parce qu'il est vraiment en rapport avec le libre (le sujet est abordé dans l'article) et l'informatique. Par contre, comme l'article est vraiment très long, un résumé des points forts de l'article aurait pu être sympa. Pour les gens comme moi qui auront manqué les points essentiels.
C'est vrai, pourquoi ceux qui ne sont pas capable de se concentrer plus d'une demi dépêche noyau devraient être exclus du débat ! Si ça c'est pas de la discrimination envers les hommes ! (il n'y a qu'un homme pour être bête au point de ne pas lire les long textes… :-°)
(Quand à mon expérience personnelle, je n'ai pas été beaucoup exposé au sexisme, parce que je suis un asocial. Mais les remarques sexistes que j'entend sortent aussi bien de la bouche des hommes que de celles des femmes. Na.)
Après, il faut différencier les féministes. Il y en a qui se battent pour l'égalité des sexes, et il y en a qui se battent pour un inversement de la tendance.
Aussi, certaines féministes nient le rôle de la femme dans sa soumission. Pourtant, dans le modèle contre lequel elles se battent, ce sont les femmes qui éduquent les enfants… Qui deviennent sexistes.
Les responsables ne sont pas les hommes, ou les femmes, pas même certains hommes et certaines femmes. Ma mère est pour l'égalité des sexes. Elle a été choqué¹ quand ma sœur lui a dit un jour : « Pourquoi tu fais pas faire ce travail à mon frère ? À son âge, tu me le demandais déjà. ». Parce que même avec des idéaux assez égalitaires, la reproduction sociale s'exprime à un niveau inconscient.
Quand on reproche aux féministes d'être l'une des raisons du sexisme, on ne se réfère qu'à une partie de la population féministe, celle qui gueule fort et sans réfléchir. Comme quand on dit que les musulmans sont tous extrémistes, que les juifs essayent de supprimer la liberté d'expression, etc.
Du côté de la femme objet, les magazines féminins, écrit par des femmes, sont rarement d'un niveau plus élevé que les magazines pour homme : la femme aussi « consomme » de la femme objet.
¹ : Pas choquée par la remarque, choquée d'avoir agit de la sorte… (je précise, on sait jamais ;-))
Ok. Mmmh… Moi, je me rappelle de Mac OS 7, Wikipédia me dit que c'est de ça que tu parles avec System 7 ^_^. Et je le préférais largement à Windows 98 (que je préférais à Windows 95).
La force de Windows 95 est donc d'être sorti à une époque ou la concurrence était soit morte (Amiga/Atari), soit trop chère (Mac OS, NextStep), soit pas encore sortie (Linux(?), BeOS).
Mais comme on parlait des qualités de Windows 95… À part être accessible aux petit portes monnaies, il avait vraiment un avantage sur ses concurrents, niveau qualité ?
Pas que je nie l'apport de Windows ou ta réaction de l'époque (ce serait osé), mais comme, dans le cas de Google, on parle d'un marché avec un très forte concurrence (à l'époque, il y avait Lycos, Google, Yahoo, les portails fournit par les FAIs…), je me demande si « tout le monde aurait voulu Windows » dans un cadre où il aurait été plus facile de le comparer à la concurrence (donc, avec une concurrence accessible, par exemple, s'ils avaient pu tester un certain temps les différents systèmes avant de choisir).
Parce qu'il a occupé le marché, ça ne veut pas dire que c'était un bon produit pour autant. Ça peut juste signifier un manque d'information ou de choix.
Après, même si je me demande si on peut dire qu'il a été « choisit », vu qu'il était quasiment seul sur le marché, je ne sais pas si on peut continuer à dire qu'il a été imposé (c'est le débat), à la lumière de la situation que tu nous décris. Maintenant, il est imposé (il y a qu'à voir tout les débats autour de Vista à l'époque, et Windows 8 maintenant). Mais en 95… Ça se discute, en effet (Mais choisit aussi, ça se discute. D'ailleurs, on en discute ;-))
Après, un point pour Microsoft : on râle sur la vente liée, mais à l'époque où Microsoft s'est imposé, les concurrents à Microsoft avaient la même pratique (Macintosh vendu avec Mac OS, Le NextCube avec NextStep, les BeBox avec BeOS…). L'arrivée des système libres a rendu cette pratique moins acceptable, mais avant ça, elle ne perturbait pas la concurrence (les pratiques douteuses mises à part).
Windows s'est imposé par ses qualités ? Dans mon entourage, en 96 (oui, j'ai un an de retard), personne n'en voulait, c'était de la merde. Sur un échantillon de 10 personnes, on peu dire que 90% de la population n'en voulait pas ;-).
Nous, on avait un mac. Et on y est resté longtemps. Ma mère a quitté Mac uniquement pour un Linux que je lui ai installé et configuré aux petits oignons (et elle préférerait garder son Mac OS 9 si elle pouvait).
Bon, je suis jeune, j'ai un entourage d'intellectuels qui réfléchissent à leur achats, et qui avait un ordinateur pour des raisons professionnelles : payer un Mac au prix fort était plus intéressant qu'un Windows. De meilleurs logiciels, une meilleure interface… Sans compter qu'on les achève, nos ordis : Son iMac première génération est mort (moribond) il y a deux ans, et elle a utilisé son portable Macintosh il y a deux jour pour récupérer de très vieilles données. Le tout date d'avant 2002, puisqu'il tourne sur Mac OS 9.
Mais quand je lis des articles sur l'histoire de l'informatique (témoignages de grand programmeurs, articles Wikipédia, tout ça), ce que j'en retiens, c'est que Windows n'avait pas tant de qualités que ça (les blagues sur la stabilité de Windows, elle sont très vieilles, pourtant Mac aussi plantait, mais pas de manières aussi surprenantes). Si les gens ont eu des Windows, c'est parce qu'ils tournaient sur PC, et que les PCs, par rapport à la concurrence, c'était pas cher, et qu'on en trouvait partout (et les vendeurs essayaient de le caser même quand on demandait un mac…).
Quand à XP, il est meilleur que les Windows précédents (et suivants :-°), mais pas non plus bien meilleur que la concurrence. J'ai débuté Linux sur une Mandrake. Elle n'était pas pire que Windows, même mieux (le seul défaut dont je me souvienne, c'est OSS…). Il faudrait demander à ceux qui ont eu autre chose que Windows dans les mains – et pendant un moment –, avant de dire si Windows était supérieur. BeOS était si mauvais ? Amiga OS ? GeOS ?
Pour moi, l'hégémonie de Windows vient d'abord du prix du matériel sur lequel il tournait, puis du manque d'information des gens. Je n'ai jamais entendu quelqu'un venant d'un autre système d'exploitation dire « Windows est vachement mieux ! », même quand ils ont abandonné le système en question pour un Windows (Parce que le système est mort, parce que… Windows)
Je ne parle que d'expérience personnelle, parce que c'est tout ce que je vois. Mais entendre que Windows s'est imposé par ses qualités, ça me surprend, et je viens d'expliquer pourquoi. C'était une remarque sérieuse, ou juste balancé comme ça, sur des suppositions ? (C'est une vrai question, ça m'intéresse d'entendre quelqu'un qui à l'époque trouvait Windows meilleur que la concurrence…)
Quand à Google, je suis d'accord avec ceux qui disent qu'il a été choisit. J'ai souvent entendu des gens râler sur Windows « mais il y avait que ça ». Mais les premières réactions à Google ont été « Mais c'est génial ! ». À l'époque, il y avait même de la pub à la télé pour Lycos. Pourtant, c'est Google qui est sorti du lot. Pour parler de la vente liée, Google a réussit à la surmonter dans le domaine des mails (quasiment tout les FAI proposent une adresse mail, pourquoi j'ai tant de contacts en Gmail ?). Dans mon cas, comme pour beaucoup sûrement, Google s'est développé par le bouche à oreille (et ça vaut pour Gmail aussi). On est loin du fait qu'il était fournit de base sur la majorité des ordinateurs, dont les moins chers. Même intégré à Firefox : Google s'est imposé bien avant ça, à l'époque d'Internet Explorer 5 !
Les mots ont un sens quand leur définition est partagée. Si je dis que j'aime les parapluies, quand ils sont assez sucrés, ma phrase n'a pas de sens, sauf si je précise avant que pour moi, un parapluie, c'est une espèce de gâteau. Si je dis à un ami que sa fille sera heureuse s'il lui offre un gros parapluie d'anniversaire, elle va être déçue et il va croire que je lui ai menti, alors que j'étais de bonne fois.
Et ce, jusqu'à ce que j'arrive à convaincre suffisamment de personnes qu'un parapluie, ça se mange et c'est bon. En attendant, le consensus est qu'un parapluie est un objet non comestible destiné à protéger de la pluie.
C'est un exemple assez extrême, mais il se trouve que tu donnes ta propre définition d'un mot, et que ta définition va à l'encontre du consensus. Quand Clownix veut obliger la redistribution à l'upstream, c'est sa définition du libre, et c'est une partie de la définition qui ne fait pas consensus. On peut en débattre jusqu'à ce que la majorité se mette d'accord sur le sujet.
Par contre, le fait qu'empêcher le commercial fait qu'une licence devient non libre, ça fait consensus. Pour Stallman, Torvalds, et De Raadt, mais aussi tout les gens derrière eux. C'est pas trois personnes. Je ne connais pas les effectifs, mais si on regroupe les acteurs de l'OSI et la FSF, ainsi que ceux qui les suivent et les acceptent comme autorités capable de définir ce qui est libre, qu'on rajoute ceux qui préfèrent considérer les DFSG comme vrai définition du libre, et qu'on ajoute encore les agnostiques qui sont tout de même totalement vendu aux quatre libertés comme définition du libre (et ces quatre libertés inclues l'utilisation commerciale), ça fait un paquet de monde. Je serais moins inflexible que Zenitram quand à dire que ta définition du libre n'est pas valable, mais il va te falloir mener un combat contre tout ces gens là pour amender leur définition du libre et faire valoir la tienne.
En attendant, quand je veux un parapluie, je demande un gâteau, ça m'évitera d'avoir faim parce que mon dictionnaire personnel n'est pas plus répandu. Tu as le droit d'avoir tes propres définitions, mais quand tu communiques avec les autres, il faut faire attention à t'accorder avec ton auditoire, si tu ne veux pas perdre toute crédibilité à ses yeux.
Oui, on peut aussi préciser que si B a vendu son code à C, tu peux contacter C en lui expliquant que B ne joue pas le jeu (mais reste poli, quoique tu en penses ;-)), que tu aimerais bien avoir accès aux modifications pour augmenter la qualité du service dont ils profitent, et que ça tombe bien, selon la GPL, ils ont le droit de te donner les modifications de B \o/
(Je précise que je n'ai pas assez d'expérience professionnelle à ce niveau pour décider si faire ça est une bonne ou mauvaise idée. Je vous laisse juge ;-))
En fait l'auteur du billet recherche une possibilité de divulguer son code mais proscrit une utilisation commerciale, un peu à la manière de certaines licences creatives commons pour les oeuvres artistiques. Je peux comprendre le principe mais ce n'est pas du libre.
Il ne proscrit même pas l'utilisation commerciale. C'est juste que pour lui, l'utilisation commerciale doit s'accompagner d'un retour. Si il y a modification du code source et utilisation commerciale, la modification doit être remontée upstream.
Ça ne me semble pas incompatible avec « l'esprit » du libre (partagez, ne gardez pas tout pour vous !). Il y a même (de manière surprenante) une licence approuvée par la FSF qui permet de forcer cette distribution upstream (licence vim, mais là, je me répète :-°), ainsi qu'une licence OSI (la Reciprocal Public License). Manque de pot, la RPL n'est pas approuvée FSF, et la licence vim n'apparaît pas sur la page de l'OSI :-D
Bien sur, en interne ou sans échange financier tout le monde peut modifier le code et jouer avec en toute liberté.
Dans ce cas, cette licence ne suffit pas encore :
Regarding deployment, under the RPL your changes, bug fixes, extensions, etc. must be made available to the open source community at large when you Deploy in any form—either internally or to an outside party. Once you start running the software you have to start sharing the software.
C'est l'un des reproches faits par la FSF à cette licence : même pour un usage totalement interne, les modifications doivent être distribuées.
Ensuite, vis à vis du changement de licence, mais aussi du choix de la licence au début d'un projet, je te conseille de passer un peu plus de temps à lire et comprendre la licence choisie. Les licences de ce types son longues et ennuyeuses, pleines de références croisées, mais c'est le seul moyen que tu as de savoir si la licence te convient ou pas. Un résumé ne suffit pas (il suffit pour éliminer, pas pour confirmer). Si tu avais lu la GPL, tu aurais vu que cette protection manquait (mais tu n'y avais peut-être pas pensé à l'époque). De la même manière, tu verras peut-être des choses en trop dans cette licence (comme ce que je viens de pointer). Les trucs les plus « choquants » sont là. (et même si tu t'en fous de la FSF, ils ont prit la peine de faire un résumé très succinct de ce qui ne leur plait pas, ce qui t'évitera si l'une des trois critiques te semble valide d'avoir à lire toute la licence)
(oui, j'ai noté le « ;-) », mais un peu tard, puis c'est tellement tentant…)
Ceci-dit, c'est une illustration de ce qu'on retrouve dans ce journal : le libre, c'est simple ou pas. Si on se retrouve à utiliser une licence approuvée seulement par un des trois organismes décidant du caractère libre ou non d'une licence, on est sur une pente glissante et exposé aux critiques. Ce n'est pas tant la diversité des licences qui porte préjudice au libre, que la diversité des « autorités » sur le sujet. Dans la définition du libre, il y a des points qui font vraiment consensus, et il y a des points qui font différentes licences et autorités.
Bon, se serait plus simple si une licence valide DFSG était automatiquement valide FSF, et une licence valide FSF automatiquement valide OSI… Mais même pas.
Il y a une différence entre la logique et la moindre des choses. Parfois, on choisit une licence en se disant que les utilisateurs vont jouer le jeu. Puis on se rend compte qu'ils se contentent du strict minimum. C'est même arrivé entre des auteurs BSD et des auteurs GPL (les premiers râlant sur le fait que les modifications soient en GPL (enfin, l'affaire était plus compliquée que ça, mais c'est ce qu'on en a retenu)).
Ça doit pas être agréable de se rendre compte qu'un c*****d a décidé d'utiliser les droits qu'on lui à donné de la manière la plus égoïste possible. Mais c'est vrai que ça veux dire qu'à un moment, on a commis une erreur (une erreur de jugement, je dirais).
Ta vision du libre est une vision altruiste, l'idée est de forcer la coopération. Mais la vision partagée du libre est une vision « préventive » : on ne veut pas forcer les gens à coopérer, mais on veut le leur permettre, et dans le cas du copyleft, empêcher la disparition de cette possibilité.
Il y a trois mots clefs : forcer, permettre, empêcher. Tu as été critiqué sur ton désir de forcer. Permettre pose rarement des problèmes, et empêcher est à utiliser avec modération.
Après, je dis ça en simplifiant les choses, et je me contredis déjà si on lit mes commentaires sur la licence vim (car il y a une part de forçage dans cette licence). De plus, on peut jouer sur les mots en disant « la GPL force la licence de nos modifications ». Ici, je n'argumente pas (parce que ce serait pauvre, comme argumentation), j'essaye de proposer un moyen de reconnaître le « bien » du « mal » (définissez ces mots comme vous voulez, dans ce contexte, ce serait « irréprochable »/« qui provoque des moqueries »)
J'aurais juste un conseil, avant que tu ne passes définitivement sur la RPL : si ton programme est empaqueté dans certaines distributions (en plus de la version que tu propose sur ton site), vérifie que ça ne compromette pas cette possibilité (vis à vis des DFSG, par exemple). Après, tu peux t'en foutre. Tu seras de toute façon critiqué sur la licence (c'est GPL, je préfère BSD – c'est approuvé que par l'OSI, je veux du FSF) ou ta vision du libre (parce que pas deux pensent pareil, malgré mes discours sur le « c'est simple », on voit que même des groupes de personnes comme la FSF et l'OSI n'arrivent pas à se mettre réellement d'accord).
Personnellement, j'aime bien les licences très permissives pour m'éviter ce genre de surprise : si j'utilise une WTFPL, une MIT ou ma LRL, c'est parce que je sais que les gens vont pouvoir en faire n'importe quoi, et qu'ils ont donc peut de chance de ne pas respecter les droits que je leur ai donné. Mais ça veut aussi dire que j'ai pleinement accepté les situations telles que celle que tu décris. Si un jour je suis surpris, ce sera plus de ne pas accepter ce qu'a permis la licence que l'utilisation elle même.
La clause rendant la licence compatible GPL n'annule pas ce devoir. C'est juste que l'auteur autorise une modification à être sous GPL. Dans ce cas, il a toujours le droit de demander les sources des modifications même sans être client.
La clause de compatibilité annule toutefois un morceau de la licence, celui qui dit que les modifications doivent être sous une licence permettant l'inclusion dans le code original. L'auteur ne peut pas inclure le code GPL sans passer tout vim en GPL.
C'est donc une exception envers (et seulement envers) la GPL. Un choix de l'auteur. Je ne sais pas ce que ça donne en pratique.
À noter aussi que la clause rend compatible GPL du côté de vim. La FSF a approuvé la licence vim, ce qui veut dire que, juste à cause de la clause de compatibilité, et manifestement sans retirer le devoir de redistribution à l'auteur original sur demande, la FSF à considéré cette licence comme valable. Conclusion : si on ajoute un devoir de distribution du code source à la demande, même à des non-clients, ce n'est apparemment pas incompatible GPL, et approuvé comme logiciel libre par la FSF.
Personnellement, je trouve cette licence compliquée. Quand je la lis, je me pose plein de questions sur comment vim évolue (est-ce qu'il accumule plein de licences en son sein, toutes compatibles avec la licence vim ?). Et comme je ne suis pas avocat, je ne prendrais pas le risque de tripoter cette licence (quoi, le copyleft n'est pas un virus ?). Mais bon, elle existe, elle est approuvée par la FSF, et elle possède un morceau de ce que l'auteur de ce journal désire, donc, je la pointe du doigt (oui, je sais, c'est pas poli).
comme… des gens comme toi, qui veut restreindre "tu as le droit de modifier que si tu me files une copie"
Bah je me suis posé la question au moment où j'éditais le wiki. Et il se trouve que vim possède cette restriction. Dans ce cas, l'auteur protège à la fois les utilisateurs, mais aussi lui même vis à vis d'un autre auteur.
[…]
d) When you have a modified Vim which includes changes as mentioned under c), you can distribute it without the source code for the changes if the following three conditions are met:
The license that applies to the changes permits you to distribute the changes to the Vim maintainer without fee or restriction, and permits the Vim maintainer to include the changes in the official version of Vim without fee or restriction.
You keep the changes for at least three years after last distributing the corresponding modified Vim. When the maintainer or someone who you distributed the modified Vim to asks you (in any way) for the changes within this period, you must make them available to him.
[…]
Après, il n'y a pas encore le devoir de remonter upstream systématiquement, mais sur demande, même si l'upstream n'est pas client.
Pour ce qui est de se faire du fric sur le dos de l'auteur, ça, par contre, oui, c'est indissociable du libre ;-)
Il y a aussi la licence de vim, GPL compatible et approuvée par la FSF (pour l'OSI, j'ai pas trouvé, ça doit vouloir dire pas approuvée, haha !). Les restrictions citées ici ne s'appliquent pas à la licence de vim, mais c'est une licence copyleft (sauf négociation évidemment), et l'entité modifiant le programme doit fournir à l'auteur original les modifications (avec les droits d'utilisation qui vont bien) si celui-ci les demande.
J'aurais tendance à dire que ce sont deux choses différentes :
Les commentaires en Python et dans la Javadoc ont tendance à décrire l'API. L'objectif est de pouvoir récupérer la documentation d'une bibliothèque à partir de son code source, d'une part, et d'avoir la documentation sous les yeux lors de la programmation de la bibliothèque, d'autre part, non pas pour comprendre le code qu'on écrit, mais pour faciliter la synchronisation entre le code et sa documentation. Mais l'objectif final est de décrire l'API (cette fonction fait ça, celle là fait ceci…).
L'orientation des commentaires de la programmation lettrée est plus destinée à celui qui va lire le code, qu'à celui qui va l'utiliser : on ne se contente pas de dire ce que fait la fonction, mais on explique pourquoi, comment, tout ce qui n'est pas évident. Si j'écris un parser, la documentation « javadoc » va expliquer comment utiliser mon parser (appeler telle fonction pour tel résultat), et la documentation « lettrée » va expliquer le fonctionnement interne du parseur (quel algorithme, quelles exceptions…).
Dans ce morceau de code :
# Sys will be needed to acceed standard file descriptors (stderr, stdout, sdin). importsysdeferror(message):""""Display a message on the stderr"""# Don't forget to put a newline, as write, unlike print, will not append it for us.sys.stderr.write(message+"\n")
Le commentaire """ est l'équivalent de la javadoc, et les commentaires # sont l'équivalent de la programmation lettrée (quand à la pertinence des dit commentaires, essayez de trouver un meilleur exemple aussi court ;-)).
Pour un exemple en français de ce à quoi peut ressembler un programme littéraire, j'ai écrit celui-ci il y a trois ans. (soyez gentils avec ma connexion, c'est auto-hébergé)
Bon, mon style a beaucoup évolué depuis (c'est fou ce qu'on peut changer vite). Les morceaux de code sont conséquents, tout n'est pas dit (entre autre, une revue rapide du mode de fonctionnement du programme n'aurait pas été de trop), certains commentaires ont été écrits par captain obvious, il y a des passages pas très formels (lire : il y a des grossièretés), il n'y a pas de licence. Comme j'ai la flemme d'aller reprendre ce code dont je ne me sert plus du tout (puis bon, c'est un jouet, donc niveau motivation, si je l'utilise pas…), ces problèmes vont rester. À moins qu'un fou désire jouer avec. Dans ce cas, je ne dirais rien, mais il vaux mieux qu'il m'en informe, histoire que je fasse au moins l'effort de spécifier une licence, puis que je lui donne la source s'il ne l'a pas trouvé tout seul.
Justement, l'objectif de la programmation lettrée est de créer ce plan. Certes, de manière plus verbeuse qu'avec juste des schémas. Mais le programme se présentant comme un livre, il peut inclure des schémas.
J'avais commencé à écrire un programme assez conséquent (pas terminé, même s'il est juste en pause). La majeure partie de l'effort s'est retrouvée à penser, puis décrire l'architecture. Il y avait des schémas inclut.
Knuth est avant tout un mathématicien, et si le langage de l'ordinateur est celui des mathématiques, sa propositions est tout à fait pertinente : ce que j'ai lu qui ressemble le plus à de la programmation lettrée, c'est les travaux de mathématiciens décrivant des algorithmes (celui-ci par exemple).
En fait, j'ai l'impression que la programmation lettrée se rapproche plus de la conception logicielle « à l'ancienne », où on réfléchit, spécifie, etc. énormément avant la moindre ligne de code, et où les spécifications ne vont pas changer. Dans ce cas, on obtient un livre, qui décrit de bout en bout l'implémentation du programme, de manière précise, avec schéma… Ce livre traite à la fois de l'architecture du programme, des détails d'implémentation, des pièges à éviter… C'est à la fois la description du programme et un traité sur comment résoudre le problème auquel le programme répond.
La programmation lettrée me semble toutefois moins adaptée à des spécifications en continuelle évolution, comme on croise dans les méthodes agiles, programmation extrême, etc. (et quoi que vous pensiez des méthodes en question, le problème auquel elles veulent répondre existe et est inévitable dans certains domaines). Ces méthodologies étant très courantes de nos jours, et pertinentes dans les domaines pour lesquels je programme, j'aurais aimé savoir si quelqu'un avait réussit à les concilier à la programmation lettrée.
Je me pose d'autant plus cette question que je croise de plus en plus de propositions quant à cette pratique (comme cette nouvelle implémentation par CoffeeScript). La programmation lettrée « des origines » date d'une époque où les besoins d'un programme étaient fixée avant l'écriture, et avec l'avènement de la programmation extrême est entrée en hibernation. L'éveil/évolution de cette pratique dans un nouveau contexte peut signifier qu'un début de réponse se met en place, visant à concilier ces deux mondes.
Pour ma part, je suis passé à autre chose, influencé par Forth (dans ma recherche de la « méthode parfaite », l'approche de la programmation lettrée et l'approche de Forth sont les deux réponses qui m'ont le plus convaincues, bien que d'apparence totalement opposées). Je continuerais d'utiliser la programmation lettrée pour les problèmes « finit » (utilitaire shell, programme qui ne fait qu'une chose mais le fait bien), mais je n'essaye même plus pour les problèmes « créatifs » (site web, programme évolutif…).
Et je suis donc intéressé par l'avis de ceux qui ont pratiqué, ou pratiquent encore, la programmation lettrée dans le cadre instable devenu courant de nos jours.
Depuis que j'ai découvert la programmation lettrée, j'ai beaucoup accroché avec le concept. J'ai même traduit l'article Wikipédia anglais en français, afin de pouvoir faire profiter mes amis anglophobes du concept.
J'ai écrit quelques programmes en utilisant des outils comme noweb, mais mon expérience est que cela mène à un code assez rigide :
Quand on écrit un programme assez conséquent, on écrit encore plus de documentation. La conception du programme ressemble dans mon cas à l'écriture d'un livre. On organise notre documentation (qui n'est pas comment utiliser le code, mais quel est le contexte du code, pourquoi il est là, quel est son but réel) comme un livre, en le découpant en chapitre, suivant les différentes tâches à accomplir et les différents modules.
Lors de la refactorisation, on n'a plus juste un petit morceau de code à déplacer, mais aussi toute une documentation à mettre à jour.
Dans le cas d'un code extrêmement factorisé, la documentation devient quasiment inutile (une fonction parle d'elle même), ou – pour un problème complexe – a une meilleure place dans un document annexe décrivant le problème. Au pire, cette documentation peut se trouver au début du code, comme préambule. Elle n'est pas destinée à changer (elle décrit le problème), et n'est plus mélangée au code (ce n'est donc pas de la programmation lettrée).
L'article de blog lié dans la dépêche pose la question de la programmation objet mixée à la programmation lettrée. J'ai remarqué dans ma manière de faire (et pour un programme écrit dès le départ en programmation lettrée, par contraste avec des codes déjà écrit et documentés/réorganisés après coup) que ce n'était pas très différent du fonctionnement headers/code que l'on trouve en C++. J'aurais par exemple une partie décrivant mon objet, puis plus loin la définition des méthodes (dans leur propres chapitres).
Malgré tout l'enthousiasme que j'éprouve envers cette pratique, j'ai la sensation qu'elle ne fonctionne que dans le cas de petits programmes. Mon expérience porte sur un environnement de développement plus « complet » que ceux proposés par Haskell, CoffeeScript et Docco, c'est à dire des environnements où l'on peut vraiment séparer et déplacer le code suivant notre propre logique (les possibilités de factorisation offertes par Haskell et Coffeescript diminuent le besoin de réorganisation, mais je ne factorisais pas autant à l'époque, et cette réorganisation me semble encore pertinente dans le cas de la programmation objet). Et je n'ai pas trouvé d'exemple de code vraiment conséquent et en perpétuelle évolution écrit en programmation lettrée.
Je parle de petits/gros programmes, mais mon véritable questionnement porte sur les programmes « jamais finit » : si le programme a une tâche à effectuer, et le fait bien, il n'a plus de raison d'évoluer. Dans ce cas, la programmation lettrée permet d'avoir un travail définitif et bien documenté. Mais pour les programmes plus « vivants » (par exemple, le code de LinuxFR n'a jamais arrêté d'évoluer), quelqu'un a t'il déjà utilisé avec succès cette méthode ?
Posté par daeldir .
En réponse au journal Habitrpg.
Évalué à 5.
Pourquoi les filles peuvent changer d'habit et pas les mecs ? Y en a marre de cette domination incessante des femelles sur les mâles au niveau vestimentaire ! (ça, c'est pour rester dans le ton des journaux de ces derniers jours ;-))
Bon, ça doit être dû aux graphismes de BrowserQuest, mais j'avais même pas vu qu'on pouvait personnaliser son avatar sur ce jeu, donc j'avais pas râlé ;-)
Plus sérieusement, il y a un « connectez vous avec Facebook ». Pourtant, il est de moins en moins rare qu'un internaute possède un autre fournisseur d'identité (Google, Twitter, pour ne citer que les plus proches de Facebook…). Un champ OpenID me semblerait plus pertinent, et ce, pour chaque site proposant une connexion Facebook (et OpenID, ça veut pas dire « connectez vous avec Google, Twitter ou Facebook », ça veut dire « connectez vous avec votre fournisseur d'identité, quel qu'il soit » – j'ai déjà vu des sites se limiter aux trois entités sus-citées, et je trouve pas ça mieux).
Je ne sais pas si tu participes au développement. Bah, j'irais jeter un œil sur leurs outils de communication (bug tracker, tout ça).
Et aussi, il y a pas indiqué ce qui se passe si on meure. Il doit bien y avoir une conséquence, sinon, ça a pas d'intérêt, et cette conséquence doit nous permettre de continuer à jouer, pour la même raison… Ŀà, je serais tenté de jouer et mourir juste pour voir.
Posté par daeldir .
En réponse au journal Habitrpg.
Évalué à 10.
Je vais répondre sur le premier point, parce que je me sens concerné par celui-ci.
Avant tout, je tiens à préciser que cela fait de nombreuses années que « je me pose des questions sur ma vie », donc je ne commencerais pas aujourd'hui ;-)
Ensuite, à mon niveau, je ne sais même pas si « ça » suffirait comme incitation pour réaliser ce que je veux faire. C'est un problème de volonté, c'est personnel, c'est en partie physique, mais « vouloir » quelque chose ne me suffit pas pour agir. D'autant plus quand c'est un objectif indirect (pour atteindre cet objectif, je ne dois pas juste travailler sur cet objectif, mais surtout sur des tâches annexes qui me débloqueront l'accès à cet objectif). Par contre, « devoir » faire quelque chose marche mieux. Les tâches ménagères, par exemple, j'arrive à les faire. Parce que je dois les faire, que je le veuille ou non.
L'intérêt d'un tel programme est que l'on peut transformer le « vouloir » en « devoir », ce qui a un effet direct sur la (ma) volonté. Il permet aussi (surtout ?) de nous motiver sur les tâches annexes qui vont débloquer notre objectif voulu.
Le « devoir » n'est pas fort (si je ne fais pas le ménage, ou que je ne paye pas mes factures, la conséquence est bien plus importante que si mon personnage meure dans ce jeu). Mais le simple fait que ça devienne un devoir, avec une conséquence, même moindre, en cas d'échec (alors que de base, il n'y a une conséquence qu'en cas de réussite) peut débloquer certaines personnes.
Si tout va bien dans ton « paysage psychiatrique » (cherchez pas, je viens de l'inventer), il peut être difficile de se projeter dans la tête d'un mec pas aussi sain d'esprit, et je comprend que ça te fasse flipper. Mais – et ce que je vais dire devrait s'appliquer aussi aux autres points de ton commentaire – utiliser un tel programme ne veut pas dire que c'est la seul chose qui compte.
Équilibrer les statistiques, pour rendre les points d'expérience et niveaux pertinents, est une tâche ardue ? Qu'importe, on n'est pas en évaluation, on est en progression : on se fiche de combien on avance, mais on a un marqueur qui nous montre qu'on avance. Ça vaut aussi pour ton quatrième point : l'objectif n'est pas les points, mais d'avancer. Les points ne peuvent pas vraiment faire office de mesure (car, comme tu l'as dit, il est difficile (impossible ?) d'en faire une mesure pertinente) mais ils sont un témoin de la progression. Et parfois, c'est bien de voir qu'on progresse, surtout sur des tâches où la progression est tout sauf évidente.
Pour ton commentaire sur le karma, je ne dirais rien, je suis plutôt d'accord : je ne contribuerais pas à Stack Overflow pour les médailles, je n'interviens pas ici pour le karma (Mais je le regarde, et j'aime bien avoir de bonnes notes. Pas que la note compte pour moi, mais j'essaye de rester pertinent, et voir que la communauté a approuvé mon commentaire me fait plaisir.)
Quand à ta conclusion, j'aurais tendance à dire que l'outil proposé permet de lutter contre la procrastination (si tu joue le jeu, tu « perd » quelque chose en procrastinant, tu n'y a donc pas intérêt), n'a pas d'effet sur la paresse (je vois pas trop en quoi ça peut la conforter ou la contrecarrer — avis purement subjectif), et en effet nous conforte dans la facilité (conforte, pas empire ;-)) : l'objectif est justement de faciliter la mise en mouvement. Mais se plaindre de la facilité, à mon sens, c'est se tromper d'objectif : c'est en essayant de rendre les choses faciles qu'on progresse : quand une chose est facile, on peut se concentrer sur une autre, plus compliquée, jusqu'à ce qu'elle devienne facile. Ce site facilite la mise en mouvement ? Ce n'est pas un mal, on n'a plus besoin de se concentrer sur le départ, on est enfin sur le chemin. J'encourage la facilité (et la paresse, qui est le moteur de l'informatique de qualité ;-)). Je n'approfondirais néanmoins pas plus mon point de vue dans ce commentaire, qui est suffisamment long, car c'est un autre sujet.
Pour ce qui est du site, je vais peut-être essayer. Voir si ça me suffit comme incitation ou si je suis encore plus désespéré que ça. (maintenant, tu flippes, hein ? ;-))
Pour un exemple concret : depuis que j'ai fait de l'assembleur, j'ai enfin arrêté de faire des segfault au bout de 100 lignes de C ! (et ma femme est revenue, et j'ai gagné au loto ;-))
Il y a plein de trucs qui sont « évidents » en assembleur, mais cachés dans les langages de plus haut niveau. Sauf quand on a un usage un peu pointu/astucieux/crade (suivant les goûts ;-)), auquel cas on a un bug incompréhensible, parce que, justement, le langage cache sa raison. Avoir fait de l'assembleur, ou au moins étudié la chose, nous donne au moins une chance de voir d'où vient le problème.
Après, connaître l'assembleur seulement, ça ne sert pas à grand chose (sauf pour l'étude de l'algorithmique, ce genre de choses, qui font que Knuth a écrit MMIX de cette manière). Il faut se pencher sur le fonctionnement de la machine elle même : l'alignement de la mémoire, son organisation, les registres qui se modifient tout seuls (sur les architectures pourries traditionnelles), Les accès mémoire directs, indirects, indirectement indirects (variable, pointeur, pointeur de pointeur…)… Le fonctionnement de la pile, l'interface avec les langages de plus haut niveau…
Ça ne m'a pas trop servit sur des langages de plus haut niveau encore, par contre… (Javascript, Python… Mouais, là, l'assembleur devient vraiment lointain).
Enfin, je ne sais pas pour les autres langages, mais pour le C, connaître les limitations de la machine sous-jacente est un vrai bonus, même si le C est censé être « abstrait ».
Mmmh… C'est pas évident de trouver des pages sur ce wiki /o\ (j'ai peut-être pas fait assez d'efforts, aussi :-°).
Dès que j'ai un peu de temps, je relis les derniers débats sur le sujet, et j'essaierais d'ajouter des détails sur cette page (un truc du genre « idées reçues souvent rencontrées »). Puis je modifierais la page principale du wiki pour ajouter un lien vers cette page, parce que… Elle y a sa place, non ? (au pire, comme c'est un wiki, vous annulerez mes changements…)
Bah s'il trifouille des routeurs et des Unix, on peut supposer qu'il va écrire sa doc dans un fichier texte, avec ed ou pire (vim, emacs), et être donc intéressé par la qualité de sa mise en page avec ce format. S'il utilise troff pour générer son fichier texte, ça va se voir, et c'est plutôt un bon point, non ? (il est capable d'écrire des pages de man)
C'est pas totalement vrai. J'ai eu des profs vraiment excellents en histoire géographie. J'ai compris avec eux que l'histoire pouvait être intéressante. Je me suis senti vraiment mal d'être aussi mauvais en histoire, parce qu'ils méritaient mieux. Mais je préfère quand même les maths. Si seule la qualité du professeur était en cause, et pas les intérêts « innés » des élèves, j'aurais récupéré mon retard, au moins un minimum. Depuis que j'ai quitté le système éducatif, j'ai continué à apprendre, mais beaucoup plus de maths ou de physique – et un peu de linguistique – que d'histoire. Dans mon cas au moins, la matière qui m'intéresse est une matière que je suis capable d'apprendre tout seul. Si un professeur est vraiment bon, mais que la matière n'est « pas pour moi », j'apprendrais un peu. Si un professeur est mauvais, je n'apprendrais pas du tout. Si la matière m'intéresse, je n'ai pas besoin de prof¹ (en fait, les mauvais profs m'ont même retardé…).
Après, je suis d'accord avec toi sur le fait de donner des cours qui n'ont pas un rapport direct avec le cursus de l'élève : même pour les matières que je n'ai pas aimé, j'ai toujours retenu au moins un minimum de chose. Ça donne les bases, et quand on a un besoin un peu compliqué sur le sujet, ça nous permet de savoir où commencer les recherches. Il ne faut pas forcément aménager un cours de droit régulier dans un cursus d'informaticiens, mais avoir quelques modules qui montrent rapidement mais pertinemment des choses que les élèves ne seraient pas allé chercher seuls (parce qu'ils s'en foutent, que ce n'est pas leur boulot, ou qu'ils n'y ont même jamais pensé), c'est un vrai bonus. Quelle que soit la matière, quelle que soit le cursus. Il est vraiment dommage de s'enfermer dans une « bulle culturelle » sous prétexte qu'on est pas là pour apprendre autre chose.
¹ Ça ne veut pas dire qu'un prof ne sert à rien, j'apprendrais plus vite avec un bon prof que tout seul…
Je cherchais une autre formulation à la phrase, qui garde le sens sans choquer les gens, pour voir, mais j'ai juste conclut par « oh, si c'était moi, je la virerais, elle n'apporte rien au journal ». C'est même plus pervers que ça, finalement : non seulement elle n'apporte rien au journal, mais son manque d'à propos fait qu'on se concentre plus sur ces quelques mots que les paragraphes entiers qui suivent.
Ton commentaire est d'ailleurs assez ironique (et le mien aussi) : tu ne parles pas non plus du sujet du journal, mais du hors-sujet !
Avec un peu de chance, le troisième commentaire de premier niveau sera enfin par rapport au contenu du journal ;-)
Je crois que ce n'est pas une question de fanboyisme. Moi aussi, sa formulation m'a choqué¹. Mais sa formulation, pas son avis. J'y ai ressenti un « mon dieu, ça a été si horrible, si long, je n'en pouvais plus ! ». Ce qui peut être le cas, hein ! Mais ça fait bizarre, et on ressent ça comme une attaque. Peut-être parce qu'on a beaucoup lu de « m'étant enfin débarrassé de Windows sur tout mes ordis », ou « ayant enfin remplacé tout les services Google que j'utilisais », et que souvent, ce choix est compréhensible et évident, parce qu'effectué dans un climat de débat vis à vis du « mal » dont on s'est débarrassé, les arguments étant tout frais dans la tête de l'auteur et des lecteurs (enfin, d'une grande partie d'entre eux, en tout cas).
D'ailleurs, cette phrase est souvent accompagnée d'arguments, parce que c'est le but du journal. Mais là, c'était pas le but du journal. Et je n'ai pas vu passer de grosse polémique sur Archlinux comme nouvel axe du mal. À la limite, on aurait parlé d'Ubuntu… Et encore, les grosses critiques avaient cours il y a quelque années, mais ça s'est vachement calmé… (archers, méfiez vous, vous êtes les nouveaux ubunteros !)
Pareil, si on évoque systemd, la phrase est beaucoup moins choquante. Qu'on aime systemd ou pas, et que la phrase soit « ayant enfin viré systemd » ou « ayant enfin viré SysV init », d'ailleurs. C'est juste qu'elle s'inscrit dans un contexte où le « enfin » est justifié, si ce n'est dans le journal, ailleurs.
¹ … choqué : mon dieu, totalement traumatisé en fait, je vais sûrement faire des cauchemars cette nuit ⸮
Il est binaire sur le libre parce qu'il a une définition précise pour le libre. Note, le libre, pas l'ouverture (open source ne compte pas comme ouvert, c'est considéré comme un synonyme de libre). Donc, quand il dit que ces normes ne sont pas libres, c'est qu'elles ne rentrent pas dans la définition du libre (« la », « sa », suivant vos goûts). Je suppose que ça lui ira si on dit « elles sont propriétaires » au lieu de dire « elles ne sont pas libres ». Mais le concept d'ouverture est dissociés du concept de liberté, même si on les trouve souvent ensemble. Certains projets sont libres, mais plutôt fermés (développement en interne, refus des contributions extérieures…). D'autres projets propriétaires sont plus ouverts (certains jeux, par exemple, sont très ouverts aux modifications, les encouragent, les aident, prennent en compte les suggestions des utilisateurs, voire distribuent leur code source sous une licence non libre).
Maintenant, s'il y a une définition claire et couramment acceptée de l'ouverture, avec des critères aussi précis que pour le libre, ça m'intéresse. On peut être binaire sur le libre parce que la définition permet cette dichotomie. La définition de l'ouverture n'est elle pas justement plus nuancée, si bien qu'il y a moins de personnes capables de dire « c'est ouvert, ou pas, mais il n'y a pas de “plus ou moins ouvert” ! » ?
La phrase de Zenitram marque d'ailleurs la présence de cette nuance, et il réagit (comme souvent) sur les mots utilisés. Il y a « un débat sur l'ouverture ou non des normes ISOs ». En présence de ce débat, utiliser le terme « sacrément fermé » est contestable. Si c'était le cas, il n'y aurait pas de débat, non ?
# TL;DR;
Posté par daeldir . En réponse au journal [Attention, journal bookmark ET féministe] Tiens, prends ça, tu le mérites !. Évalué à 10.
L'article est vraiment très long. Je ne l'ai pas non plus lu en entier, mais je l'ai survolé jusqu'au bout. Je ne sais pas à quel point le milieu décrit est différent d'autres milieux, notamment les autres milieux « masculins ». Dans la restauration, en cuisine, c'est pas facile non plus d'être une femme (c'est ironique, non ?).
C'est vrai qu'on a beaucoup de journaux sur le féminisme ces temps-ci, mais celui là ne mérite pas d'être moinssé comme il l'est déjà, ne serait-ce que parce qu'il est vraiment en rapport avec le libre (le sujet est abordé dans l'article) et l'informatique. Par contre, comme l'article est vraiment très long, un résumé des points forts de l'article aurait pu être sympa. Pour les gens comme moi qui auront manqué les points essentiels.
C'est vrai, pourquoi ceux qui ne sont pas capable de se concentrer plus d'une demi dépêche noyau devraient être exclus du débat ! Si ça c'est pas de la discrimination envers les hommes ! (il n'y a qu'un homme pour être bête au point de ne pas lire les long textes… :-°)
(Quand à mon expérience personnelle, je n'ai pas été beaucoup exposé au sexisme, parce que je suis un asocial. Mais les remarques sexistes que j'entend sortent aussi bien de la bouche des hommes que de celles des femmes. Na.)
[^] # Re: Notre communauté est malade ?
Posté par daeldir . En réponse au journal [Attention, journal bookmark ET féministe] Tiens, prends ça, tu le mérites !. Évalué à 9.
Après, il faut différencier les féministes. Il y en a qui se battent pour l'égalité des sexes, et il y en a qui se battent pour un inversement de la tendance.
Aussi, certaines féministes nient le rôle de la femme dans sa soumission. Pourtant, dans le modèle contre lequel elles se battent, ce sont les femmes qui éduquent les enfants… Qui deviennent sexistes.
Les responsables ne sont pas les hommes, ou les femmes, pas même certains hommes et certaines femmes. Ma mère est pour l'égalité des sexes. Elle a été choqué¹ quand ma sœur lui a dit un jour : « Pourquoi tu fais pas faire ce travail à mon frère ? À son âge, tu me le demandais déjà. ». Parce que même avec des idéaux assez égalitaires, la reproduction sociale s'exprime à un niveau inconscient.
Quand on reproche aux féministes d'être l'une des raisons du sexisme, on ne se réfère qu'à une partie de la population féministe, celle qui gueule fort et sans réfléchir. Comme quand on dit que les musulmans sont tous extrémistes, que les juifs essayent de supprimer la liberté d'expression, etc.
Du côté de la femme objet, les magazines féminins, écrit par des femmes, sont rarement d'un niveau plus élevé que les magazines pour homme : la femme aussi « consomme » de la femme objet.
¹ : Pas choquée par la remarque, choquée d'avoir agit de la sorte… (je précise, on sait jamais ;-))
[^] # Re: Dans Firefox
Posté par daeldir . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 1.
Ok. Mmmh… Moi, je me rappelle de Mac OS 7, Wikipédia me dit que c'est de ça que tu parles avec System 7 ^_^. Et je le préférais largement à Windows 98 (que je préférais à Windows 95).
La force de Windows 95 est donc d'être sorti à une époque ou la concurrence était soit morte (Amiga/Atari), soit trop chère (Mac OS, NextStep), soit pas encore sortie (Linux(?), BeOS).
Mais comme on parlait des qualités de Windows 95… À part être accessible aux petit portes monnaies, il avait vraiment un avantage sur ses concurrents, niveau qualité ?
Pas que je nie l'apport de Windows ou ta réaction de l'époque (ce serait osé), mais comme, dans le cas de Google, on parle d'un marché avec un très forte concurrence (à l'époque, il y avait Lycos, Google, Yahoo, les portails fournit par les FAIs…), je me demande si « tout le monde aurait voulu Windows » dans un cadre où il aurait été plus facile de le comparer à la concurrence (donc, avec une concurrence accessible, par exemple, s'ils avaient pu tester un certain temps les différents systèmes avant de choisir).
Parce qu'il a occupé le marché, ça ne veut pas dire que c'était un bon produit pour autant. Ça peut juste signifier un manque d'information ou de choix.
Après, même si je me demande si on peut dire qu'il a été « choisit », vu qu'il était quasiment seul sur le marché, je ne sais pas si on peut continuer à dire qu'il a été imposé (c'est le débat), à la lumière de la situation que tu nous décris. Maintenant, il est imposé (il y a qu'à voir tout les débats autour de Vista à l'époque, et Windows 8 maintenant). Mais en 95… Ça se discute, en effet (Mais choisit aussi, ça se discute. D'ailleurs, on en discute ;-))
Après, un point pour Microsoft : on râle sur la vente liée, mais à l'époque où Microsoft s'est imposé, les concurrents à Microsoft avaient la même pratique (Macintosh vendu avec Mac OS, Le NextCube avec NextStep, les BeBox avec BeOS…). L'arrivée des système libres a rendu cette pratique moins acceptable, mais avant ça, elle ne perturbait pas la concurrence (les pratiques douteuses mises à part).
[^] # Re: Dans Firefox
Posté par daeldir . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 4.
Windows s'est imposé par ses qualités ? Dans mon entourage, en 96 (oui, j'ai un an de retard), personne n'en voulait, c'était de la merde. Sur un échantillon de 10 personnes, on peu dire que 90% de la population n'en voulait pas ;-).
Nous, on avait un mac. Et on y est resté longtemps. Ma mère a quitté Mac uniquement pour un Linux que je lui ai installé et configuré aux petits oignons (et elle préférerait garder son Mac OS 9 si elle pouvait).
Bon, je suis jeune, j'ai un entourage d'intellectuels qui réfléchissent à leur achats, et qui avait un ordinateur pour des raisons professionnelles : payer un Mac au prix fort était plus intéressant qu'un Windows. De meilleurs logiciels, une meilleure interface… Sans compter qu'on les achève, nos ordis : Son iMac première génération est mort (moribond) il y a deux ans, et elle a utilisé son portable Macintosh il y a deux jour pour récupérer de très vieilles données. Le tout date d'avant 2002, puisqu'il tourne sur Mac OS 9.
Mais quand je lis des articles sur l'histoire de l'informatique (témoignages de grand programmeurs, articles Wikipédia, tout ça), ce que j'en retiens, c'est que Windows n'avait pas tant de qualités que ça (les blagues sur la stabilité de Windows, elle sont très vieilles, pourtant Mac aussi plantait, mais pas de manières aussi surprenantes). Si les gens ont eu des Windows, c'est parce qu'ils tournaient sur PC, et que les PCs, par rapport à la concurrence, c'était pas cher, et qu'on en trouvait partout (et les vendeurs essayaient de le caser même quand on demandait un mac…).
Quand à XP, il est meilleur que les Windows précédents (et suivants :-°), mais pas non plus bien meilleur que la concurrence. J'ai débuté Linux sur une Mandrake. Elle n'était pas pire que Windows, même mieux (le seul défaut dont je me souvienne, c'est OSS…). Il faudrait demander à ceux qui ont eu autre chose que Windows dans les mains – et pendant un moment –, avant de dire si Windows était supérieur. BeOS était si mauvais ? Amiga OS ? GeOS ?
Pour moi, l'hégémonie de Windows vient d'abord du prix du matériel sur lequel il tournait, puis du manque d'information des gens. Je n'ai jamais entendu quelqu'un venant d'un autre système d'exploitation dire « Windows est vachement mieux ! », même quand ils ont abandonné le système en question pour un Windows (Parce que le système est mort, parce que… Windows)
Je ne parle que d'expérience personnelle, parce que c'est tout ce que je vois. Mais entendre que Windows s'est imposé par ses qualités, ça me surprend, et je viens d'expliquer pourquoi. C'était une remarque sérieuse, ou juste balancé comme ça, sur des suppositions ? (C'est une vrai question, ça m'intéresse d'entendre quelqu'un qui à l'époque trouvait Windows meilleur que la concurrence…)
Quand à Google, je suis d'accord avec ceux qui disent qu'il a été choisit. J'ai souvent entendu des gens râler sur Windows « mais il y avait que ça ». Mais les premières réactions à Google ont été « Mais c'est génial ! ». À l'époque, il y avait même de la pub à la télé pour Lycos. Pourtant, c'est Google qui est sorti du lot. Pour parler de la vente liée, Google a réussit à la surmonter dans le domaine des mails (quasiment tout les FAI proposent une adresse mail, pourquoi j'ai tant de contacts en Gmail ?). Dans mon cas, comme pour beaucoup sûrement, Google s'est développé par le bouche à oreille (et ça vaut pour Gmail aussi). On est loin du fait qu'il était fournit de base sur la majorité des ordinateurs, dont les moins chers. Même intégré à Firefox : Google s'est imposé bien avant ça, à l'époque d'Internet Explorer 5 !
[^] # Re: Euh?
Posté par daeldir . En réponse au journal License open source. Évalué à 8.
Les mots ont un sens quand leur définition est partagée. Si je dis que j'aime les parapluies, quand ils sont assez sucrés, ma phrase n'a pas de sens, sauf si je précise avant que pour moi, un parapluie, c'est une espèce de gâteau. Si je dis à un ami que sa fille sera heureuse s'il lui offre un gros parapluie d'anniversaire, elle va être déçue et il va croire que je lui ai menti, alors que j'étais de bonne fois.
Et ce, jusqu'à ce que j'arrive à convaincre suffisamment de personnes qu'un parapluie, ça se mange et c'est bon. En attendant, le consensus est qu'un parapluie est un objet non comestible destiné à protéger de la pluie.
C'est un exemple assez extrême, mais il se trouve que tu donnes ta propre définition d'un mot, et que ta définition va à l'encontre du consensus. Quand Clownix veut obliger la redistribution à l'upstream, c'est sa définition du libre, et c'est une partie de la définition qui ne fait pas consensus. On peut en débattre jusqu'à ce que la majorité se mette d'accord sur le sujet.
Par contre, le fait qu'empêcher le commercial fait qu'une licence devient non libre, ça fait consensus. Pour Stallman, Torvalds, et De Raadt, mais aussi tout les gens derrière eux. C'est pas trois personnes. Je ne connais pas les effectifs, mais si on regroupe les acteurs de l'OSI et la FSF, ainsi que ceux qui les suivent et les acceptent comme autorités capable de définir ce qui est libre, qu'on rajoute ceux qui préfèrent considérer les DFSG comme vrai définition du libre, et qu'on ajoute encore les agnostiques qui sont tout de même totalement vendu aux quatre libertés comme définition du libre (et ces quatre libertés inclues l'utilisation commerciale), ça fait un paquet de monde. Je serais moins inflexible que Zenitram quand à dire que ta définition du libre n'est pas valable, mais il va te falloir mener un combat contre tout ces gens là pour amender leur définition du libre et faire valoir la tienne.
En attendant, quand je veux un parapluie, je demande un gâteau, ça m'évitera d'avoir faim parce que mon dictionnaire personnel n'est pas plus répandu. Tu as le droit d'avoir tes propres définitions, mais quand tu communiques avec les autres, il faut faire attention à t'accorder avec ton auditoire, si tu ne veux pas perdre toute crédibilité à ses yeux.
[^] # Re: RPL
Posté par daeldir . En réponse au journal License open source. Évalué à 3.
Oui, on peut aussi préciser que si B a vendu son code à C, tu peux contacter C en lui expliquant que B ne joue pas le jeu (mais reste poli, quoique tu en penses ;-)), que tu aimerais bien avoir accès aux modifications pour augmenter la qualité du service dont ils profitent, et que ça tombe bien, selon la GPL, ils ont le droit de te donner les modifications de B \o/
(Je précise que je n'ai pas assez d'expérience professionnelle à ce niveau pour décider si faire ça est une bonne ou mauvaise idée. Je vous laisse juge ;-))
[^] # Re: Euh?
Posté par daeldir . En réponse au journal License open source. Évalué à 1.
Il ne proscrit même pas l'utilisation commerciale. C'est juste que pour lui, l'utilisation commerciale doit s'accompagner d'un retour. Si il y a modification du code source et utilisation commerciale, la modification doit être remontée upstream.
Ça ne me semble pas incompatible avec « l'esprit » du libre (partagez, ne gardez pas tout pour vous !). Il y a même (de manière surprenante) une licence approuvée par la FSF qui permet de forcer cette distribution upstream (licence vim, mais là, je me répète :-°), ainsi qu'une licence OSI (la Reciprocal Public License). Manque de pot, la RPL n'est pas approuvée FSF, et la licence vim n'apparaît pas sur la page de l'OSI :-D
[^] # Re: RPL
Posté par daeldir . En réponse au journal License open source. Évalué à 3.
Dans ce cas, cette licence ne suffit pas encore :
C'est l'un des reproches faits par la FSF à cette licence : même pour un usage totalement interne, les modifications doivent être distribuées.
Ensuite, vis à vis du changement de licence, mais aussi du choix de la licence au début d'un projet, je te conseille de passer un peu plus de temps à lire et comprendre la licence choisie. Les licences de ce types son longues et ennuyeuses, pleines de références croisées, mais c'est le seul moyen que tu as de savoir si la licence te convient ou pas. Un résumé ne suffit pas (il suffit pour éliminer, pas pour confirmer). Si tu avais lu la GPL, tu aurais vu que cette protection manquait (mais tu n'y avais peut-être pas pensé à l'époque). De la même manière, tu verras peut-être des choses en trop dans cette licence (comme ce que je viens de pointer). Les trucs les plus « choquants » sont là. (et même si tu t'en fous de la FSF, ils ont prit la peine de faire un résumé très succinct de ce qui ne leur plait pas, ce qui t'évitera si l'une des trois critiques te semble valide d'avoir à lire toute la licence)
[^] # Re: RPL
Posté par daeldir . En réponse au journal License open source. Évalué à 1.
C'est malin…
(oui, j'ai noté le « ;-) », mais un peu tard, puis c'est tellement tentant…)
Ceci-dit, c'est une illustration de ce qu'on retrouve dans ce journal : le libre, c'est simple ou pas. Si on se retrouve à utiliser une licence approuvée seulement par un des trois organismes décidant du caractère libre ou non d'une licence, on est sur une pente glissante et exposé aux critiques. Ce n'est pas tant la diversité des licences qui porte préjudice au libre, que la diversité des « autorités » sur le sujet. Dans la définition du libre, il y a des points qui font vraiment consensus, et il y a des points qui font différentes licences et autorités.
Bon, se serait plus simple si une licence valide DFSG était automatiquement valide FSF, et une licence valide FSF automatiquement valide OSI… Mais même pas.
[^] # Re: RPL
Posté par daeldir . En réponse au journal License open source. Évalué à 7.
Il y a une différence entre la logique et la moindre des choses. Parfois, on choisit une licence en se disant que les utilisateurs vont jouer le jeu. Puis on se rend compte qu'ils se contentent du strict minimum. C'est même arrivé entre des auteurs BSD et des auteurs GPL (les premiers râlant sur le fait que les modifications soient en GPL (enfin, l'affaire était plus compliquée que ça, mais c'est ce qu'on en a retenu)).
Ça doit pas être agréable de se rendre compte qu'un c*****d a décidé d'utiliser les droits qu'on lui à donné de la manière la plus égoïste possible. Mais c'est vrai que ça veux dire qu'à un moment, on a commis une erreur (une erreur de jugement, je dirais).
Ta vision du libre est une vision altruiste, l'idée est de forcer la coopération. Mais la vision partagée du libre est une vision « préventive » : on ne veut pas forcer les gens à coopérer, mais on veut le leur permettre, et dans le cas du copyleft, empêcher la disparition de cette possibilité.
Il y a trois mots clefs : forcer, permettre, empêcher. Tu as été critiqué sur ton désir de forcer. Permettre pose rarement des problèmes, et empêcher est à utiliser avec modération.
Après, je dis ça en simplifiant les choses, et je me contredis déjà si on lit mes commentaires sur la licence vim (car il y a une part de forçage dans cette licence). De plus, on peut jouer sur les mots en disant « la GPL force la licence de nos modifications ». Ici, je n'argumente pas (parce que ce serait pauvre, comme argumentation), j'essaye de proposer un moyen de reconnaître le « bien » du « mal » (définissez ces mots comme vous voulez, dans ce contexte, ce serait « irréprochable »/« qui provoque des moqueries »)
J'aurais juste un conseil, avant que tu ne passes définitivement sur la RPL : si ton programme est empaqueté dans certaines distributions (en plus de la version que tu propose sur ton site), vérifie que ça ne compromette pas cette possibilité (vis à vis des DFSG, par exemple). Après, tu peux t'en foutre. Tu seras de toute façon critiqué sur la licence (c'est GPL, je préfère BSD – c'est approuvé que par l'OSI, je veux du FSF) ou ta vision du libre (parce que pas deux pensent pareil, malgré mes discours sur le « c'est simple », on voit que même des groupes de personnes comme la FSF et l'OSI n'arrivent pas à se mettre réellement d'accord).
Personnellement, j'aime bien les licences très permissives pour m'éviter ce genre de surprise : si j'utilise une WTFPL, une MIT ou ma LRL, c'est parce que je sais que les gens vont pouvoir en faire n'importe quoi, et qu'ils ont donc peut de chance de ne pas respecter les droits que je leur ai donné. Mais ça veut aussi dire que j'ai pleinement accepté les situations telles que celle que tu décris. Si un jour je suis surpris, ce sera plus de ne pas accepter ce qu'a permis la licence que l'utilisation elle même.
[^] # Re: RPL
Posté par daeldir . En réponse au journal License open source. Évalué à 2.
La clause rendant la licence compatible GPL n'annule pas ce devoir. C'est juste que l'auteur autorise une modification à être sous GPL. Dans ce cas, il a toujours le droit de demander les sources des modifications même sans être client.
La clause de compatibilité annule toutefois un morceau de la licence, celui qui dit que les modifications doivent être sous une licence permettant l'inclusion dans le code original. L'auteur ne peut pas inclure le code GPL sans passer tout vim en GPL.
C'est donc une exception envers (et seulement envers) la GPL. Un choix de l'auteur. Je ne sais pas ce que ça donne en pratique.
À noter aussi que la clause rend compatible GPL du côté de vim. La FSF a approuvé la licence vim, ce qui veut dire que, juste à cause de la clause de compatibilité, et manifestement sans retirer le devoir de redistribution à l'auteur original sur demande, la FSF à considéré cette licence comme valable. Conclusion : si on ajoute un devoir de distribution du code source à la demande, même à des non-clients, ce n'est apparemment pas incompatible GPL, et approuvé comme logiciel libre par la FSF.
Personnellement, je trouve cette licence compliquée. Quand je la lis, je me pose plein de questions sur comment vim évolue (est-ce qu'il accumule plein de licences en son sein, toutes compatibles avec la licence vim ?). Et comme je ne suis pas avocat, je ne prendrais pas le risque de tripoter cette licence (quoi, le copyleft n'est pas un virus ?). Mais bon, elle existe, elle est approuvée par la FSF, et elle possède un morceau de ce que l'auteur de ce journal désire, donc, je la pointe du doigt (oui, je sais, c'est pas poli).
[^] # Re: journal ?
Posté par daeldir . En réponse au journal License open source. Évalué à 3.
Bah je me suis posé la question au moment où j'éditais le wiki. Et il se trouve que vim possède cette restriction. Dans ce cas, l'auteur protège à la fois les utilisateurs, mais aussi lui même vis à vis d'un autre auteur.
Après, il n'y a pas encore le devoir de remonter upstream systématiquement, mais sur demande, même si l'upstream n'est pas client.
Pour ce qui est de se faire du fric sur le dos de l'auteur, ça, par contre, oui, c'est indissociable du libre ;-)
[^] # Re: RPL
Posté par daeldir . En réponse au journal License open source. Évalué à 1.
Il y a aussi la licence de vim, GPL compatible et approuvée par la FSF (pour l'OSI, j'ai pas trouvé, ça doit vouloir dire pas approuvée, haha !). Les restrictions citées ici ne s'appliquent pas à la licence de vim, mais c'est une licence copyleft (sauf négociation évidemment), et l'entité modifiant le programme doit fournir à l'auteur original les modifications (avec les droits d'utilisation qui vont bien) si celui-ci les demande.
[^] # Re: Programmation lettrée, des retours d'expérience ?
Posté par daeldir . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #10. Évalué à 4.
J'aurais tendance à dire que ce sont deux choses différentes :
Les commentaires en Python et dans la Javadoc ont tendance à décrire l'API. L'objectif est de pouvoir récupérer la documentation d'une bibliothèque à partir de son code source, d'une part, et d'avoir la documentation sous les yeux lors de la programmation de la bibliothèque, d'autre part, non pas pour comprendre le code qu'on écrit, mais pour faciliter la synchronisation entre le code et sa documentation. Mais l'objectif final est de décrire l'API (cette fonction fait ça, celle là fait ceci…).
L'orientation des commentaires de la programmation lettrée est plus destinée à celui qui va lire le code, qu'à celui qui va l'utiliser : on ne se contente pas de dire ce que fait la fonction, mais on explique pourquoi, comment, tout ce qui n'est pas évident. Si j'écris un parser, la documentation « javadoc » va expliquer comment utiliser mon parser (appeler telle fonction pour tel résultat), et la documentation « lettrée » va expliquer le fonctionnement interne du parseur (quel algorithme, quelles exceptions…).
Dans ce morceau de code :
Le commentaire
"""est l'équivalent de la javadoc, et les commentaires#sont l'équivalent de la programmation lettrée (quand à la pertinence des dit commentaires, essayez de trouver un meilleur exemple aussi court ;-)).Pour un exemple en français de ce à quoi peut ressembler un programme littéraire, j'ai écrit celui-ci il y a trois ans. (soyez gentils avec ma connexion, c'est auto-hébergé)
Bon, mon style a beaucoup évolué depuis (c'est fou ce qu'on peut changer vite). Les morceaux de code sont conséquents, tout n'est pas dit (entre autre, une revue rapide du mode de fonctionnement du programme n'aurait pas été de trop), certains commentaires ont été écrits par captain obvious, il y a des passages pas très formels (lire : il y a des grossièretés), il n'y a pas de licence. Comme j'ai la flemme d'aller reprendre ce code dont je ne me sert plus du tout (puis bon, c'est un jouet, donc niveau motivation, si je l'utilise pas…), ces problèmes vont rester. À moins qu'un fou désire jouer avec. Dans ce cas, je ne dirais rien, mais il vaux mieux qu'il m'en informe, histoire que je fasse au moins l'effort de spécifier une licence, puis que je lui donne la source s'il ne l'a pas trouvé tout seul.
[^] # Re: Programmation lettrée, des retours d'expérience ?
Posté par daeldir . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #10. Évalué à 1.
Justement, l'objectif de la programmation lettrée est de créer ce plan. Certes, de manière plus verbeuse qu'avec juste des schémas. Mais le programme se présentant comme un livre, il peut inclure des schémas.
J'avais commencé à écrire un programme assez conséquent (pas terminé, même s'il est juste en pause). La majeure partie de l'effort s'est retrouvée à penser, puis décrire l'architecture. Il y avait des schémas inclut.
Knuth est avant tout un mathématicien, et si le langage de l'ordinateur est celui des mathématiques, sa propositions est tout à fait pertinente : ce que j'ai lu qui ressemble le plus à de la programmation lettrée, c'est les travaux de mathématiciens décrivant des algorithmes (celui-ci par exemple).
En fait, j'ai l'impression que la programmation lettrée se rapproche plus de la conception logicielle « à l'ancienne », où on réfléchit, spécifie, etc. énormément avant la moindre ligne de code, et où les spécifications ne vont pas changer. Dans ce cas, on obtient un livre, qui décrit de bout en bout l'implémentation du programme, de manière précise, avec schéma… Ce livre traite à la fois de l'architecture du programme, des détails d'implémentation, des pièges à éviter… C'est à la fois la description du programme et un traité sur comment résoudre le problème auquel le programme répond.
La programmation lettrée me semble toutefois moins adaptée à des spécifications en continuelle évolution, comme on croise dans les méthodes agiles, programmation extrême, etc. (et quoi que vous pensiez des méthodes en question, le problème auquel elles veulent répondre existe et est inévitable dans certains domaines). Ces méthodologies étant très courantes de nos jours, et pertinentes dans les domaines pour lesquels je programme, j'aurais aimé savoir si quelqu'un avait réussit à les concilier à la programmation lettrée.
Je me pose d'autant plus cette question que je croise de plus en plus de propositions quant à cette pratique (comme cette nouvelle implémentation par CoffeeScript). La programmation lettrée « des origines » date d'une époque où les besoins d'un programme étaient fixée avant l'écriture, et avec l'avènement de la programmation extrême est entrée en hibernation. L'éveil/évolution de cette pratique dans un nouveau contexte peut signifier qu'un début de réponse se met en place, visant à concilier ces deux mondes.
Pour ma part, je suis passé à autre chose, influencé par Forth (dans ma recherche de la « méthode parfaite », l'approche de la programmation lettrée et l'approche de Forth sont les deux réponses qui m'ont le plus convaincues, bien que d'apparence totalement opposées). Je continuerais d'utiliser la programmation lettrée pour les problèmes « finit » (utilitaire shell, programme qui ne fait qu'une chose mais le fait bien), mais je n'essaye même plus pour les problèmes « créatifs » (site web, programme évolutif…).
Et je suis donc intéressé par l'avis de ceux qui ont pratiqué, ou pratiquent encore, la programmation lettrée dans le cadre instable devenu courant de nos jours.
# Programmation lettrée, des retours d'expérience ?
Posté par daeldir . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #10. Évalué à 6.
Depuis que j'ai découvert la programmation lettrée, j'ai beaucoup accroché avec le concept. J'ai même traduit l'article Wikipédia anglais en français, afin de pouvoir faire profiter mes amis anglophobes du concept.
J'ai écrit quelques programmes en utilisant des outils comme noweb, mais mon expérience est que cela mène à un code assez rigide :
Quand on écrit un programme assez conséquent, on écrit encore plus de documentation. La conception du programme ressemble dans mon cas à l'écriture d'un livre. On organise notre documentation (qui n'est pas comment utiliser le code, mais quel est le contexte du code, pourquoi il est là, quel est son but réel) comme un livre, en le découpant en chapitre, suivant les différentes tâches à accomplir et les différents modules.
Lors de la refactorisation, on n'a plus juste un petit morceau de code à déplacer, mais aussi toute une documentation à mettre à jour.
Dans le cas d'un code extrêmement factorisé, la documentation devient quasiment inutile (une fonction parle d'elle même), ou – pour un problème complexe – a une meilleure place dans un document annexe décrivant le problème. Au pire, cette documentation peut se trouver au début du code, comme préambule. Elle n'est pas destinée à changer (elle décrit le problème), et n'est plus mélangée au code (ce n'est donc pas de la programmation lettrée).
L'article de blog lié dans la dépêche pose la question de la programmation objet mixée à la programmation lettrée. J'ai remarqué dans ma manière de faire (et pour un programme écrit dès le départ en programmation lettrée, par contraste avec des codes déjà écrit et documentés/réorganisés après coup) que ce n'était pas très différent du fonctionnement headers/code que l'on trouve en C++. J'aurais par exemple une partie décrivant mon objet, puis plus loin la définition des méthodes (dans leur propres chapitres).
Malgré tout l'enthousiasme que j'éprouve envers cette pratique, j'ai la sensation qu'elle ne fonctionne que dans le cas de petits programmes. Mon expérience porte sur un environnement de développement plus « complet » que ceux proposés par Haskell, CoffeeScript et Docco, c'est à dire des environnements où l'on peut vraiment séparer et déplacer le code suivant notre propre logique (les possibilités de factorisation offertes par Haskell et Coffeescript diminuent le besoin de réorganisation, mais je ne factorisais pas autant à l'époque, et cette réorganisation me semble encore pertinente dans le cas de la programmation objet). Et je n'ai pas trouvé d'exemple de code vraiment conséquent et en perpétuelle évolution écrit en programmation lettrée.
Je parle de petits/gros programmes, mais mon véritable questionnement porte sur les programmes « jamais finit » : si le programme a une tâche à effectuer, et le fait bien, il n'a plus de raison d'évoluer. Dans ce cas, la programmation lettrée permet d'avoir un travail définitif et bien documenté. Mais pour les programmes plus « vivants » (par exemple, le code de LinuxFR n'a jamais arrêté d'évoluer), quelqu'un a t'il déjà utilisé avec succès cette méthode ?
# Critiques
Posté par daeldir . En réponse au journal Habitrpg. Évalué à 5.
Pourquoi les filles peuvent changer d'habit et pas les mecs ? Y en a marre de cette domination incessante des femelles sur les mâles au niveau vestimentaire ! (ça, c'est pour rester dans le ton des journaux de ces derniers jours ;-))
Bon, ça doit être dû aux graphismes de BrowserQuest, mais j'avais même pas vu qu'on pouvait personnaliser son avatar sur ce jeu, donc j'avais pas râlé ;-)
Plus sérieusement, il y a un « connectez vous avec Facebook ». Pourtant, il est de moins en moins rare qu'un internaute possède un autre fournisseur d'identité (Google, Twitter, pour ne citer que les plus proches de Facebook…). Un champ OpenID me semblerait plus pertinent, et ce, pour chaque site proposant une connexion Facebook (et OpenID, ça veut pas dire « connectez vous avec Google, Twitter ou Facebook », ça veut dire « connectez vous avec votre fournisseur d'identité, quel qu'il soit » – j'ai déjà vu des sites se limiter aux trois entités sus-citées, et je trouve pas ça mieux).
Je ne sais pas si tu participes au développement. Bah, j'irais jeter un œil sur leurs outils de communication (bug tracker, tout ça).
Et aussi, il y a pas indiqué ce qui se passe si on meure. Il doit bien y avoir une conséquence, sinon, ça a pas d'intérêt, et cette conséquence doit nous permettre de continuer à jouer, pour la même raison… Ŀà, je serais tenté de jouer et mourir juste pour voir.
[^] # Re: TodoList intéressante
Posté par daeldir . En réponse au journal Habitrpg. Évalué à 10.
Je vais répondre sur le premier point, parce que je me sens concerné par celui-ci.
Avant tout, je tiens à préciser que cela fait de nombreuses années que « je me pose des questions sur ma vie », donc je ne commencerais pas aujourd'hui ;-)
Ensuite, à mon niveau, je ne sais même pas si « ça » suffirait comme incitation pour réaliser ce que je veux faire. C'est un problème de volonté, c'est personnel, c'est en partie physique, mais « vouloir » quelque chose ne me suffit pas pour agir. D'autant plus quand c'est un objectif indirect (pour atteindre cet objectif, je ne dois pas juste travailler sur cet objectif, mais surtout sur des tâches annexes qui me débloqueront l'accès à cet objectif). Par contre, « devoir » faire quelque chose marche mieux. Les tâches ménagères, par exemple, j'arrive à les faire. Parce que je dois les faire, que je le veuille ou non.
L'intérêt d'un tel programme est que l'on peut transformer le « vouloir » en « devoir », ce qui a un effet direct sur la (ma) volonté. Il permet aussi (surtout ?) de nous motiver sur les tâches annexes qui vont débloquer notre objectif voulu.
Le « devoir » n'est pas fort (si je ne fais pas le ménage, ou que je ne paye pas mes factures, la conséquence est bien plus importante que si mon personnage meure dans ce jeu). Mais le simple fait que ça devienne un devoir, avec une conséquence, même moindre, en cas d'échec (alors que de base, il n'y a une conséquence qu'en cas de réussite) peut débloquer certaines personnes.
Si tout va bien dans ton « paysage psychiatrique » (cherchez pas, je viens de l'inventer), il peut être difficile de se projeter dans la tête d'un mec pas aussi sain d'esprit, et je comprend que ça te fasse flipper. Mais – et ce que je vais dire devrait s'appliquer aussi aux autres points de ton commentaire – utiliser un tel programme ne veut pas dire que c'est la seul chose qui compte.
Équilibrer les statistiques, pour rendre les points d'expérience et niveaux pertinents, est une tâche ardue ? Qu'importe, on n'est pas en évaluation, on est en progression : on se fiche de combien on avance, mais on a un marqueur qui nous montre qu'on avance. Ça vaut aussi pour ton quatrième point : l'objectif n'est pas les points, mais d'avancer. Les points ne peuvent pas vraiment faire office de mesure (car, comme tu l'as dit, il est difficile (impossible ?) d'en faire une mesure pertinente) mais ils sont un témoin de la progression. Et parfois, c'est bien de voir qu'on progresse, surtout sur des tâches où la progression est tout sauf évidente.
Pour ton commentaire sur le karma, je ne dirais rien, je suis plutôt d'accord : je ne contribuerais pas à Stack Overflow pour les médailles, je n'interviens pas ici pour le karma (Mais je le regarde, et j'aime bien avoir de bonnes notes. Pas que la note compte pour moi, mais j'essaye de rester pertinent, et voir que la communauté a approuvé mon commentaire me fait plaisir.)
Quand à ta conclusion, j'aurais tendance à dire que l'outil proposé permet de lutter contre la procrastination (si tu joue le jeu, tu « perd » quelque chose en procrastinant, tu n'y a donc pas intérêt), n'a pas d'effet sur la paresse (je vois pas trop en quoi ça peut la conforter ou la contrecarrer — avis purement subjectif), et en effet nous conforte dans la facilité (conforte, pas empire ;-)) : l'objectif est justement de faciliter la mise en mouvement. Mais se plaindre de la facilité, à mon sens, c'est se tromper d'objectif : c'est en essayant de rendre les choses faciles qu'on progresse : quand une chose est facile, on peut se concentrer sur une autre, plus compliquée, jusqu'à ce qu'elle devienne facile. Ce site facilite la mise en mouvement ? Ce n'est pas un mal, on n'a plus besoin de se concentrer sur le départ, on est enfin sur le chemin. J'encourage la facilité (et la paresse, qui est le moteur de l'informatique de qualité ;-)). Je n'approfondirais néanmoins pas plus mon point de vue dans ce commentaire, qui est suffisamment long, car c'est un autre sujet.
Pour ce qui est du site, je vais peut-être essayer. Voir si ça me suffit comme incitation ou si je suis encore plus désespéré que ça. (maintenant, tu flippes, hein ? ;-))
[^] # Re: Étudiant qui lève le doigt
Posté par daeldir . En réponse au journal Alpha: une machine bêta avec écran.. Évalué à 4.
Pour un exemple concret : depuis que j'ai fait de l'assembleur, j'ai enfin arrêté de faire des segfault au bout de 100 lignes de C ! (et ma femme est revenue, et j'ai gagné au loto ;-))
Il y a plein de trucs qui sont « évidents » en assembleur, mais cachés dans les langages de plus haut niveau. Sauf quand on a un usage un peu pointu/astucieux/crade (suivant les goûts ;-)), auquel cas on a un bug incompréhensible, parce que, justement, le langage cache sa raison. Avoir fait de l'assembleur, ou au moins étudié la chose, nous donne au moins une chance de voir d'où vient le problème.
Après, connaître l'assembleur seulement, ça ne sert pas à grand chose (sauf pour l'étude de l'algorithmique, ce genre de choses, qui font que Knuth a écrit MMIX de cette manière). Il faut se pencher sur le fonctionnement de la machine elle même : l'alignement de la mémoire, son organisation, les registres qui se modifient tout seuls (sur les architectures
pourriestraditionnelles), Les accès mémoire directs, indirects, indirectement indirects (variable, pointeur, pointeur de pointeur…)… Le fonctionnement de la pile, l'interface avec les langages de plus haut niveau…Ça ne m'a pas trop servit sur des langages de plus haut niveau encore, par contre… (Javascript, Python… Mouais, là, l'assembleur devient vraiment lointain).
Enfin, je ne sais pas pour les autres langages, mais pour le C, connaître les limitations de la machine sous-jacente est un vrai bonus, même si le C est censé être « abstrait ».
[^] # Re: Rien de nouveau
Posté par daeldir . En réponse au journal Vendre de l'open source illégal??. Évalué à 1.
Mmmh… C'est pas évident de trouver des pages sur ce wiki /o\ (j'ai peut-être pas fait assez d'efforts, aussi :-°).
Dès que j'ai un peu de temps, je relis les derniers débats sur le sujet, et j'essaierais d'ajouter des détails sur cette page (un truc du genre « idées reçues souvent rencontrées »). Puis je modifierais la page principale du wiki pour ajouter un lien vers cette page, parce que… Elle y a sa place, non ? (au pire, comme c'est un wiki, vous annulerez mes changements…)
[^] # Re: Mets donc ton LaTex chérie...
Posté par daeldir . En réponse au journal les SSLL et les annonces de recrutement (troll inside, vendredi c'est permis, etc). Évalué à 2.
Bah s'il trifouille des routeurs et des Unix, on peut supposer qu'il va écrire sa doc dans un fichier texte, avec ed ou pire (vim, emacs), et être donc intéressé par la qualité de sa mise en page avec ce format. S'il utilise troff pour générer son fichier texte, ça va se voir, et c'est plutôt un bon point, non ? (il est capable d'écrire des pages de man)
[^] # Re: Rien de nouveau
Posté par daeldir . En réponse au journal Vendre de l'open source illégal??. Évalué à 1.
C'est pas totalement vrai. J'ai eu des profs vraiment excellents en histoire géographie. J'ai compris avec eux que l'histoire pouvait être intéressante. Je me suis senti vraiment mal d'être aussi mauvais en histoire, parce qu'ils méritaient mieux. Mais je préfère quand même les maths. Si seule la qualité du professeur était en cause, et pas les intérêts « innés » des élèves, j'aurais récupéré mon retard, au moins un minimum. Depuis que j'ai quitté le système éducatif, j'ai continué à apprendre, mais beaucoup plus de maths ou de physique – et un peu de linguistique – que d'histoire. Dans mon cas au moins, la matière qui m'intéresse est une matière que je suis capable d'apprendre tout seul. Si un professeur est vraiment bon, mais que la matière n'est « pas pour moi », j'apprendrais un peu. Si un professeur est mauvais, je n'apprendrais pas du tout. Si la matière m'intéresse, je n'ai pas besoin de prof¹ (en fait, les mauvais profs m'ont même retardé…).
Après, je suis d'accord avec toi sur le fait de donner des cours qui n'ont pas un rapport direct avec le cursus de l'élève : même pour les matières que je n'ai pas aimé, j'ai toujours retenu au moins un minimum de chose. Ça donne les bases, et quand on a un besoin un peu compliqué sur le sujet, ça nous permet de savoir où commencer les recherches. Il ne faut pas forcément aménager un cours de droit régulier dans un cursus d'informaticiens, mais avoir quelques modules qui montrent rapidement mais pertinemment des choses que les élèves ne seraient pas allé chercher seuls (parce qu'ils s'en foutent, que ce n'est pas leur boulot, ou qu'ils n'y ont même jamais pensé), c'est un vrai bonus. Quelle que soit la matière, quelle que soit le cursus. Il est vraiment dommage de s'enfermer dans une « bulle culturelle » sous prétexte qu'on est pas là pour apprendre autre chose.
¹ Ça ne veut pas dire qu'un prof ne sert à rien, j'apprendrais plus vite avec un bon prof que tout seul…
[^] # Re: commentaires
Posté par daeldir . En réponse au journal x2go : le digne successeur de freenx. Évalué à 1.
Je cherchais une autre formulation à la phrase, qui garde le sens sans choquer les gens, pour voir, mais j'ai juste conclut par « oh, si c'était moi, je la virerais, elle n'apporte rien au journal ». C'est même plus pervers que ça, finalement : non seulement elle n'apporte rien au journal, mais son manque d'à propos fait qu'on se concentre plus sur ces quelques mots que les paragraphes entiers qui suivent.
Ton commentaire est d'ailleurs assez ironique (et le mien aussi) : tu ne parles pas non plus du sujet du journal, mais du hors-sujet !
Avec un peu de chance, le troisième commentaire de premier niveau sera enfin par rapport au contenu du journal ;-)
[^] # Re: Pourquoi ?
Posté par daeldir . En réponse au journal x2go : le digne successeur de freenx. Évalué à 10.
Je crois que ce n'est pas une question de fanboyisme. Moi aussi, sa formulation m'a choqué¹. Mais sa formulation, pas son avis. J'y ai ressenti un « mon dieu, ça a été si horrible, si long, je n'en pouvais plus ! ». Ce qui peut être le cas, hein ! Mais ça fait bizarre, et on ressent ça comme une attaque. Peut-être parce qu'on a beaucoup lu de « m'étant enfin débarrassé de Windows sur tout mes ordis », ou « ayant enfin remplacé tout les services Google que j'utilisais », et que souvent, ce choix est compréhensible et évident, parce qu'effectué dans un climat de débat vis à vis du « mal » dont on s'est débarrassé, les arguments étant tout frais dans la tête de l'auteur et des lecteurs (enfin, d'une grande partie d'entre eux, en tout cas).
D'ailleurs, cette phrase est souvent accompagnée d'arguments, parce que c'est le but du journal. Mais là, c'était pas le but du journal. Et je n'ai pas vu passer de grosse polémique sur Archlinux comme nouvel axe du mal. À la limite, on aurait parlé d'Ubuntu… Et encore, les grosses critiques avaient cours il y a quelque années, mais ça s'est vachement calmé… (archers, méfiez vous, vous êtes les nouveaux ubunteros !)
Pareil, si on évoque systemd, la phrase est beaucoup moins choquante. Qu'on aime systemd ou pas, et que la phrase soit « ayant enfin viré systemd » ou « ayant enfin viré SysV init », d'ailleurs. C'est juste qu'elle s'inscrit dans un contexte où le « enfin » est justifié, si ce n'est dans le journal, ailleurs.
¹ … choqué : mon dieu, totalement traumatisé en fait, je vais sûrement faire des cauchemars cette nuit ⸮
[^] # Re: Quand c'est ouvert, c'est fermé?
Posté par daeldir . En réponse au journal les SSLL et les annonces de recrutement (troll inside, vendredi c'est permis, etc). Évalué à 7.
Il est binaire sur le libre parce qu'il a une définition précise pour le libre. Note, le libre, pas l'ouverture (open source ne compte pas comme ouvert, c'est considéré comme un synonyme de libre). Donc, quand il dit que ces normes ne sont pas libres, c'est qu'elles ne rentrent pas dans la définition du libre (« la », « sa », suivant vos goûts). Je suppose que ça lui ira si on dit « elles sont propriétaires » au lieu de dire « elles ne sont pas libres ». Mais le concept d'ouverture est dissociés du concept de liberté, même si on les trouve souvent ensemble. Certains projets sont libres, mais plutôt fermés (développement en interne, refus des contributions extérieures…). D'autres projets propriétaires sont plus ouverts (certains jeux, par exemple, sont très ouverts aux modifications, les encouragent, les aident, prennent en compte les suggestions des utilisateurs, voire distribuent leur code source sous une licence non libre).
Maintenant, s'il y a une définition claire et couramment acceptée de l'ouverture, avec des critères aussi précis que pour le libre, ça m'intéresse. On peut être binaire sur le libre parce que la définition permet cette dichotomie. La définition de l'ouverture n'est elle pas justement plus nuancée, si bien qu'il y a moins de personnes capables de dire « c'est ouvert, ou pas, mais il n'y a pas de “plus ou moins ouvert” ! » ?
La phrase de Zenitram marque d'ailleurs la présence de cette nuance, et il réagit (comme souvent) sur les mots utilisés. Il y a « un débat sur l'ouverture ou non des normes ISOs ». En présence de ce débat, utiliser le terme « sacrément fermé » est contestable. Si c'était le cas, il n'y aurait pas de débat, non ?