anaseto a écrit 2229 commentaires

elle ne s'appauvrit pas, et pas plus la France globalement, va voir par exemple le Venezuela pour un pays qui s'appauvrit

Je trouve que t'es un peu rapide toi aussi pour les conclusions. Je dis ça, pourtant moi je suis de ceux qui pensent que, de nos jours, en France, la pauvreté est assez souvent un choix : si on accepte de vivre chez des amis, les parents ou dans un coin pas cher un peu pommé (mais pas au point d'exiger une voiture) et qu'on est pas trop difficile avec le choix de métier (voire juste accepter fièrement la honte du RSA), on peut y échapper. Mais bon, se dire qu'on est parfois contraint de nos jours à faire de tels choix pour échapper à la pauvreté (c'est-à-dire pas sacrifier des dizaines d'années de travail à payer un logement) et qu'on n'a plus la même liberté de choisir où on vit qu'avaient (plus souvent) nos grands-parents, j'ai quand même l'impression que, sous certains aspects quand même assez fondamentaux et impactant la qualité de vie (choix du lieu où on vit et proximité au lieu de travail), on a régressé, mes c'est peut-être juste mes stats, au pifomètre et basées sur mon expérience, qui disent ça.

J'ai l'impression que cette conversation mélange plusieurs choses.

D'abord est-ce que c'est sain et éthique qu'il y ait d'aussi grandes différences de richesses. Et est-ce que c'est sain de se comparer toujours à plus et pas à moins.

Et puis d'un autre côté, est-ce que c'est possible d'avoir un monde plus juste, car tout le monde veut toujours plus de toute façon et les êtres humains sont ce qu'ils sont etc. Pour le coup la réponse ici n'est pas facile et on va pas résoudre ça sur linuxfr, mais bon, dans tous pays il y a de meilleurs et pires moments, à certains endroits c'est mieux pour ceci et pire pour cela, c'est pas tout le temps pareil non plus. Tu compares au chasseur de mamouth, mais je pense qu'à l'époque ça devait être plus facile d'avoir des petites tribus avec des modes de fonctionnement plus divers, dont certains plus « justes » que ce qu'on peut trouver de nos jours, où tout a été assez homogénéisé par la centralisation ; centralisation permise essentiellement par les avancées technologiques qui ont aussi du bon (mouler sur linuxfr) et du mauvais (différences extrêmes de richesses plus faciles). C'est compliqué, mais je pense qu'on peut pas tout mettre sur un même plateau de façon défaitiste, comme si la société a toujours été la même, bien qu'individuellement les gens sont les mêmes êtres humains.

Après, c'est vrai qu'un des inconvénients de nos jours, c'est que là où la petite tribu ne pouvait pas se permettre d'être trop injuste, car sinon elle ne survivait pas à l'évolution (vu la difficulté à survivre l'entraide devenait un critère de survie), maintenant j'ai l'impression que la barre où les injustices deviennent suffisamment grandes pour être régulées par l'évolution est plus haut ; en fait, je me dis même peut-être que la tendance à l'esprit d'entraide qui nous vient probablement de l'évolution est même un élément clé qui permet la manipulation et le maintient d'un système injuste. Bien que ceci est en bonne partie le fruit de l'égoïsme personnel naturel (espoir de se débrouiller dans le système actuel plutôt que consacrer de l'énergie à des changements avec des conséquences incertaines pour soi et ses proches), il y a aussi le côté « esprit de faire un minimum bien les choses » dans son travail qui permet de nos jours à beaucoup de structures de fonctionner là où si tout le monde avait fait juste le minimum obligatoire, ça aurait fait plouf et un système alternatif aurait du voir le jour, plutôt que l'habituelle dégradation lente et progressive des conditions.

Ah, mais je ne voulais pas sous-entendre que c'était parce que le logiciel ne serait pas respectable : pour autant qu'on puisse en juger, personne fait exprès de rendre les choses impossibles à compiler, c'était juste pas une priorité (normal, les devs actuels ont l'infrastructure qu'il faut) et maintenant inverser la tendance semble difficile.

Firefox est bien sûr un monstre également de ce point de vue, bien qu'au moins on dirait qu'il faut moins de patches pour le rendre portable.

Tu peux :-) Après, la question, c'est est-ce que tu as une alternative raisonnablement accessible dans laquelle tu pourrais avoir ces libertés.

Vu qu'un des buts de base logiciel libre à la base, c'est que ce soit l'utilisateur qui ait le contrôle sur le logiciel, on peut pas espérer capturer à fond cette notion avec simplement une licence. Dans certains cas, quand ce contrôle devient difficile pour beaucoup du fait de contraintes non-bureaucratiques (matérielles ou manque de main d'œuvre compétente) et que le logiciel (navigateur web) devient néanmoins indispensable même pour des taches administratives publiques, on peut s'inquiéter. Surtout quand il n'y a pas grand espoir de voir apparaître des alternatives accessibles à court ni peut-être même moyen terme (trop complexe).

Blink est un monstre à compiler, les fichiers demandent rapidement des GB de RAM pour compiler.

Honnêtement, quand je vois ces monstres, je me dis que le logiciel a beau être libre, s'il faut avoir une machine monstre équivalente pour le modifier et le compiler, en pratique ça veut dire que pas mal d'utilisateurs (moi inclus) ne peuvent pas disposer en pratique d'une des libertés fondamentales. À mon avis, c'est plus grave que de ne pas pouvoir modifier par manque de compétences, car c'est une contrainte plus matérielle, même si je conçois qu'on puisse les considérer similaires : dans les deux cas, du moment qu'il y a des gens à qui tu fais confiance qui ont les moyens, tu profites indirectement des libertés et sinon t'es piégé.

Enfin, pour s'effrayer davantage, heu, je veux dire, se rassurer, dis-toi que ça aurait pu être pire que dans ton cas : sur OpenBSD il y a une multitude de patchs pour porter chromium, j'ai l'impression que les faire remonter upstream c'est pas évident (pas suivi l'histoire, mais ça fait un moment que c'est comme ça) et comme qt5 webengine n'utilise pas exactement la même version de chromium, personne n'a encore eu le courage d'essayer d'adapter les patches, ce qui fait qu'on a toujours pas qt5 webengine, même si j'imagine que ça finira peut-être par arriver.

Les blagues d'initié, c'est souvent moins intense la première fois, mais satisfaisant dans la durée :-) Sinon, moi j'aime bien les blagues où, au début, on a l'impression que ça va peut-être être un truc d'initiés/scientifique.

Genre celle de celui qui demande à ses amis, dans un bar, pourquoi les plongeurs plongent toujours en arrière. L'un répond « sinon, l'impact avec l'eau pourrait déplacer leurs lunettes et gêner leur vue », à quoi un autre répond « mais non, ils se jettent en arrière à cause du poids de l'équipement qui pourrait les déséquilibrer et les projeter contre la coque du bateau et les hélices » pour qu'on lui réplique aussitôt « pas du tout, c'est du fait du principe d'Archimèdes et que tout corps qui se submerge expérimente une force du bas vers le haut… ». La personne derrière le comptoir intervient : « mais qu'est-ce que vous êtes lents : s'ils plongent en arrière, c'est parce que s'ils plongeaient en avant, bah ils tomberaient dans le bateau ! ».

C'en est un qui va voir un devin, frappe à la porte et on lui demande : « Qui c'est ? ». Il répond : « Ben l'est sacrément mauvais le devin ! ».

— Chéri, je crois qu'on pourrait avoir un autre enfant.
— Ça me semble bien, moi aussi j'aime pas celui qu'on a maintenant.

Tu dis feu-txt2tags, le langage est vraiment mort ou fini ?

Si je me souviens bien, c'est un langage très orienté regexp et extension via substitutions textuelles, filtres et/ou pipes ? Ça a le mérite d'être une approche simple, même si question fiabilité et précision des messages d'erreurs du coup, c'est a priori difficile. Et c'est probablement lent mais ça c'est rarement important, je réagis juste au very fast sur le site comme si c'était particulièrement rapide pour un langage de balisage ;) (peut-être comparé à pandoc ou autre programme pas super rapide).

… mais par contre la gestion des tableaux et notes de bas de page est royal.

Pour ceci Frundis n'est pas le langage à choisir a priori par contre, car assez dépourvu par défaut : ça fait partie des trucs pour lesquels j'ai dû définir des balises enrobant du LaTeX lorsque j'ai écrit ma thèse. Après, tout dépend aussi de chacun (comme je maîtrise bien l'outil et sait l'étendre assez facilement, je serais tenté de l'utiliser dans plus de cas).

En tout cas, je trouve passionnant ces discussions autour des langages même si je suis pas dans le milieu de l'informatique.

En même temps, c'est pas forcément les informaticiens qui vont être intéressés par un langage de balisage donné. La personne qui utilise le plus Frundis (en gros, tous les jours depuis plusieurs années), c'est pas moi mais une écrivain (ma sœur) ayant suivi une formation littéraire, et qui a d'ailleurs fait une présentation au CDL il y a peu (par contre, on voit pas bien les slides dans la vidéo, ils sont disponibles ici aussi).

Les points que je soulève (abstraction sémantique et messages d'erreurs) sont effectivement des points que j'ai eu en tête en créant Frundis, me souvenant de mes aventures avec LaTeX, pandoc, EPUB et surtout mandoc(1), ma plus grande source d'inspiration au sujet des messages d'erreur.

Ceci dit, Frundis n'est pas un langage pour écrire de la doc technique, donc ce n'est pas vraiment comparable : la doc de Frundis est en mdoc(7) d'ailleurs, évitant le piège classique consistant à utiliser son propre langage lorsqu'il y a un outil plus adapté :-) Par contre, pour des textes pas suffisamment spécifiques pour justifier l'utilisation d'un outil spécialisé (tutoriel oui, page man non) et pas trop demandants (genre sans équations ou figures et tableaux complexes) ou de simples pages web (je fais ça pour une bonne partie de mon site statique) ça fait bien l'affaire, et c'est plus facile à maintenir que du markdown et moins verbeux que du html.

Après, s'il n'y a pas de solution évidente rien n'empêche bien sûr d'expérimenter. J'ai écrit une thèse d'info avec après tout. Mais ça demande de définir de nouvelles balises techniques pour les différents formats que l'on veut, c'est potentiellement du travail pour réussir à abstraire tout ce qu'on veut (quand c'est possible). Du coup, j'avais défini des balises que pour l'export LaTeX en l'occurrence (facile), perdant une bonne part de l'intérêt de Frundis (export multi-format), profitant au final juste de messages d'erreur moins brutaux que LaTeX et une syntaxe que je préfère, car moins d'accolades et qui s'harmonise mieux avec grep et diff.

J'avais jamais vraiment creusé ce langage jusqu'à présent, car j'ai pas vraiment besoin personnellement d'un langage de doc technique, ayant juste écrit quelques pages man et pour ça un langage vraiment spécialisé comme mdoc(7) est plus adapté. Mais je suis toujours curieux au sujet des langages de balisages, j'ai donc regardé plus en détail. Je pensais que c'était simplement un markdown++ qui exportait vers docbook, mais le langage a quand même un certain nombre de trucs le rendant plus adapté à la maintenance d'un gros projet : possibilité d'être sémantiquement extensible et pas que présentationnel (ajout de classes et rendu personnalisable dans css, je sais pas ce que ça donne pour l'export LaTeX par contre), possibilité d'utiliser des directives style ifdef, pour personnaliser s'il le faut en écrivant du code différent pour des formats de rendus différents (autorisant par exemple une personnalisation LaTeX poussée sans empêcher l'export à d'autres formats). Ça gère plus de trucs de base, peut-être limite trop, car on maîtrise pas ça en deux heures, mais ça a son côté positif aussi si on en a besoin (tableaux complexes, balisage de blocs de code, etc.). Et le langage est extensible, bien qu'on dirait qu'il faut écrire du ruby pour ça, donc pas pour tout le monde, surtout vu le nombre de points d'extension différents et le côté bas niveau de l'API.

Par contre, pour de gros projets, sauf si je suis passé à côté ou oubli dans la doc, ça préserve un inconvénient à mon avis majeur du « tout est permis » du markdown : pas de messages d'erreur pour des trucs classiques comme oubli d'une étoile (balise fermante), a priori. On dirait qu'il y a des messages d'erreurs pour certains trucs spécifiques (contrairement à markdown ou tout est vraiment valide), mais c'est plutôt limité. C'est un truc qui me surprend, peut-être n'est-ce juste pas documenté dans la liste des diagnostics, j'ai pas testé en vrai (pas de paquet asciidoctor sur OpenBSD on dirait, donc testé avec le veil asciidoc). Je comprends que ce genre de syntaxe « intuitive » est en fait bien plus compliquée et que donc c'est moins facile d'avoir de bons messages d'erreur qu'avec une syntaxe plus explicite, mais je vois pas trop ce qui empêcherait une implémentation de prévenir l'utilisateur qu'il a oublié de fermer des balises (quitte à avoir une localisation sous-optimale).

Je ne vois pas non plus de vérification automatique possible que les classes personnalisées utilisées lors de l'utilisation des balises # font partie d'une liste spécifique et n'ont pas de typos : il faut se faire un script à part pour vérifier extraire ces infos et vérifier qu'on a pas fait de typos, je suppose.

Et puis, une dernière chose que j'ai cherché sans trouver, c'est une façon de faire de nouvelles macros/styles (sans passer par toute la machinerie ruby) capables d'abstraire le code spécifique à un format d'export de façon simple pour pas polluer le corps du texte. Sans ça, les ifdef sont quand même beaucoup moins utiles. Je vois donc pas non plus de façon de raccourcir simplement l'utilisation de code comme [.pathname]#/etc/#, donc si on tient vraiment à écrire de façon sémantique et non présentationnelle, ça devient un peu verbeux (plus de caractères même qu'en LaTeX ou groff où on aurait pu définir quelque chose comme \pathname{/etc/} — 2 symboles en moins).

Pour le programme, c'est vrai qu'on a un programme très orienté algorithmique. Cela me semble être un bon choix. Il y a certes eu des excés en prépa (langages reconnaissables et autres joyeusetés, fonctionnel beaucoup trop mis en avant à mon sens) mais ça se calme.

D'un côté, moi j'aimais bien ça à l'époque, mais perso je trouve qu'autant d'algorithmique sans but concret, c'est pas une bonne chose pour la plupart.

Moi, tout le goût de l'informatique, je l'ai pris en découvrant le libre entre la première et deuxième année de prépas et en faisant des choses sur mon temps libre fin prépas début L3, à peu près dans l'ordre : apprendre Haskell (en période révision concours, hum) pour utiliser parsec et écrire un parseur pour un DSL pour poèmes, découverte de la communauté Haskell (un peu dans les nuages mais un minimum dans le concret), écrire un jeu de pendu, parser les METAR (rapport d'observation météo), utiliser un framework web Haskell, apprendre Perl et écrire des scripts divers pour de petits besoins, découverte de la communauté Perl très pragmatique (OO, fonctionnel, peu leur importe tant que ça marche : gros contraste avec la communauté Haskell), la communauté du libre aussi (bépo, emacs, vim, sh et unix, etc.), lire des blogs, linuxfr etc.

Le côté social et un aperçu des diverses communautés et leur charme à chacune est quelque chose à mon avis très important, ça donne vie à l'informatique, et j'en ai eu quasiment aucun aperçu pendant les cours (autre à la limite de ce qu'est la communauté informatique académique, mais même ça c'est surtout pendant la thèse). Jamais fait de gros trucs pendant les débuts (pas le temps à l'époque), mais tous ces petits trucs concrets m'ont permis d'associer des souvenirs positifs avec « informatique » malgré le côté totalement abstrait/asocial de l'enseignement reçu à côté. Même plus tard, pendant thèse etc, j'ai ressenti le besoin de faire à côté des trucs concrets à côté (de plus en plus gros), sans quoi j'aurais probablement perdu le goût de l'info. Connaître tout un tas d'algos de graphes, optims compilateur et que sais-je etc. si on arrive pas à utiliser ces connaissances d'une façon qui nous parle… comment dire, pour beaucoup de gens (dont moi), l'intérêt intellectuel en soi des algos n'est pas suffisant pour alimenter la motivation. Et se dire peut-être dans 5-10 ans je l'utiliserai, non plus.

Il y a aussi le problème fondamental du recrutement : il y a de moins en moins de candidats aux concours d'enseignement et le niveau baisse. Donc il va être à mon avis très difficile de recruter des jeunes profs d'informatique compétents.

Pas surprenant, en même temps, tant que le système d'affectation, indépendant des compétences, « on t'envoie à l'autre bout de la France, tu pourras peut-être revenir chez toi une fois que t'auras un ou deux enfants et donc plein de points » restera ce qu'il est. Ça attire ceux qui veulent un poste stable peu importe où, plutôt ceux qui ont la vocation, qui ont de bonnes chances d'être suffisamment déçus pour laisser tomber.

Enfin, pour ceux qui comme toi (si j'ai bien compris) veulent bien enseigner en prépas, c'est un peu plus facile (dossier puis les inspecteurs généraux font ce qu'ils veulent, donc en général ils regardent plutôt les compétences que le nombre d'enfants). Mais pour ça faut aimer l'esprit concours et les grandes villes avec une prépas, et c'est pas dit de trouver un poste dans sa région non plus.

Zbasu représente la progression logique et ordonnée, lakne est l’imprévisible et le chaotique, les deux étant considérées comme des composantes fondamentales de l’univers qui doivent se trouver équilibrées en toute chose.

Amusant que la langue sacrée de Khanat soit le lojban, ça me donne presque envie de m'y remettre : je suis bêtement resté un moment à réfléchir au lien entre les concepts du zbasu et du lakne et leur origine étimologique. J'imagine que lakne reflétant le probable est donc plus proche de l'imprévisible, vu qu'on n'est pas sûrs, alors que zbasu reflétant l'action de produire est plus proche du logiquement ordonné, genre un enchaînement d'actions dans une ligne de production, même si dit comme ça fait pas trop fantasy :-)

Ah, et j'ai écouté quelques morceaux, dont le thème principal : plutôt sympa, oui, ça commence un peu mélancolique, mais ça varie par la suite !

Les centrales ont été conçues pour tenir au minimum 40 ans avec possibilité d'allonger si les mesures et l'expérience montrent que les parties irremplaçables peuvent durer plus longtemps.

À l'origine moins de parties étaient remplaçables que de nos jours, il me semble. Mais oui, il n'y a pas de durée de vie limite fixée.

Il s'avère que c'est le cas et tous les 10 ans c'est réévalué.

Tous les 10 ans, pour un truc aussi sensible, pour un non-connaisseur, ça n'a pas l'air beaucoup.

Il n'y a donc pas de raison de se focaliser sur les 40 ans si les éléments permettent d'aller au delà. Ce serait absurde.

Peut-être bien, mais, en même temps, ça donne aussi l'impression qu'on essaie de presser au maximum. Deux interprétations sont possibles et c'est difficile de savoir laquelle est la vraie.

Ce n'est plus un impôts dont tout un chacun pourrait profiter via des services gérés par l'état, mais une rente pour certains individus.

C'est une classique de la privatisation des bénéfices : tu régules tout un système de façon publique, puis une fois que c'est construit grâce à tout le monde, si ça marche bien, tu en privatises les bénéfices.

Le fait que la française des jeux paramètre ses gains sur le fait que les joueurs vont être globalement perdants, je commence à trouver ça louche, mais après tout, je me dis que c'est juste un impôt de plus basé sur une forme de volontariat des joueurs.

Plus qu'un impôt basé sur une forme de volontariat, c'est une simple façon de profiter des faiblesses des gens, en l'occurrence l'ignorance et/ou l'addiction des joueurs. On appelle ça aussi une arnaque, tout simplement.

Quelque soit son bord politique, il me semble qu'un état et ses dirigeants sont là pour que son peuple puisse bien vivre en harmonie, avec un rôle protecteur.

C'est pour ça que tout l'argent des impôts sur le jeu était sans doute dédié à éduquer les joueurs ou les soigner de leurs addictions… ;-)

Perso, j'ai pas un accès privilégié aux données pour me faire une idée si oui ou non des solutions existent et sont suffisamment rentables, mais par contre il y a un truc qui m'interpelle :

Le stockage des déchets actuellement est fait en surface sous surveillance, ce n'est pas une solution pérenne, tout le monde le sait. Qu'on utilise temporairement une solution transitoire ne dit en rien ce qui va être utilisé pour la solution définitive…

Qu'est-ce qui nous garantit que, si une telle solution définitive existe, elle sera privilégiée même si elle est moins rentable ? J'ai l'impression que tu fais beaucoup de suppositions sur ce que feront ou non les différents gouvernements au cours des décennies suivantes.

Jusqu'à présent, ce qu'on voit, c'est qu'à l'époque où ils ont commencé avec le nucléaire, ils ont clairement privilégié les sous à court terme. Ils ont choisit cette énergie alors que la solution « définitive » pour les déchets n'était même pas encore en vue. Ils ont calculé une durée de vie pour les vieilles centrales et elle n'a pas été respectée. Alors, ok, peut-être, qu'après coup, maintenant, ils ont de meilleures solutions et de meilleures prévisions pour les centrales plus récentes (peut-être), mais au vu de ce passé non brillant, ça n'inspire pas la confiance. Si c'est moins rentable, rien ne garantit que ce seront les meilleures solutions qui seront choisies, ni que les délais seront respectées : perso, je serais déjà content s'ils choisissent des solutions médiocres, plutôt que des vraiment mauvaises.

Pour exprimer le problème que je devais résoudre en Fortran, le français me faisait utiliser de multiples fois "de". En basque, le suffixe -ren (appartenance) se met sur celui qui possède et non sur le possédé.

Ok, j'arrive à imaginer. Du type « le chien du cousin du voisin » qui devient « auzokoaren lehengusuaren txakurra ».

Pour faire un parallèle avec la programmation, c'est un peu comme la différence entre get_chien(get_cousin(voisin)) et voisin.get_cousin().get_chien(), parfois le deuxième est en effet plus naturel que le premier, car on voit d'abord l'acteur (possédeur) et après le patient (le possédé) et, une fois qu'on a le deuxième, on peut oublier le premier pour comprendre la suite, alors que dans le premier cas on doit tout garder en mémoire.

Bon, je reconnais qu'un parallèle entre basque et OO, fallait oser ;-)

Le japonais peut aussi paraître assez brutal à cause de l'alternance consonne-voyelle quasi permanent qui peut produire un effet "mitraillette", mais ça peut aussi être très mélodieux en fonction de la voix et de la façon de prononcer.

C'est surtout quand ils parlent anglais que ça donne cette impression. Sinon, personnellement, j'adore les sonorités de cette langue (après, j'aime le basque aussi, qui fait un peu aussi dans l'alternance consonne-voyelle en un peu moins extrême).

Paradoxalement, en français, je fais rarement gaffe aux sons, vu que je suis concentré sur le sens, mais les rares fois où j'essaie d'entendre plutôt qu'écouter, je trouve que ça sonne plutôt barbare, suffit d'écrire en alphabet phonétique international pour s'en rendre compte, même si « sa pøt o.si ɛtʁ me.lɔ.djø ɑ̃ fɔ̃k.sjɔ̃ də la vwa e də la fa.sɔ̃ də pʁɔ.nɔ̃.se » :-)

Quand on connait les quelques règles de prononciation du basque, on sait le lire. Il n'y a pas d'exceptions.

Il m'arrive parfois de douter lorsqu'il y a un « h » entre deux voyelles : parfois ça donne un diphtongue et parfois non. Pour certains mots de deux syllabes, c'est aussi pas évident s'il faut accentuer la première ou la deuxième (l'accent ne s'écrit pas). Après, on s'y fait assez vite, c'est généralement sur des mots courants que le doute se pose. Édit : j'oublie aussi les petites différences dialectiques, du type si il y a un « i » avant un « n » ça donne une sorte de « ñ » dans certaines régions.

Ceci dit, c'est vrai que ça fait une liste très très courte de cas problématiques, par rapport au français ou encore pire l'anglais.

Suivant la langue il y a toujours certains trucs qui se disent plus ou moins facilement (genre « ganbarou! » en japonais qui signifie « faisons du mieux que nous pouvons ! »), mais au point d'avoir une influence significative sur un problème algorithmique, je n'aurais pas imaginé (surtout que je me débrouille à peu près justement en euskara).

Après, personnellement, je pense que pour l'algorithmique j'utilise plus la visualisation dans ma tête, mélange d'images de graphe avec nœuds et flèches et pseudo code avec un peu de subvocalisation, et moins une langue particulière, du coup j'imagine que ça dépend aussi beaucoup de la façon dont une personne approche le sujet.

Je ne sais pas trop ce que tu entends par déclinaisons très précises : c'est pas vraiment très différent qu'utiliser les prépositions correctement en français, ça sert relativement le même but (rôle sémantique d'un groupe nominal dans la phrase), avec possiblement moins d'exceptions. L'ordre des mots est plus « tête à la fin » (head final), plus comme en japonais (sauf qu'avec changement de place pour les questions ou focus et une exception pour les adjectifs qui viennent après le nom tête). Je peux imaginer que parfois ça peut aider à ne pas perdre de vue l'important avant la fin, puisqu'il vient en dernier.

Après, le truc dont généralement tout le monde parle à propos du basque, c'est les verbes, où des choses comme « Je le lui ai » dans « Je le lui ai donné » font partie intégrante de l'auxiliaire « eman diot », mais au fond ça rend le basque juste un peu plus concis (en nombre de mots).

J'ai connu un professeur d'université qui selon le problème à résoudre raisonnait soit en chinois soit en français (ou anglais, c'est équivalent).

Mais du fait de particularités de la langue ou parce qu'il était plus habitué à un gérer un type de problème particulier dans une langue donnée ? Je veux dire, pour l'informatique, je vais souvent avoir tendance à penser des mots en anglais, pour les maths en français, et pour plein de choses de la vie de tous les jours en espagnol, mais j'aurais dit que c'est juste l'habitude.

maîtresse ça renvoie à institutrice ce qui est moins prestigieux

Le vrai souci à la base, c'est justement la hiérarchisation des fonctions : si elle disparaît, celle qui te gêne spécialement disparaitrait aussi (alors qu'on a pas vice-versa). Sauf que pour ça, il y a vraiment des trucs à faire, car pas mal de monde se plait au fond dans un système hiérarchique, espérant grimper un jour au-delà de la moyenne ou ne voulant pas descendre.

Pense plutôt « éw » avec un « w ». Un diphtongue c'est une « fusion » de deux voyelles. Pour une déf plus technique, wikipédia.

C'est un son assez courant, écrit « eu » en basque ou espagnol, pas en français.

Je comprends ce que tu veux dire, mais une solution n'empêche pas forcément les autres : une langue naturelle, c'est pas comme un langage de programmation ou l'on peut décider de l'introduction d'un nouveau mot-clé ou pas pour éviter qu'il y ait plusieurs façons de faire une même chose. De la même façon que des tournures alternatives apparaissent, des mots nouveaux peuvent apparaître et disparaître aussi.

Après, les considérations subjectives sur la sonorité du mot en question… le futur dira ce qu'en feront les gens, ils finiront peut-être par prononcer ésou, ou bien étou (pas impossible, héhé), ou bien le diphtongue «éou» (peu probable en français, car inexistant actuellement), ou bien encore héroïquement le éhou d'origine. Ou le mot ne survivra pas à l'usage et disparaîtra :-)

je préfère faire une périphrase dans le genre tu vas à la piscine lundi, mardi ou les deux jours ?

Oui. Après, dans la vie réelle, il y a d'autres possibilités : « C'est quand que tu vas à la piscine ? » (question plus ouverte même si on sait que ça peut être que les deux premiers jours de la semaine) ou « Tu vas à la piscine lundi et mardi ? » (on tente un truc, la réponse nous dit si en fait c'est pas les deux jours et juste l'un des deux), ou « c'est quel(s) jour(s) que tu vas à la piscine ? » (versions pluriel identique à l'oral en pratique).

s'il peut s'écrire, il doit bien avoir une façon de le dire

Pas forcément, on est habitués à plein de lettres qui ne se prononcent pas dans notre écriture. Faudrait faire un sondage :-) Personnellement, quand je lis, je subvocalise souvent et le et/ou dans ma tête c'est éhou, en deux syllabes (sans diphtongue).

le simple fait de faire crasher un service peu déjà être une exploitation grave de la faille.

Oui, mais à ce niveau tu as ce même problème qu'avec un langage ayant des vérifications à l'exécution pour l'accès à un élément de tableau, par exemple rust. Après, ça a peut-être plus de chance d'être détecté par chance dans les tests. Et les itérateurs etc. réduisent un peu le nombre de ces cas pour les boucles simples. Ceci dit, on pourrait imaginer (à tort peut-être) qu'on se plante plus facilement dans les cas justement un peu moins évidents où on a besoin, quel que soit le langage, d'écrire l'index à la main et, donc, de risquer un crash.

Je mets de côté le cas où on dispose d'une preuve formelle mécanique que l'accès est valide, ce qui reste encore laborieux et peu accessible, limité à des langages plutôt académiques ou de niche.