arnaudus a écrit 4595 commentaires

D'après ce que j'ai compris en lisant la presse en ligne, ce n'est pas l'activité Bitcoin qui est en cause, c'est juste qu'il s'agit d'une sorte d'escroquerie qui utilisait entre autres des Bt.

OK, donc les Bitcoins peuvent servir à des activités illégales? Super. Bientôt, on va s'apercevoir que Tor héberge des activités criminelles. Ouhlala!

Personnellement, je n'arrive pas à comprendre comment on peut avoir peur du contrôle des États au point de vanter les mérites de systèmes qui permettent à n'importe qui (y compris à des gens pas très recommandables) d'échapper, justement, au contrôle des États. Il y a probablement 1000 pédophiles pour un opposant chinois sur Tor. En ce qui concerne les Bitcoins, c'est peut-être moins tranché, mais il y a certainement une très grosse majorité des gens qui ne sont pas réellement utilisateur (qui utilisent les Bt simplement comme un support de spéculation). Franchement, vu l'évolution des taux de change du Bt, qui s'amuserait à effectuer des payements en Bt? Il faut être complètement dingue ; avoir un portefeuille de Bt offre la possibilité de multiplier sa valeur par 1000 en quelques années, il faut être profondément c*** pour acheter des oeufs ou des DVD avec! J'imagine que la plupart des transactions (en volume) sont donc motivées par l'absence de traçabilité. Et il ne doit pas avoir beaucoup d'activités légales qui justifient de devoir perdre des possibilités de spéculation aussi gigantesques…

En tout cas, si les Bt saisis par la justice sont systématiquement détruits, il va bientôt falloir compter en nanoBt, parce qu'il ne va plus y avoir beaucoup de Bt sur le marché!

Il est d'ailleurs d'autant plus regrettable que d'après l'article, la loi va être totalement abrogée, alors qu'elle partait d'une bonne intention. Sa mise en place a juste été débile. Il aurait suffi d'un portail Internet auquel on s'identifiait (avec par exemple un numéro de sécu) pour juguler le problème : non seulement on pourrait facilement repérer les comptes dont l'activité n'a rien à voir avec une demande légitime (et donc saisir un juge pour "abus de droit" ou équivalent), mais en plus on aurait pu mettre en place des bases de connaissance accessibles aux citoyens, ce qui aurait évité de devoir répondre plusieurs fois aux mêmes questions. Par exemple, pour l'histoire des caméras de vidéosurveillance, si on entre une fois les coordonnées GPS dans le système, on n'a plus à répondre aux questions.

Les pays du Nord passent souvent pour des pragmatiques, mais il semble que les députés néerlandais ont vraiment ruiné une bonne idée avec leur truc. L'article explique même que certaines demandes étaient cachées (par exemple, dans un devis ou une candidature spontannée), ce qui suppose qu'il n'y avait même pas besoin de remplir un formulaire spécifique! C'est profondément crétin ; s'il peut y avoir un dédommagement financier, on peut s'attendre à avoir un minimum de procédures à respecter!

C'est pas R le langage ou le runtime qui est rapide, ce sont les libs d'algèbre linéaire qu'il y a dessous (et je prends le pari que c'est du C).

Comme tous les langages, R a une bibliothèque standard—qu'elle soit implémentée en C, en Fortran, en assembleur, ou en javascript ne change pas.

L'objectif n'est pas de comparer des trucs sur une base idéologique, c'est de déterminer en pratique si un langage est adapté au développement de telle ou telle application. Seule une minorité d'applications ont un temps d'exécution critique : pour un uptime de 9 jours sur mon PC de bureau, seules 19 applications (sur 267) ont pris plus de 30 s de temps CPU (soit 0.13s par heure!). Et je suis certain que pour toutes ces applications, seuls quelques % du code sont réellement concernés. Seule une fraction de pourcent des millions de lignes de code que j'utilise au quotidien sur ma machine mérite d'être rapide, le reste pourait être codé en visual Basic que je ne verrais pas la différence.

Je maintiens donc que C est très largement sur-utilisé. C'est un outil très technique, indispensable dans certains domaines, mais son utilisation systématique par le commun des développeur n'est pas justifié. Évidemment, s'ils tombent systématiquement sur des gens qui leur disent que C est une sorte de graal qui tend vers l'optimalité, ou qu'on n'est pas un vrai développeur si on ne code pas en C, on ne va pas sortir de cette situation.

Je sais bien, mais c'est le benchmark initial qui était complètement stupide, je n'ai fait que suivre les instructions! (calculer 500 fois la somme des 1/n² pour n = 1 à 10000).

Du coup, un bon compilo s'apercevrait qu'on ne fait rien, je pense, et le test concerne tout autant le langage que le compilateur.

Le code initial en R incluait une double boucle, comme si c'était du C. Du coup, R mettait 3h à faire ce calcul stupide, ce qui n'est pas étonnant. Ce que j'ai essayé de montrer, c'est que ça n'était pas de la faute de R, mais du programmeur. Codé correctement, cet algo stupide est tout aussi rapide que du C.

Après, il existe forcément des algorithmes pour lesquels R est beaucoup plus lent que C. C'est évident, c'est un langage interprété. Mais il existe aussi de nombreux cas où en pratique R sera plus rapide que le code C, parce qu'il appelle des routines optimisées. Je ne connais pas les rouages internes de R, mais il est très efficace pour les opérations vectorisées (apply, lapply, sapply, etc), et ça ne m'étonnerait pas qu'il implémente des optimisations de bas niveau pour ça. Il est aussi diaboliquement bon pour des casse-têtes algorithmiques (par exemple tirer au hasard des éléments d'un vecteur avec ou sans remise avec pondération, avec une vitesse que je n'ai jamais réussi à approximer en C++).

Encore une fois, les langages sont tous Turing compplets, on peut tout faire avec n'importe quoi. Mais il est malsain de penser que de tout coder en C montre qu'on est un programmeur balèze. Ça montre juste qu'on est un programmeur qui ne connait que le C :)

C'est vrai, mais typiquement ton exemple en R est illisible.

Sérieux, tu n'arrives pas à lire quelque chose comme:

replicate(500, sum(1/((1:10000)^2))?

Là c'est vraiment une question d'habitude, pour moi c'est vraiment limpide. Il y a des trucs en R qui sont vraiment illisibles (notamment à cause de l'accumulation de parenthèses), mais je parse très bien cette ligne.

Il y a de grande chance que ton compilateur ai détecté que tu demandes 500x la même chose et ne le fasse pas.

Il n'est pas si malin que ça. Si on remplace 500 par 500000, ça prend 0.45 sec. Le vrai temps est donc autour de 0.004s, certainement trop court pour être mesuré efficacement avec system.time.

l'investissement dans la chaîne de production ne se rentabilise pas sur la première vente mais s'étale sur plusieurs années.

Hors matières premières? C'est clair qu'il est impossible de prendre en compte les charges et les investissements dans le calcul, mais un assembleur qui achète des carte-mères à 50€, des proc à 50€, et des boitiers à 20€, a-t-il le droit de vendre les PC assemblés à 100€ hors des périodes de solde?

Il ne faut pas exagérer, il y a souvent un facteur 10 entre un script et un langage compilé.

C'est loin d'être vrai. Il suffit de comparer des opérations comparables (cf un de mes anciens commentaires sur un benchmark où R se gamellait, et où j'avais réussi en codant selon les paradigmes du langage à réduire le temps d'exécution de 7 secondes à 0.00 (sic) seconde : http://linuxfr.org/news/version-1-0-de-julia#comment-1327186).

C'est clair, si tu implémentes un algo de tri en perl, il va être 10 fois moins rapide qu'en C. Mais ce n'est pas comme ça qu'on fait un tri en perl, c'est tout.

Toutafé. En bio-informatique par exemple, il est très courant d'employer des langages interprétés (principalement R et python) même pour les algorithmes critiques. Évidemment, c'est en partie attribuable au fait que les gens ne sont pas nécessairement développeurs de profession et que ces langages sont plus accessibles, mais c'est aussi lié au fait que (contrairement à ce qu'on peut souvent entendre), ces langages ne sont pas si lents que ça en pratique, car la très très grande majorité des algorithmes consiste à assembler des briques déja optimisées : du tri, des expressions régulières, des sommes, des opérations sur des matrices, etc. Si on ajoute la compilation just-in-time et la parallelisation relativement accessible, on se situe dans des domaines de performance qui sont du même ordre de grandeur que les langages compilés traditionnels, pour un temps de développement très inférieur.

Qu'est-ce qui te permet de juger qu'ils ne devraient pas être en C ? Tu es sans doute un des rares à pouvoir choisir au début d'un développement qu'elle sera la complexité du logiciel au final

Le meilleur langage est celui que tu connais, mais il y a des limites.

Les exemples auxquels je pense, c'est par exemple des applis essentiellement basées sur des GUI. Imagine par exemple un truc qui édite des fichiers de config. Tu crées un clicodrome, il n'y a pas de calcul ou d'algorithme particulier. Dans ce cas, tu te vois gérer la mémoire, détuire les pointeurs vers les widgets au fur et à mesure de leur fermeture, etc? Tu n'as aucune contrainte de temps d'exécution, 99% du temps cpu va être consacré à l'affichage des éléments qui sont appelés par une bibliothèque (qui elle pourra être en C).

Un autre exemple (celui auquel je pensais, en fait) sont tous ces jeux de stratégie, type implémentation de jeux de plateaux ou jeux de rôle. Au niveau algo et calcul, il y a que dalle, c'est juste de l'interface autour d'un moteur de jeu. J'ai contribué parfois à ces trucs, en plus, souvent, c'est "Dédé apprend à programmer", c'est plein de segfaults et de pointeurs tout nus qui se balladent partout, les tableaux sont initialisés avec des dimensions constantes (souvent plusieurs millions de cases, hein, faut voir grand), etc.

De toute façon, la langage ne fait pas l'optimisation. C'est l'algorithme qui fait ça.

Justement, raison de plus pour ne pas s'emm* avec ces langages proches de la machine, qui n'ont d'utilité réelle que dans une minorité de cas. Et surtout si on n'est pas développeur de formation et de profession. Personnellement, je vois C comme un outil spécialisé, pour des développeurs système ou embarqué, ou réservés à des cas très particuliers. Pour coder un truc avec une GUI et trois algos triviaux, il me parait beaucoup plus censé de démarrer sur un langage de script (python? ruby?) plutôt que de se demander si on ne va pas avoir un jour besoin de faire de la logique bitwise.

L'approche de plus en plus désincarnée des langages abstraits a beau essayer de cacher ce qui a sous le capot, au final ça marche pourtant comme ça

Oui, mais c'est ce qui s'appelle l'"abstraction". La question centrale est celle des contraintes du langage, est-ce qu'un langage doit représenter la manière dont la machine fonctionne, ou est-ce que le langage doit fournir des outils pour implémenter formellement ce que le programmeur pense? Bon, en plus, tout ça est proche de la machine, il faut avoir en tête les différences entre les architectures, ça me parait être une complexité dingue pour une histoire de trois nombres entre 0 et 255.

D'une manière plus spécifique, oui, il me paraitrait évident de manipuler du bit de couleur dans Gimp. Dans un émulateur de terminal, je ne vois pas. La manière "correcte" de traiter les couleurs dans ce contexte est, à mon avis, de créer un objet qui contient trois variables de la bonne taille, avec une méthode d'import (qui elle peut éventuellement tripoter les bits—ce n'est pas sale), et des méthodes d'export. Si un émulateur de terminal passe plus de 0.01% de son temps à jouer avec les couleurs, c'est certainement qu'il y a un problème dans l'émulateur, et pas dans l'optimisation de la fonction qui gère les couleurs.

Et comment tu fais pour extraire certains bits de la valeur que tu reçois, dans un autre langage ???

Tu fais pas :-) Dans un langage évolué, tu structures tes variables de manière à ce que leur sémantique ne soit pas cryptique :-)

Peut-être n'existe-t-il pas une relation divine entre le langage et la performance d'un logiciel?

Ce que je trouve amusant, c'est que dès qu'on discute performance, il semble que tous les développeurs bossent sur de l'embarqué, des drivers de carte graphique, ou sur le noyau. Mais ce développement là représente quoi, en vrai? Quelle proportion des logiciels qu'on utilise tous les jours a besoin des quelques % de différence de temps d'exécution entre C et C++? Le noyau, le serveur X, et puis heuuu… Ça serait débile de croire que si LibreOffice est poussif, c'est parce qu'il n'est pas codé en C.

Si tu fais un tour sur un dépôt de logiciels libres et que tu regardes les langages, tu t'apercevras que 90% (au pifomètre rouillé) des projets en C n'ont absolument aucune raison d'être en C.

Ben non, il y a d'autres façons de facturer.

Bah oui, mais c'est la différence entre une entreprise et un salarié. Une entreprise peut facturer au temps ou au forfait, un salarié loue sa force de travail. Ça permet par exemple de payer les gens même quand ils font un travail inutile pour la boite (par exemple, un projet qui sera finalement abandonné) : les salariés ne facturent pas à leur entreprise.

Le développement de la micro-entreprise et de l'auto-entreprenariat pose de vrais problèmes qu'on ne peut pas écarter d'un simple revers de la main avec un argument libéral. En particulier, il se pose le problème du dumping. Une entreprise n'a pas le droit de vendre à perte, mais un autoentrepreneur a le droit de facturer des services à perte (par exemple, sous le salaire minimum). Il est évident que beaucoup d'autoentrepreneurs font un tel dumping, rien que pour conserver leur entreprise en vie dans l'espoir d'un démarrage ultérieur.

Je ne vois rien de mal à préférer une personne qui répond au besoin (même si ce dernier est de prioriser labaisse de prix à la qualité).

Ce qu'il y a de "mal", c'est que ça remet en cause le modèle économique de la profession. Je ne suis pas en train de comparer les devis de deux entreprises, là. Quand on met en concurrence deux boites, on va comparer les prestations proposées à ce qu'on souhaite, et dans les deux cas, on s'attend à ce que le travail soit de qualité professionnelle.

Là, on parle carrément de mettre en concurrence un système qui nie complètement le principe du droit du travail. Tu as affaire (au mieux) à des autoentrepreneurs plus ou moins légaux, voire carrément à du travail au noir pas du tout déclaré. Le travail se fait à l'arrache, dans des conditions absolument pas contrôlées (horaires journaliers?), payé à la tâche, sans salaire minimum.

Pour moi, l'équivalent, ça serait un grand hôlel qui file de temps en temps un balai et 5€ à un SDF pour mettre un coup dans l'arrière-cour, plutôt que d'embaucher une personne pour ça. Qu'est-ce que tu t'en fous d'avoir un balayeur professionnel? Tu es content, le SDF est content, où est le mal? Le mal, c'est que dans notre société, le travail a un coût et doit s'effectuer en respectant des règles. Ce coût peut être supérieur à la valeur que tu associes au travail, mais tu dois supporter cette différence par respect pour les personnes qui travaillent. C'est certes une logique non-libérale, mais le libéralisme seul ne peut pas définir l'éthique de nos sociétés (en tout cas, la plupart des européens semblent le voir comme ça).

Non, mais ça pose un vrai problème en fait : c'est le prix de l'expertise et du travail.

On vit dans un monde paradoxal où le chômage est rampant, mais où on veut garder des salaires raisonnables. Le problème n'est pas seulement la délocalisation des services, c'est simplement le prix que l'on veut bien mettre dans le travail d'une personne.

Le développement est un bon exemple. Tu as besoin de développer une fonctionnalité pour un programme existant. Combien ça peut te coûter de le faire faire dans les règles de l'art? Très cher, probablement. Des dizaines de milliers d'euros, même pour un truc qui ne parait pas hors de portée (une personne.mois, un truc comme ça). Combien ça va te coûter de le faire à l'arrache, avec un stagiaire, ou avec une offre dématérialisée sur Internet? Probablement 10 fois moins cher. Évidemment, la prestation sera de moins bonne qualité. Mais là n'est pas la question, parce que tu n'avais peut-être pas besoin qu'elle soit spécifiquement de qualité supérieure. Tu voulais juste avoir quelque chose de plus ou moins fonctionnel pour pas cher.

Avec la montée du chômage et la démocratisation des connaissances via internet, les experts ne sont plus compétitifs pour les trucs triviaux. Un exemple idiot, ta machine à laver ne fonctionne plus. Si tu es une personne âgée, tu vas appeler un réparateur. Si tu as un ordinateur, tu vas taper le nom de la machine, explorer les forums, te faire une idée de la panne, et tenter de dépanner toi-même. La moitié du temps, ça va fonctionner (évidemment, l'autre moitié, non, mais ça n'est pas la question). Au pire, tu vas trouver un bricolo du dimanche qui y connait un peu plus que toi et qui va te dépatouiller sur une partie des cas restants. Bref, tu cantonnes l'expert professionnel qui bosse selon les règles de l'art aux cas les plus complexes. Son expertise a encore de la valeur, évidemment : le jour où tu veux un travail bien fait, tu payeras. Mais dans notre monde où tout est jetable, où les entreprises ne cherchent plus à durer 40 ans, où personne dans une entreprise se souhaite y rester plus que quelques années, qui se soucie réellement que le boulot soit fait par les meilleurs experts? Qui est prêt à payer 10 fois ou 100 fois plus cher pour un service qui est, quoi, 2 ou 3 fois meilleur, avec souvent des délais plus longs ou des contraintes légales qui n'existent pas pour les services à l'arrache? Il n'y a plus que quelques professionnels que tu acceptes de payer plus que ce que tu es payé, parce qu'il y a des impératifs de sécurité qui nécessitent une qualité irréprochable : les médecins, les avocats, les architectes, les notaires, et éventuellement les garagistes. Pour le reste, on vit très bien avec l'imperfection.

Mouais.

1) Je ne vois pas l'avantage de coder des applications non-système en C. Pourquoi pas en assembleur, tant qu'on y est? C'est sûr, C permet de faire des trucs comme #define TRUERED(x) (((x) & 0xff0000) >> 8). Ça marche pour draguer?

2) Il n'y a pas nécessairement de rapport entre le nombre de lignes de code et l'efficacité ou la facilité de maintenance. Par exemple, pour st, on se retrouve avec un fichier st.c de 4000 lignes, et des centaines de fonction dedans. À part pour l'exploit de faire tenir un émulateur de terminal dans un fichier, c'est quoi l'intérêt?

3) L'exploit a un coût. Par exemple, le texte qui s'affiche quand on lance "st -h" est codé en dur. Du coup, quand on change une option, il faut modifier le code, et modifier le texte en dur. Il existe probablement des dizaines de bibliothèques qui permettent d'automatiser ça; beaucoup d'entre elles sont d'ailleurs seulement dans un .h et ne nécessitent pas de dépendance externes, elles peuvent juste être #include-ées.

Bref, l'exploit est intéressant en tant que tel, mais il est peut-être raisonnable de trouver un juste milieu. Les buffer overflow dans les applis météos parce qu'un geek a imaginé qu'il savait faire du C, ça va deux secondes, mais je préfère quand les gens utilisent des langages adaptés.

En fait c'est l'inverse

Ouuhhh, j'en connais qui vont parler de systemd :-)

Par rapport à DOS, c'est compliqué, mais par rapport à Windows, je trouve que depuis quelques années les distributions Linux ont fait beaucoup de progrès au niveau du temps de démarrage. Ce n'est pas instantané, certes, mais c'est très acceptable. Mon PC de boulot met plus de temps à lancer le bios et les trucs matériels que de démarrer le noyau et le serveur graphique. En gros, ça met autant de temps à lancer le système qu'à lancer libre office, c'est quand même notable.

La lourdeur des distributions, c'est autre chose. Les stratégies "à la Ubuntu", avec un bureau qui se comporte comme une surcouche à un système complet, sont évidemment à remettre en cause. D'une manière générale, un OS est un gros truc complexe, et à moins de disposer d'une puissance de développement extraordinaire, on est souvent obligé d'accumuler des couches pas bien conçues pour que ça marche (typiquement, des trucs comme PulseAudio). Les distribs ne vont pas développer et débugger tous les logiciels, elles ne font qu'assembler des briques. Si les briques sont mal foutues ou incompatibles, on ne peut pas blâmer les distrubutions…

Pour la lenteur des vieilles machines, j'ai toujours mis ça sur le compte du facteur psychologique, mais c'est vrai que je n'ai jamais pensé au vieillissement des composants.

faire de l'A/B avec pour seul but de fourguer plus de pub c'est vachement plus éthique que de regarder les impacts potentiel d'une fonctionnalité

J'ai l'impression que c'est exactement la question. Pourquoi donc tout le monde considère qu'une expérience est éthique quand elle est susceptible de générer directement des revenus commerciaux, et non-éthique dès qu'elle est un chouilla plus fondamentale, et qu'on ne voit pas le bénéfice direct pour l'entreprise? On marche à l'envers, là! Depuis quand générer du fric est un critère pour dire que quelque chose est éthique ou non?

Non, je pense que l'analogie n'est pas bonne : il s'agirait éventuellement de deux méthodes pédagogiques différentes. Et ça se fait très régulièrement ; quand j'avais 4 groupes de TD par semaine, je faisais évidemment des "expériences" de la sorte, pour voir quelle méthode semblait marcher le mieux. Je ne sais pas à partir de quel niveau on peut parler d'expérience, d'ailleurs ; est-ce que c'est simplement parce que le protocole était bien standardisé? Si tu fais un truc un peu au pif, ce n'est pas une expérience, mais si tu fais la même chose après 3 réunions, c'est une expérience?

À partir du moment où tu mets en place un service, et que tu bénéficie d'une forme de "retour" des utilisateurs (ne serait-ce que par l'observation de leur comportement), tu es dans une logique d'expérience, puisque tu vas modifier ton service en tenant compte de tes observations. Évidemment, c'est plus efficace si tu induis les comportements désirés en bricolant ton service ; tu penses donc que ce bricolage est non-éthique? Que c'est plus éthique si c'est mis en place chez tous les utilisateurs (pendant 24h pour tout le monde, plutôt qu'une semaine sur une sous-partie des utilisateurs?). Tout ça me semble être une question de détails, pas de principe.

Parfois, c'est bien de mettre en garde les gogos contre les pratiques abusives des grands groupes, mais là, c'est un peu exagéré de crier au loup pour une telle "expérience", qui est une chose assez banale chez les fournisseurs de contenu. Au pire, on peut reprocher à Facebook d'avoir volontairement dégradé un service, mais Facebook fait ce qu'il veut sur ses serveurs, et on pourrait reprocher la même chose à beaucoup de logiciels, dont pas mal sont libres (qui a dit Gnome?).

Le principe même de l'expérience est assez peu choquant : quand un enseignant donne un cours, il regarde ses élèves, s'ils dorment tous, il changera son cours au prochain coup. Une émission TV va tenter de changer des choses quand l'audience baisse, etc : il s'agit de s'adapter à son public en essayant des choses, et en regardant lesquelles sont plus efficaces. Parfois, comme ici, l'objectif n'est pas de mieux capter l'audience, mais de mieux comprendre comment les gens réagissent. C'est un peu de la recherche fondamentale ; il n'y a pas d'application directe mais ça n'est pas non plus fait par hasard.

Bof, l'argument est quand même pas terrible. À la limite, on peut dire que si Dieu existe, alors il ne peut pas exhausser les prières.

Bah, c'est juste un problème de définition. Pour la plupart des gens, leur Dieu exhauce les prières. Ce Dieu est donc réfuté par les expériences qui n'ont pas montré d'effet significatif des prières sur la survie. Après, si tu changes les définitions, il va falloir changer l'observation, mais c'est inévitable.

Et puis le coup du Dieu non-interventionniste, c'est une vaste blague : non seulement c'est un copier-coller caricatural de la plaisanterie de la licorne rose invisible, mais en plus, c'est une construction purement rhéotique : personne ne croit dans un Dieu non-interventionniste. Et pour cause : qu'il existe ou non ne change absolument rien, et il n'a jamais pu, par définition, se faire connaitre des Hommes. Pire, un gusse qui croit à un dieu non-interventionniste est complètement débile, il n'a aucune raison d'y croire, par défintion, puisque ce dieu n'a jamais rien fait et ne fera jamais rien.

C'est totalement vrai, mais la ligne de pensée, étrangement, est assez récente (en tout cas, elle est devenue populaire seulement avec la publication de "The God Delusion", un bouquin que j'ai trouvé très éclairant.

Avant les années 2000, il me semble que la ligne majoritaire parmi les scientifiques était celle dite de la "séparation des magistères" : la science s'occuppe de la science, les religieux s'occupent de la religion, les deux problèmes sont imperméables. Sauf qu'à de nombreux points de vue, ils le le sont pas, mais il était beaucoup plus confortable de rester sur ce statu-quo. D'ailleurs, dans cette discussion, il est frappant de voir que (d'après ce que j'ai deviné), le principe de la séparation des magistères est défendu bec et ongle par les gens qui pensent être croyants ou pseudo-agnostiques.

Mais bon, voila, la séparation des magistères est une solution socialement acceptable, mais pas scientifiquement. Factuellement, les prochaines avancées scientifiques dans le domaine vont être liées à la compréhension de la biologie du cerveau, et de plus en plus d'équipes s'intéressent à une approche intégrative de la psychologie des religions, qui mêle des approches sociologiques, des approches neuro-machintruc (avec des IRM du cerveau), et des approches de génétique évolutive, pour comprendre pourquoi, en gros, l'être humain a cette capacité incroyable à inventer des explications superstitieuses et à y croire dur comme fer. C'est vraiment étonnant à quel point c'est une souffrance de se débarrasser de ses superstitions, même petites—et c'est pareil pour tout le monde, ce n'est pas une différence athées/croyants. Après, la différence, c'est si on est prêt à faire l'effort de regarder le monde tel qu'il est, ou si on préfère se l'imaginer tel qu'on aimerait qu'il soit. Encore une fois, ce n'est pas seulement lié à l'athéisme ; j'imagine que beaucoup d'athées peuvent mettre des années à admettre que leur couple ne fonctionne plus, ou qu'il ne faut pas débrancher tonton Dédé parce que les 3 encéphalogrammes ont été faits par des incompétents. D'une manière générale, c'est une souffrance pour un être humain d'analyser les choses de manière rationnelle, et la religion est critique : elle a très souvent une dimension émotionnelle majeure, avec une transmission culturelle et familiale, et elle est structurante pour l'individu. Des gens pourraient tuer plutôt de remettre en cause leurs superstitions ; c'est d'ailleurs la frustration liée au manque d'arguments qui est probablement à l'origine de ce besoin de violence (je n'ai jamais eu l'impression que les athées voudraient être violents avec les religieux ; par contre, beaucoup de religions sont des menaces réelles pour les athées).

Je pense donc qu'il faut être très prudent dans les discussions. Évidemment, Moïse a ouvert la mer de la même manière que Pikachu a jeté des éclairs. Un extra-terrestre ne comprendrait pas pourquoi tout le monde trouve ridicule qu'un dieu à tête de faucon pèse les âmes, alors que 30% de l'humanité semble convaincue qu'il est tout à fait crédible qu'un gros barbu décide si tu vas au paradis. Mais c'est juste hyper-violent comme réalité. C'est un peu comme si tu disais à quelqu'un "ta femme est laide". Évidemment qu'il le sait, mais il s'est construit dans le déni de cette réalité, c'est inhumain d'aborder la question de cette manière.

la non existence du Dodo est scientifique, parce qu’elle est réfutable

J'ai longtemps cru que ç'était la base du raisonnement de Popper, mais j'ai appris récemment que Popper basait la réfutabilité sur la notion d'expérience critique (ça m'apprendra à ne pas lire les bouquins directement). Or, il n'existe pas d'expérience pouvant montrer l'inexistence du dodo, c'est pour ça que Popper avait beaucoup de mal avec la biologie évolutive, et les sciences à dimension historique en général. Il me parait évident actuellement que le principe de réfutabilité doit être étendu au delà de l'expérience critique pour prendre en compte les cas où une hypothèse est réfutable par une observation possible, mais qui ne peut pas être provoquée par l'expérience directe.

C'est évidemment un raisonnement à manier avec précaution, puisqu'on pourrait l'invoquer pour justifier n'importe quoi. Par exemple, on pourrait dire que Dieu existe, et qu'il suffise d'attendre qu'Il apparaisse et qu'Il lance des boules de feu par le trou de balle pour le prouver, sauf que pour l'instant, Il ne l'a pas fait. L'argument de l'observation possible doit donc être basé sur le fait qu'on puisse prouver qu'il a existé des dodos à un moment, et qu'à partir d'une certaine date, on n'en a plus observé. L'hypothèse la plus parcimonieuse est donc qu'il a disparu, et elle est potentiellement réfutable par l'observation. Mais ça ne tient que parce qu'on a des squelettes de dodo. Autrement, on pourrait dire que le dudu, une sorte de dodo de 38 tonnes, a existé et qu'il a disparu, et que l'hypothèse est réfutable par la possibilité d'observer un dudu.

On fonde un raisonnement logique pour essayer de tirer une conclusion.

Basé sur des axiomes, comme le rasoir d'Ockham. L'espèce de relativisme que tu défends n'est qu'une version pseudoscientifique d'un raisonnement rationnel. Aucun raisonnement scientifque ne peut être construit si l'on considère qu'en absence d'information, "A existe" a la même valeur que "A n'existe pas".

Ton discours est effrayant, épistémologiquement parlant. Je pense que tu t'es inventé une philosophie des sciences personnelle pour éviter la schizophrénie.

Ça me fait un peu penser à un gars qui avait demandé à Richard Dawkins "Comment pouvez-vous dire que Jésus n'existe pas? Ma vie est basée sur son existence, vous ne pouvez pas dire que ma vie n'a aucun sens." : c'est un exemple très puissant, je pense, de la manière dont des êtres humains a priori normalement constitués peuvent distordre les fondements de la logique pour éviter que le monde qui les entoure s'effondre.

Ça peut aller jusqu'à la redéfinition de la méthode scientifique, ou bien à relativiser les résultats scientifiques pour les mettre au même niveau que les croyances superstitieuses. Ça ne peut évidemment tromper que la personne qui les énonce, mais sa conviction est tellement forte qu'il n'y a aucun moyen de lui faire entendre raison. Toutes proportions gardées, c'est le sentiment que j'ai quand je te lis. Il faut que tu choisisses : la pilule rouge ou la pilule bleue? Tu peux parfaitement décider de continuer à vivre dans la matrice. Mais il faut aller discuter avec les gens qui ont fait le même choix, autrement, ça risque d'être conflictuel.