Philippe F a écrit 2204 commentaires

Dans les cas présentés, la gestion des mutex parait très simple. Dans des cas réels un peu complexes, avec plusieurs threads occupés à des tâches qui n'ont rien à voir entre elles, partageant plusieurs ressources à coups de mutex, écrire un programme correct s'avère beaucoup plus compliqué.

Dans ce cas, la mémoire transactionnelle peut apporter une solution intéressante en terme de simplification logicielle. Je ne saurai dire en terme de performance car c'est pas trop mon rayon.

Pour prendre un cas concret, Armin Rigo, le développeur de PyPy (l'implémentation alternative de CPython) vient justement de poster un article de blog sur le sujet 1, en disant que la mémoire transactionnée serait une alternative réaliste et intéressante pour se passer du GIL. Par contre, il cite des impacts de performance assez massif, donc ça reste un sujet expérimental à ce stade.

Je ne crois pas trop au modèle où les utilisateurs arrivent à mutualiser un besoin et l'exprimer suffisamment clairement pour que ça deviennent un sujet de développement rémunéré. Les utilisateurs ont rarement une vision suffisamment claire de ce qui leur manque et de comment y arriver et combien ça coûterait.

Ou bien alors on parle d'utilisateurs institutionnels et professionnels, et vous vendez de la prestation de développement comme une SSII.

En revanche, les différents exemples dans les commentaires parlent de succès dans le cas où le besoin et le but partent du développeur, qui cherche alors un financement. Je l'ai vu utilisé, pour Python, pour KDE (Krita, Quanta), pour mercurial. Là, c'est un développeur, en général indépendant, qui dit ce qu'il a envie de faire, combien il lui faut pour le réaliser et les utilisateurs peuvent se grouper pour l'aider. L'intérêt dans ce cas est multiple:
- comme ça part du développeur du projet, on sait que ça sera intégré au final dans le projet
- garantie de sérieux, puisque c'est le développeur lui-même
- la visibilité du projet est utilisée comme vecteur de communication vers les utilisateurs donc bonne chance de toucher ceux qui ça intéresse.

Bref, dans ce deuxième cas, j'y crois plus...

Toutes les fois que j'ai voulu utiliser Doxygen pour du python, ça été une catastrophe. D'abord il était pas compatible avec la documentation normale d'une fonction python. Puis quand ça a été ajouté, il y avait plein de cas où mes fonctions ou classes documentées n'apparaissaient pas dans la doc finale.

Quitte à faire du sucre syntaxique, pourquoi ne pas coder dans un langage propre qui génère du C++ crade. Comme ça, au moins, on peut avoir d'autres fioritures.

Sinon, les std::trucs, c'est pas toujours la panacée. Dés que tu veux faire des structures imbriquées, bonjour le bazar. Alors qu'en Python (ou en lisp), on va souvent s'abstenir de définir une classe parce que un dictionnaire de tuple de liste de string, ca s'écrit tellement vite que t'y penses pas. Et du coup, tu peux faire des manipulations faciles sur des arbres de données avec tous les avantages de la programmation orientée Data. En C++, tu te retrouves vite à trainer plusieurs classes, qui sont lourdes à faire évoluer, sur lesquelles tu vas rajouter une ou deux méthodes, etc.

En l'occurence, l'inférence de type a l'air de pallier à un autre défaut du C++, qui est la verbosité extrème de l'utilisation des template. Il aurait mieux valu addresser le problème à la source, avant de faire une syntaxe à rallonge, non ?

Et je parle pas des erreurs de gcc quand tu as une erreur de compile sur des string !

Déjà que le C++ était un langage relativement complexe, dont très peu d'humains sur terre maîtrisent toutes les subtilités (qui comprends réellement les appels de destructeurs virtuels des objets dans le cas d'une exception levée dans le constructeur d'un objet ?), là on entre dans une nouvelle ère.

Et que fait-on ? On rajout des mot-clés, avec des nouveaux comportements tout aussi subtils que les précédents, mais attention, qui peuvent aussi s'y cumuler. Les syntaxes des nouveaux concepts (lambda, foreach) ne ressemble pas du tout à la syntaxe typique du C++ et ça fait grosse verrue.

Parfois, il faut accepter qu'un langage est fini et que toute modification du langage ne va pas forcément dans le sens de son amélioration.

A mon sens, quitte à faire un nouveau langage avec des super fonctionnalités, mieux vaut faire ça dans un autre langage, avec une syntaxe flexible et travailler à mort sur l'interaction entre le C++ et ce nouveau langage.

Par contre, quelques évolutions de la STL, pourquoi pas.

Je m'interroge sur KDE et Gnome. Pour les deux projets, dont le but est d'avoir un desktop convivial sous Linux, je me demande si on a pas atteint le but. Les deux me semblent raisonnablement conviviaux à utiliser. En ce qui me concerne, mes besoins de base sont couverts par les deux projets, même si on peut toujours trouver des petites améliorations ou des gros défauts dans certains coins, je ressens pas du tout le besoin de continuer à faire évoluer l'interface de façon majeure (je suis tout aussi satisfait de Windows XP au boulot hormis 2 ou 3 conneries).

Pourtant KDE (et Gnome dans une moindre mesure) continuent à vouloir proposer une révolution du bureau en changeant ceci ou cela. Perso j'adhère pas du tout. Ca doit être mon côté vieux con mais je vois pas l'apport pour l'utilisateur standard. KDE 4 ne m'a pas fait tripper, et encore moins ce qui s'annonce pour KDE 5 .

En dehors des buts grandioses de KDE 5, je vois une masse de code en C++ qui manque de mainteneurs, un certain nombre d'applications qui peinent à retrouver leur ancienne vitalité, et des plans prévus pour tout casser.

Je dis : BOF !

Reconnaître qu'une application est finie et fonctionnelle, c'est une qualité. Il y a plein de logiciels qui n'évoluent plus que à la marge, sans que ça pose de problème. Pourquoi un truc comme KDE ne pourrait-il pas le faire ?

Surtout, les US étaient complètement à la rue sur la technologie de la carte à puce.

Bossant dans le secteur, le classement des grands producteurs de cartes à puce est à peu de choses près:
1. Gemalto, c'est bien de chez nous
2. Oberthur, c'est bien de chez nous
3. Sagem / Orga: ils produisent quand même la carte vitale et plusieurs autres projets passeports. Mais ils sont en perte de Vitesse.
4. Giesicke & Devrient: c'est des allemands
5. NXP (anciennement Philips): c'est des Néerlandais, très présents en Allemagne et en France

Les autres sont plutôt minoritaires. Donc en gros, la carte à puce, c'est un monde franco-allemand. Alors que c'est en train de devenir un technologie stratégique pour l'identification sécurisée des citoyens ou des employés dans le cadre d'un renforcement de la sécurité (je parle pas de traçage, juste d'assurer que Bob est bien Bob et pas Jules).

Quand on pense que les pays qui investissent le plus au monde en sécurité (Israël, US, Russie) n'ont pas la maîtrise de cette technologie, je comprends qu'ils aient des sueurs froides.

Mais de toute façon, l'expertise est en France ou au pire en Europe. Les développeurs familiers avec la technologie carte à puce, les laboratoires de sécurité, les gens qui pondent les spécifications internationales, etc, tout ça est soit chez nous, soit chez nos voisins.

Donc à moins de fermer tous les bureaux français, je pense que la techno va rester sur le principe en France. Et un agent de la DGA aura certainement plus d'influence sur un développeur de carte à puce travaillant à Nanterre que un patron situé aux Etats-Unis.

Pour moi, il y a pas de quoi s'affoler. Surtout que c'est un fond d'investissement, il peut très bien revendre Oberthur à une boite française ou européenne.

Il me semble que Gnome s'oriente de plus en plus vers du NIH, ou seuls les composants et applications développées par ou pour Gnome sont mises en avant et ont un vrai futur. Cf le post d'Aaron qui parle de la désimplication de Gnome dans l'interopérabilité avec les autres bureaux et surtout le choix de pousser une "expérience Gnome" unique, qui suppose de contrôler toutes les parties graphiques eux-mêmes.

Sur cet exemple précis de la moyenne d'ailleurs, le programmeur C sera contant de son programme "plus proche du hardware" et donc plus rapide. Mais il se fera ramasser par la gestion pourrie des floats en C.

Un programme dans un langage de haut-niveau, notamment des langages orientés maths, seront suremement moins proche du CPU (et encore, le JIT, c'est bien à ça que ça sert) mais donneront un résultat correct avec un nombre de décimal beaucoup plus élevé.

Et surtout: comment faire pour une conférence avec tes parents, ton frêre et toi ? Bah, vous avez qu'à pas vous parler...

Ca doit dépendre aussi de la puce elle-même. Dans le monde de la carte à puce, la production d'un masque par ST ou autres, c'est environ 15 000 de frais de masquage, et une commande minimale entre 15 000 et 30 000 € (soit entre 3 et 10 wafers).

C'est vrai ça, pourquoi on tape pas nos requêtes http à la main plutôt que de passer par un navigateur qui les génère ? Il serait quand même temps que les utilisateurs s'adaptent un peu à la technique !

Intéressant, mais pas portable. Si je debugge sous Windows et sous Unix, tu as une solution ?

La question revient tous les 3 mois sur comp.lang.python . On est VendredI Mais je ne VaIs Même pas rentrer dans le troll. Ou alors inVIsibleMent...

Plus sérieusement, au delà de l'éditeur, je cherche régulièrement un bon débogueur graphique pas à pas. Pdb, c'est gentil mais perso, je préfère le confort visuel.

J'ai utilisé Eclipse + pydev un temps, mais quand on développe pas sous Eclipse, c'est un vraiment lourd. Et régulièrement, il me sautait allègrement mes points d'arrêts, il ne prenait pas ma version de Python par défaut, et autres joyeusetés. Komodo est pas mal mais c'est payant et quand même un poil lourd. Maintenant, je me suis rabattu sur winpdb . C'est encore un peu rustique (supporter le drag'n drop pour ouvrir des fichiers par exemple, ce serait sympa) mais au moins, ça débugge correctement.

Ouai, on peut dire la même chose de Hurd vs Linux. Perso, j'ai pas parié sur Hurd et je parierai pas plus sur Parrot. Etre trop ambitieux, c'est la raison no 1 d'échec des projets logiciels libres.

Unladen Swallow est officiellement mort maintenant. Reid Kleickner, un développeur stagiaire chez Google qui travaillait sur le projet explique dans une entrée de blog les raisons de l'abandon du projet: http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html .

En gros:

• LLVM s'est avéré décevant pour l'optimisation de langages dynamiques. Les développeurs ont rencontré beaucoup de bugs qu'ils ont du corriger eux-même, d'où une perte de temps considérable sur le coeur du projet.

• les projets qui sont sensibles à la performance chez Google sont finalement peu développés en Python. En dehors du module Pickle, les développeurs Google s'en sortent très bien avec le Python officiel.

• Google est encore en Python 2.5 alors que Unladen Swallow est parti sur Python 2.6 . Du coup les projets Google ne peuvent pas bénéficier du JIT sans un effort de portage.

• Au début de Unladen Swallow, PyPy était encore moyen en performance et ne gérait pas du tout les extensions en C ou la génération de code 64 bits, d'où un intérêt certain pour Uladen Swallow. Ce n'est plus le cas aujourd'hui.

• Reid Kleickner a essayé de travailler sur Unladen Swallow dans le cadre de sa thèse mais on lui a dit poliment qu'il n'y avait là aucun sujet de recherche : les techniques de JIT font partie de l'état de l'art.

Au final, ce qui reste de Unladen Swallow: - pas mal d'optimisations sur le module Pickle - quelques optimisations de ci de là dans Python - une super suite de benchmark contenant les projets majeurs en Python (twisted, django, ...) permettant d'évaluer les performance de Python sur des projets réels - une interface de débuggage pour gdb permettant de suivre le code JIT de LLVM

La suite de benchmark de Unladen Swallow a été reprise par PyPy et sert de référence pour http://speed.pypy.org . Elle sera aussi bientôt reprise officiellement par CPython pour comparer toutes les version de Python (CPython, PyPy, Jython, IronPython, WPython, ...). Son seul inconvénient est qu'elle ne supporte que Python 2 pour l'instant (parce que les projets utilisés pour les benchmarks sont encore en Python 2).

C'est pas très solide comme argumentation pour m'expliquer que j'ai tort de dire que je vis dans un monde qui n'existe pas.

Je vis dans un monde tout à fait réel. Le fait que tu retrouves le mêmes arguments que Zenitram dans mon post ne viennent pas du fait qu'il m'a embrigadé le cerveau ou autres trucs débiles. C'est juste que nous avons tous les deux été confrontés à la même expérience, et en avons tirés les mêmes conclusions.

<ma vie> Il se trouve que je développe un logiciel qui fonctionne sous Windows et sous Linux. Il est écrit en Python + PyQt. C'est un logiciel très modeste, j'ai 200 utilisateurs, dont à peu près 199 sous Windows et 1 sous Linux. Et encore, je ne sais même pas si il est encore là. Pour prendre en charge la distribution de mon logiciel sous Windows, j'ai investi environ une semaine de mon temps de dev (comprendre 15 minutes de trajet aller-retour dans le train à programmer, 5 fois dans la semaine soit environ 2h30). Au final, j'ai un script automatisé de packaging, qui génère un installeur qui fonctionne à coup de Suivant-Suivant-Suivant, qui supporte toutes les versions de Windows. Il détecte aussi les mises à jour via deux canaux suivant que tu choisissent les versions beta ou uniquement officielles.

Mes utilisateurs semblent répartis entre un bon paquet d'informaticiens, un bon paquets d'utilisateurs à l'aise sous Windows mais sans compétence spéciale, et un petit paquet de neuneus de l'informatique (terme que j'utiliserai ici affectivement plutôt que péjorativement). 2/5 de mes utilisateurs ont choisi d'utiliser la version beta et parmi ceux-ci, il s'en trouve des neuneus. Ce sont d'ailleurs eux qui m'ont signalé quelques petits détails qui faisaient que mon soft était "mal léché" ainsi que quelques gros bugs. Toutes les améliorations que j'ai faites pour faciliter la vie des neuneus (comme la notification des mises à jour automatisée) ont d'ailleurs fait augmenter ma base d'utilisateurs dans toutes les catégories.

Donc, pour en revenir au sujet, je constate que des utilisateurs qui ne sauraient pas su tout utiliser un tar en mode graphique (ou un zip d'ailleurs) sont tout à fait capables, d'une part d'installer un soft en version beta sous Windows, avec son lot de bug, et d'autre part, de me reporter des bugs utiles. Cette frange d'utilisateurs, même si ils ont installé linux, ne seront pas beta-testeurs de Firefox parce qu'ils ne sont pas capables de l'installer. Et c'est une perte réelle pour Firefox.

L'autre point qui me chiffonne dans mon expérience, c'est la difficulté de distribuer un soft sous Linux. Il y avait une super initiative qui n'a malheureusement pas duré, qui s'appelait Klik. En dehors de ça, c'est vraiment la galère.

Partons du principe que je suis prêt à investir le double du temps en packaging que ce que j'ai investi pour Windows, pour gérer Linux, c'est à dire à peu près 5 heures. Voire même 10 heures. J'ai un utilisateur sous Debian stable, un autre potentiel sous Ubuntu, et un pote qui testerai pour moi sous gentoo.

Je suis face aux questions suivantes :

1. mon programme est en python. Dois-je faire un installeur maison, qui fonctionne avec un sudo et qui copie un script dans /usr/local/bin ? Quid des dépendances PyQt et version de Python minimale ?

2. je peux aussi le packager en "binaire" avec pyinstaller, mais où ranger tout ça dans la distrib ? Et ça fait pas très classe d'avoir des binaires pour du python, non ?

3. dois-je vraiment installer 3 distributions pour tester que mon soft fonctionne ?

4. lors d'une mise à jour de mon soft, comment faciliter la réinstallation ?

5. dois-je plutôt suivre la longue route du packaging et apprendre à packager pour debian, Ubuntu (j'ose imaginer que c'est un peu la même chose) et gentoo, donc découvrir deux outils différents de packaging. Et je dois aussi fournir de la doc à mes utilisateurs sur comment gérer l'installation car on est plus dans le suivant-click-suivant-click-terminer, ce qui signifie en gros investissement de ma part en terme de doc.

6. un autre problème que je maîtrise pas (car je connais pas debian ni apt), c'est ces histoires de dépots. Dois-je faire du lobbying pour que mon soft soit inclus dans un dépot officiel, ou puis-je fournir un paquet dans un coin et lors du téléchargement, l'outil approprié proposera à l'utilisateur d'installer mon soft avec les droits qu'il faut ?

En attendant, j'ai fait simple mais pas satisfaisant : je considère mes utilisateurs linux comme des power users. Je distribue un zip et il y a la liste des dépendances et versions dans le README. Ils auront qu'à cliquer sur le script python principal pour qu'il lance mon soft. Et pour le téléchargement des mises à jour, ils iront se brosser, il n'ont que les notifications des mises à jour.

Mais quel dommage, je suis sûr qu'avec des outils plus conviviaux pour les développeurs comme pour les utilisateurs, je pourrai voir ma base d'utilisateurs de Linux grossir de 200% voir 300%. </ma vie>

Maitenant, je me demande qui vit dans un monde imaginaire ? Toi, moi ? Dans ton monde, même les neuneus sous Linux arrivent à installer mon soft, et seuls les power user sous Windows arrivent à installer la version beta, et packager un soft sous linux pour les distributions majeures prend moins de temps que sous Windows.

Je voulais juste dire que je suis 100% d'accord avec Zenitram. Pour quelqu'un qui produit un logiciel, il est 10 à 100 fois plus simple de le proposer sous Windows que sous Linux.

La procédure d'installation et de désinstallation d'un logiciel sous Windows est simple et n'importe quel utilisateur qui utilise à peu près un ordinateur arrive à la faire. Ca veut dire qu'il y a une masse énorme d'utilisateurs qui pourraient installer Firefox beta. Parmi cette masse énorme, il existe un nombre raisonnable d'utilisateur qui a envie de tester une beta, qui peut rapporter des bugs, etc.

Sous Linux, outre le premier facteur qui est que le nombre d'utilisateurs total est beaucoup moindre, le niveau minimum pour installer une beta de Firefox est aussi nettement plus élevé. Ca dépasse largement le click-click-click de Windows, ce qui veut dire que même parmi la masse d'utilisateurs de Linux, la procédure filtre plein de personnes. Donc Firefox sous linux en beta est testé par des utilisateurs qui savent utiliser tar, savent déplacer des fichiers ou bien savent utiliser l'installeur automatique de leur distribution. C'est bien mais ça fait beaucoup beaucoup moins de monde. Donc c'est pas forcément surprenant que Firefox marche moins bien sous Linux que sous Windows.

C'est fait. Par contre j'essaye de l'executer, c'est pas vraiment portable. Je vais voir si j'arrive à en tirer qqch.

C'est censé être portable ? Parce que là, sous Windows, python setup.py install, ca marche pas des masses...

Autre question au passage, est-ce que boobank permet d'exporter facilement en csv ? Ou gère les fonctions d'export csv des différentes banques ?

1. Qu'est ce que vous faites comme travail ? Est-ce que ça implique du Python ? Est-ce que vous êtes payés pour travailler sur le développement de Python ?

2. Comment êtes-vous arrivés à devenir développeur Python ? Depuis combien de temps ?

3. Certains projets comme KDE donnent un accès svn facilement (au second patch soumis). D'autres comme gcc ou CentOs n'ouvrent le repository qu'après plusieurs années de travail et sous recommendation. Comment se situe Python de ce point de vue là ? Est-ce difficile de passer de contributeur à développeur, d'obtenir un accès svn (hg maintenant) ? Est-ce que vous pensez que le curseur est au bon niveau ?

4. La popularité de Python a vraiment augmenté ces dernières années, est-ce que vous en avez vu les conséquences au niveau du développement du langage : plus de bugs reportés ? plus de patchs ? plus de contributeurs ? plus de questions débiles ?

5. Est-ce que le langage Python a encore besoin d'évoluer ? Le langage est aujourd'hui très complet, est-ce qu'il y a vraiment besoin de lui rajouter des nouveaux trucs ? Le moratorium sur l'immobilité du langage a été levé, est-ce une bonne chose selon vous ?

6. Qu'est ce que vous pensez de Perl 6 ? Est-ce que vous l'avez regardé ? Est-ce qu'il y a des idées qui pourraient être utilisées dans Python aussi ?

7. Qu'est ce que vous pensez de la qualité du code actuel de Python ? Pour le passage à Python 3, vous avez pu changer quelques trucs mais aucun changement majeur interne n'était prévu. Est-ce qu'il y a des zones de code où vous vous dite "il faudrait carrément tout réécrire ce truc mais c'est pas possible du tout" ?

8. Que pensez-vous des efforts pour avoir des interpréteur Python JIT ? Vous y croyez pour le futur de Python ?

9. Unladen Swallow devait rentrer dans Python, sauf que le projet est l'arrêt. Vous pensez qu'il a encore une chance de rentrer, maintenant que PyPy l'a rattrappé en terme de performance ?

10. Est-ce qu'il y a des choses qui manquent réellement à Python, ou qui demandent une grosse amélioration, dans l'écosystème Python en général ?

11. Le passage à Python 3 se fait de façon très lente, beaucoup de projets ne sont toujours pas portés. Est-ce un problème ? Est-ce que Python 3 apporte de réelles solutions ?

12. En lisant python-dev, j'ai pu apprécier le travail de Victor sur la gestion de l'unicode sur tout ce qui touche à la gestion de fichiers. Si j'ai bien suivi, il reste des cas irrésolvables où on ne pourra pas afficher correctement le nom d'un fichier, voire où on ne pourra pas lire un fichier au nom étrange ?

13. Certains se plaignent qu'à côté d'un langage comme Lua, Python a un runtime assez gros qui le rend difficile à embarquer sur des petits matériels. Un autre problème est aussi qu'il est impossible d'embarquer plusieurs runtime simultanément. Vous en pensez-quoi ?

En effet pour être plus uniforme, je devrai parler de lactose et du gluten, ou bien de céréales, farines, pain, pâtisseries, gâteaux, pâtes, et de lait, fromage, yaourt, fromage blanc, etc. C'est juste que les gens connaissent asses bien les dérivés du lait et sont capables de trouver la deuxième liste toute seule. La première liste est elle trop longue à faire.

Concernant les autres allergies à des aliments, il me semble que le pourcentage d'intolérants ou d'allergiques de la population est carrément ridicule par rapport au lactose et gluten. Si je me souviens bien, c'est 80% des allergies alimentaires sont au lactose et 50% au gluten (ca fait donc au moins 30% qui sont allergiques aux deux). Et le gluten comme le lactose font partie de l'alimentation quotidienne d'une très très grande part de français. Je n'en dirai pas autant de l'ananas ou des fruits de mer.

Disons qu'en observant les animaux, tu peux voir quelle est leur alimentation naturelle. On part ensuite du postulat que naturelle = bon pour leur santé, et qu'en s'écartant trop de la voie naturelle, on prend des risques qui sont très mal évalués aujourd'hui.

Notre système digestif de mammifère date d'il y a quelques millions d'année. Notre alimentation moderne a sérieusement changé dans les 50 dernières années. Le bon sens tend à faire dire que pour ne pas pourrir le système digestif, il vaut mieux lui filer des trucs qui ont fait leur preuve dans les derniers millions d'année que des trucs tout récent.

A propos des vertus de toutes les saloperies qu'on nous refile à bouffer, les scandales récents (Mediator, Bisphenol A, Di-Antalgic) montrent quand même la faiblesse des moyens de contrôle qu'on a sur des produits où la nocivité est pourtant avérée. Alors sur des trucs où la nocivité est moins patente car lente à s'activer, imagine le niveau d'information qu'on doit avoir.

Sur le lait et le gluten, il existe de l'information scientifique fiable et disponible. Après, les défenseurs du logiciel libre connaisse bien le chemin entre "ca marche et c'est prouvé" et "tout le monde le sait" et encore "tout le monde va en tenir compte".

De toute façon, la nocivité du lait serait avérée, publique et officielle que ça ne changerait pas grand chose. L'industrie laitière est là pour veiller aux grains. Comme nos braves éleveurs de porc de Bretagne qui sont en train de tuer lentement leur concitoyens en empoisonnant les nappes phréatiques.

Lit l'ouvrage recommandé juste au dessus, et fais-toi ta propre opinion. Ou arrête le gluten pendant trois mois et vois si tu te portes mieux. Attention, arrêter le gluten, c'est carrément très dur.

Pour être moins expéditif, les avis que j'avais lu sur le sujet (car je n'ai pas lu l'ouvrage du Dr Seignalet) disaient que le gluten à l'origine, n'était pas toxique pour l'organisme. Mais d'une part, on s'est mis à favoriser des céréales à teneur de plus en plus forte en gluten (plus de pain de mie, farine plus facile à travailler), d'autre part, il y a tellement de modification à la céréale que l'organisme ne reconnait plus correctement le gluten.

De fait, chez les intolérants ou allergiques, le gluten n'est pas en soi nocif, c'est juste qu'il est incorrectement détecté par le système digestif comme un élément nocif, qui génère une réaction très forte, disproportionnée, et dirigée contre l'organisme lui-même. On parle de maladie auto-immune. Ça donne une inflammation permanente du tube digestif, qui chez de nombreuses personnes (comme moi) reste suffisamment modeste pour que ce ne soit pas dérangeant (à part un ventre légèrement gonflé), mais chez d'autres, peuvent générer des douleurs insupportables. Il y a donc plein d'intolérants légers qui s'ignorent, et qui ont tous le potentiel pour devenir intolérants forts (l'organisme n'aimant pas trop être en situation d'inflammation permanente).

Tous les gens qui ont de légers problèmes digestifs (ballonnements, lourdeurs, etc) devraient commencer par arrêter lait et gluten pendant un mois, et voir si il y a des améliorations. On découvrirait que le nombre d'intolérant est bien plus élevé qu'on ne croit...