anaseto a écrit 2229 commentaires

L'inconvénient c'est que c'est impossible d'avoir une disposition qui soit parfaite pour tous les usages, et du coup il faudrait apprendre plusieurs variantes du bépo suivant les cas (c'est sans doute possible, mais de quoi s'embrouiller quand même un peu, en tous cas moi j'aurais du mal). Par exemple, pour écrire de la prose les dispositions optimisées pour la programmation du wiki sont logiquement moins adaptées, et ça se sent encore plus si on veut écrire dans d'autres langues. Actuellement j'utilise bépo pour écrire en français, espagnol, espéranto et anglais, et le bépo standard marche globalement bien pour toutes ces langues (à part le « w » en anglais), et c'est difficile de faire des changements pour gagner d'un côté sans perdre trop ailleurs : en pratique je fais juste quelques remapages sur vim dans des cas spécifiques où je sais que telle touche ne me sert pas pour un certain type de document.

D'une part, j'ai entendu du bien de quelques gusses de ma connaissance qui développent le langage de mise en forme du futur, j'ai nommé Patoline.

Je connaissais pas et ça a l'air vachement bien de pouvoir insérer des macros en OCaml à coup d'un simple \Caml(...)! Je vais regarder ça plus en détail. Je me souviens avoir regretté aussi que LaTeX ne soit pas scriptable avec un langage plus sympa quand j'ai regardé il y a quelques temps BystroTeX qui permet de faire des slides avec des formules mathématiques en utilisant Scribble, le langage de documentation de Racket, qui est lui-même un dialecte de Racket (ça c'est la magie des dialectes de Scheme!), et j'avais trouvé sympa le fait d'utiliser le même langage pour des slides, de la doc ou du code.

D'ailleurs, j'ai vérifié, et en python tu peux aller de un à trois backslashes devant le « n » et c'est toujours interprété (dans les [] ou dehors peu importe), et il en faut quatre pour obtenir \ ou n (la raison de la différence c'est qu'en python les expressions régulières utilisent les chaînes de caractères courantes, comme dans la plupart des langages).

le \n ne semble pas vouloir être pris en compte dans la syntaxe avec les crochets.

Heu, si, peut-être pas en Java, mais en python et perl c'est interprété spécialement (à la différence près qu'en perl si on double le backslash [\\n] signifie backslash ou « n »).

je n'ai pas de traductions propres en tête pour "parser", "matcher", "lazy" et "greedy" dans un tel contexte :)

Dans l'ordre je crois : analyser, correspondre (il me semble avoir vu ça quelque part, mais je trouve ça bizarre), paresseux et glouton (en tous cas pour un algorithme glouton ça correspond bien). Mais bon, je n'ai pas l'impression que les deux premiers soient très courants.

Le coût estimé du réchauffement climatique est à mille lieu du coût d'une catastrophe type Tchernobyl.

Bon, déjà, je fais partie de ceux qui ne pensent pas que l'effet de serre anthropique soit une cause principale du changement climatique, mais bon, mettons ça de côté.

Fukushima n'est payé que par les japonais par exemple.

Qui te dis qu'aucun aliment contaminé ne puisse arriver dans ton assiette par exemple? Et même si ce n'était que les japonais, ça fait tout un pays bien peuplé quand même.

Sans compter les morts dus au thermique qui sont là aussi très nombreux, bien plus que les catastrophes nucléaires sur le même laps de temps.

Je trouve que dans le deuxième cas avoir des chiffres précis est plus difficile aussi. Et les centrales thermiques sont moins dangereuses aujourd'hui qu'avant, et peuvent être remplacées par des nouvelles plus facilement, ça ne veut pas dire que c'est parfait non plus.

Du plus, une autorité nationale autour du nucléaire est censé valider la sécurité des centrales. Donc on peut estimer que ces experts ont un point de vue plus intéressant que nous sur la question. Et si on ne leur fait pas confiance, pourquoi garder une telle institution ? Autant les virer si c'est pour ne pas tenir comptes de leurs avis, de leurs règles, etc.

Ben, justement, dans l'article que j'ai cité l'auteur affirme que souvent les inspections sont faites par des personnes n'ayant pas vraiment une connaissance du domaine (il cite même l'exemple d'un inspecteur agricole de récoltes de riz qui se retrouve à inspecter les centrales), et que les ouvriers dans les centrales ne sont pas toujours très compétents, ni conscients du danger auquel ils sont exposés, et qu'il y a un déphasage entre la théorie et la pratique. Alors, peut-être qu'en France c'est mieux, mais on parle quand même du Japon, pas d'un pays du tiers monde.

Et bon, pour ce qui est de faire confiance, quand il y a autant d'argent autour d'un problème, croire aveuglément une version comme une autre n'est pas possible.

Dans les classes [ ], le « . » perd sa signification spéciale, et signifie vraiment un point littéralement, du moins en perl, d'où ton problème je pense. Remarque, c'est logique car c'est rare que dans une classe entre crochets on veuille que ça matche plus que le « . » au sens spécial.

Donc, si j'ai bien compris, certains animaux semblent bien s'adapter à la radiation autour de Tchernobyl, et recevoir des faibles doses de radiation pendant longtemps agirait comme un vaccin, et en plus, comme il n'y a pas d'humains dans la zone les animaux sauvages sont plus tranquiles. C'est intéressant comme phénomène, toujours est-il que la zone reste contaminée, il faudrait voir si l'être humain fait partie des animaux qui réussirait à s'adapter, sachant qu'avant ça il y en aurait pas mal qui y resteraient. Et dans l'hypothèse optimiste suivant laquelle on n'aura pas partout des catastrophes, j'imagine que personne ne voudra se « vacciner » au cas où.

Bon, je ne pense pas que le nucléaire détruise toute vie sur terre non plus, mais de là à le trouver inoffensif (du moins par rapport à d'autres énergies), il y a un pas. Après la catastrophe de Fukushima, les japonais avaient bien arrêté toutes les centrales (et presque toutes le sont encore), donc vu ce que ça a dû leur coûter on peut imaginer qu'ils y ont vu un vrai danger. Un tel phénomène généralisé ne s'est jamais produit avec une autre énergie, ou bien je demande à voir. Et l'enérgie nucléaire est la seule qui échappe à ce point au contrôle humain quand il y a une catastrophe, on peut vivre ou non avec ça, mais on peut difficilement le nier.

Il y a un témoignage que j'ai aimé sur le travail effectif sur les centrales d'un japonais qui a travaillé toute sa vie dans les centrales, et explique tous les « à peu près » qui s'y font, le manque de compétence autour d'une centrale, etc… et c'est intéressant que cet article date déjà de 1997, donc bien avant la catastrophe de Fukushima.

Un passage que j'ai trouvé particulièrement effrayant, explique comment ils avaient dû s'y prendre à trente personnes pour tourner de quelques tours une vis située à un endroit sensible près du réacteur : ils couraient, tournaient un peu la vice, puis revenaient en courant, chacun à son tour. Le tout pour un coût de 4 millions de yens pour une seule vis. On dirait juste un film de science fiction.

Pour les mailing list, je suis abonné à quelques unes et participe parfois. Et aussi, de temps en temps des gens de la classe ou des profs en l'absence de mailing list appropriée envoient des mails aux quarante personnes de la promo dont moi em mettant les gens en CC (j'ai découvert d'ailleurs que toutes nos adresses ont été mises en plein dans une page html sans la moindre offuscation et sans prévenir). Je suis donc étonné de ne pas recevoir du spam plus souvent, mais bon, tant mieux ;)

Quand on regarde le nucléaire civil, en plus de 40 ans, on a eu deux accidents majeurs dont les conséquences restent limités (quelques kilomètres à la ronde avec un environnement sévèrement contaminé, quelques milliers de morts directs éventuels et d'autres milliers blessés de manière plus sensible).

Tu oublies quand même des détails : la zone restera contaminée pour toujours à notre échelle de temps contrairement à d'autres technologies, tu oublies ce qui part dans l'océan (c'est vrai il est grand…), tu oublies aussi les produits alimentaires produits dans la zone qui se vendent quand même, la façon qu'ont les gouvernements de changer les limites de doses acceptables dans les aliments ou autre quand ça les arrange, les effets sur les gens travaillant dans les centrales, le coût de démantèlemet d'une centrale, ce qu'on fait des déchets, le fait que les accidents sont impossibles à contrôler et reprendre en main (Fukushima n'est pas vraiment mieux contrôlée qu'après la catastrophe, et ça fait un moment déjà) etc…

Et surtout je ne me risquerais pas à être aussi sûr que toi de tes chiffres tranquilisants sur un sujet aussi sensible politiquement.

Sinon, tu oublies que le nucléaire est une technologie dont seuls disposent quelques pays, qui en dehors de ces pays est rarement la source principale d'électricité (et ne parlons pas des autres consommations d'énergie comme les transports, qui sont de loin plus importantes), le nucléaire n'étant pas du coup vraiment une solution à échelle globale (du moins en l'état actuel des choses), en plus de permettre de créer des dépendances vis-à-vis des pays disposant de la technologie, dépendance qui ne se justifie peut-être pas pour quelque chose d'aussi basique que l'énergie.

La position rationnelle par défaut est de ne pas s'opposer à une techno tant qu'on n'a pas d'indice fiable qu'elle est dangereuse.

Par exemple, quand j'achète de la nourriture, je choisis souvent les produits « bio », ou dont la liste d'ingrédients semble plus petite, quand j'ai à choisir entre deux produits similaires, alors que je ne connais pas exactement ce que signifie les différents labels bio, et n'ai aucun grief contre les ingrédients que j'estime être en trop (et je n'ai pas envie d'en chercher), à savoir les différents arômes, conservateurs, ingrédients que je ne connais pas etc, j'utilise juste mon pifomètre probabiliste qui me dit de minimiser le nombre d'ingrédients et/ou préférer « bio » quand j'hésite entre deux produits. C'est une conduite qui est loin de mériter un preuve formelle, mais est-elle vraiment absurde ?

Ou pour les OGMs : je n'ai aucune idée s'ils peuvent avoir ou non un impact sur la santé et je suis pour la recherche dans le domaine a priori, et pourtant je ne suis pas particulièrement favorable à leur utilisation. Pourquoi? Parce que je n'aime pas la machinerie des brevets derrière, et n'ai pas l'impression qu'ils apportent un avantage significatif par rapport à l'agriculture traditionnelle qui justifierait cette machinerie.

Ce que je veux dire, c'est qu'il n'y a pas besoin qu'une technologie soit effectivement dangereuse pour qu'on n'y soit pas favorable : encore faut-il qu'elle soit vraiment utile et que son utilisation ne donne pas lieu à d'autres dérives, qu'il n'existe pas une autre technologie qui fait la même chose ou mieux en plus prouvé, etc… Il n'y a pas toujours besoin d'être un scientifique spécialisé d'un domaine en particulier pour réfléchir un peu sur le bien-fondé d'une technologie.

Mais personnellement j'aime bien utiliser Street View pour voir comment c'est et avoir plus de repère visuel par exemple (je tourne à droite après le feux…).

Oui, je ne pensais pas à ce genre de choses. Aussi, je n'ai pas de voiture donc ce type de problème ne m'est jamais survenu, ni pour la recherche d'itinéraire vu qu'à pied ou en transport public c'est pas très utile. Donc oui, « la plupart des besoins » était sans doute exagéré et subjectif, je n'utilisais sans doute qu'une infime partie de ce que fait Google Maps donc j'ai rien senti en passant à OSM, à part que ça faisait juste ce que je voulais en plus simple et avec moins de trucs à permettre sur NoScript et RequestPolicy.

Donc oui, c'était subjectif, mais bon, il y a peut-être un nombre non négligeable de gens avec des besoins cartographiques pas trop poussés comme moi pour qui OSM est juste ce qu'il faut.

Il y a aussi la question de la stabilité : si tu es identifié uniquement mais que tu actualises ou changes souvent ton navigateur ou tes plugins ça devient moins utile, donc c'est pas évident à quel point c'est pertinent d'utiliser ces infos pour identifier les gens : plus on retient d'infos, plus on a de chances d'identifier uniquement, mais aussi plus on a de chances que ce soit très temporaire. D'ailleurs il y a des chercheurs français qui (paradoxalement) collectent des infos des gens qui veulent bien utiliser l'extension StopFingerprinting pour faire des stats sur la stabilité des différentes infos qui servent à tracker.

En fait je crois pas, vu l'effet des vaines tentatives d'effaçage du prof, qui avait juste réussit à étaler un pâté aux couleurs improbables sur un bon quart de tableau, avant de décider qu'il ferait son cours avec les trois quarts restants (du coup on était assez vite passé en mode exercice si je me souviens bien).

Bah, avec un stylo bille c'est passable,

s/Bah/Oui/

J'avais pas bien lu le titre du message, et entre le clavier et le stylo bille il y en a un qui est passé à la trappe :)

Wikipédia propose feutre effaçable, ça me semble un peu léger.

Surtout que je me souviens d'un tableau où ce n'était vraiment plus effaçable et le prof avait du faire tout le cours sans pouvoir effacer ;)

(quelqu'un avait du le laver avec un produit pas adapté sans doute)

Bah, avec un stylo bille c'est passable, c'était à la primaire que c'était horrible quand on m'obligeait à écrire avec des plumes et un effaceur.

L'idée de me priver de leur moteur de recherche, de gmail, et de Google Maps me gonfle vraiment.

OpenStreetMaps marche très bien pour la plupart des besoins (et c'est même plus rapide et fluide je trouve). Et le moteur de recherche c'est juste une habitude : il suffit de réfléchir à d'autres moyens d'accéder à une info (ça peut être passer par wikipédia, un autre site qu'on connait déjà, etc…), et souvent on arrive avant à ce qu'on veut. Typiquement, j'utilise le moteur de recherche juste quelques fois par semaine, ce n'est pas vraiment un dépendance si indispensable, et quand on en a besoin, un moteur médiocre fait souvent l'affaire (je ne me souviens pas de quand date ma dernière utilisation de la recherche de Google, mais ça doit faire un moment).

Par exemple, gmail offre un accès pop/imap, un espace disque quasiment illimité, deux interfaces (une en HTML simplifié et l'autre en JS), un filtre à spams très efficace, un moteur de recherche dans la boite diablement rapide et efficace, etc.

Pour l'interface et la recherche un logiciel comme mutt c'est quand même plus complet : tu peux faire des recherches arbitrairement compliquées avec un langage de recherche très complet, tu peux personnaliser l'interface avec tous les raccourcis qui te viennent à l'esprit, et surtout tu peux faire des trucs vachement chouettes avec les couleurs (un peu comme la coloration syntaxique sous vim ou emacs avec des regexps), ce qui n'est pas primordial mais rend la tâche de s'occuper de ses mails plus joyeuse quand même. Tu as l'avantage aussi que tu peux aussi rechercher dans tes mails dans ta machine si tu les gardes aussi dessus, sans besoin d'internet.

Et dans tous les cas, utilisant webmail ou autre, tu as quand même la solution de passer par un autre fournisseur d'adresse mail comme un membre de la ffdn, et si tu as des idées pour améliorer le service tout le monde en sera enchanté :)

Pour le filtre à spam je suis un peu curieux, parce que franchement, j'en ai jamais eu suffisamment pour sentir le besoin d'un filtre (genre un spam par semaine sur l'ensemble de mes adresses, et jamais encore sur celles de mon serveur depuis un an et demi).

J'aimerai tant pouvoir activer JS via une case à cocher de la barre de statut… là ce serait le summum du confort pour moi

C'est pas un peu le principe de NoScript? Ou alors je ne sais pas ce que tu entends par barre de statut… (ce qui est possible vu que j'utilise celle de pentadactyl)

D'ailleurs c'est possible que j'ai pas bien compris parce que :

Et puis, en désactivant JS et les plugin par défaut (que j'active sur un site si j'en ai besoin et que je trouve le site intéressant)

donc je suppose que tu utilises NoScript, à moins que tu ne fasses que des activations et désactivations globales de javascript à chaque fois?

Langage trop complexe et trop puissant pour 80%-90% des développeurs : Notion d'ordre supérieur, de pattern matching, de type somme, c'est beaucoup plus compliqué que les notions de if/then/else, d'accès à un tableau, et même d'objet comme sac de donnés et de fonction.

Ça dépend aussi du parcours suivi : OCaml est le premier langage que j'ai appris, du coup je me rappelle qu'après au début les langages impératifs me faisaient un effet bizarre, j'étais surpris de pouvoir sortir d'une boucle avec un break, ou de pouvoir retourner un valeur de n'importe où dans une fonction.

OCaml a des fonctionnalités un peu complexes autour du système de types, mais c'est assez simple et carré, et une fois les bases acquises (ça prend un peu de temps), on apprend vite à à connaître globalement bien le langage (un peu comme Scheme et ses dialectes) à part juste quelques trucs spéciaux, contrairement à d'autres langages comme Perl (ou C++, et je dirais même Rust peut-être), où on arrive vite à faire des choses sans beaucoup d'apprentissage, mais on continue à être surpris de temps en temps pendant longtemps. Après il y a les langages comme Haskell qui requièrent un bon temps d'apprentissage avant d'être fonctionnel, et en plus on est toujours loin de tout savoir :)

En perl, les parenthèses qui ne servent pas, je ne les mets pas ;-)

Je m'en rappellerai :-)

D'un autre côté, une phrase qui revient souvent chez les perlistes est : « ce n'est pas parce que tu peux faire une chose, que tu dois le faire » :)

Si tu veux passer moment rigolo sur ce genre de détails : man perlstyle. Et si tu te sens carrément d'humeur maniaque tu peux aussi regarder du côté de perlcritic (qui est très bien une fois qu'on le configure à son goût).

Edit : pour les fans d'analyse statique, perlcritic c'est de l'analyse statique à la Perl assez terrible :)

Je vais peut-être dire une grosse bêtise (je sais pas comment marche jpeg), mais peut-être que tout simplement les différentes opérations ne sont pas réversibles à cause des transformations des algos de compression/décompression, ce qui expliquerait la petite différence à la fin.

est préférable de spécifier que l'on souhaite ouvrir en mode lecture seule.

Oui, mais rien et '<' c'est la même chose il me semble. Mais c'est vrai que normalment on spécifie, ce qui a l'avantage d'être plus clair en tous cas.

Généralement, on fait un "open() or die…"

ou bien un

use autodie;

quand le message d'erreur importe peu.

P.S. : C'est mon premier script perl \o/

Pas mal pour un premier script :) Le seul truc qui est plus trop à la mode c'est les open avec des variables non lexicales. Avec à la place de FILE un my $file :

open(my $file, "path/to/file");

tu as l'avantage que quand tu n'est plus dans la portée de la déclaration de $file le close se fait automatiquement (ça veut pas dire que c'est une bonne habitude d'utiliser ça), et aussi de manière générale tu as tous les avantages d'une variable lexicale par rapport à une globale.