anaseto a écrit 2229 commentaires

Elle a ainsi l'avantage d'être facilement parsé par l'informatique, je me demandais si cela pourrait aider dans "l'open law" pour rendre compréhensible la loi automatiquement ou des specs…

Le soucis, c'est que l'on n'a pas d'ambiguïté syntaxiques, mais il nous reste les ambiguïtés sémantiques (même si chaque mot n'a qu'un sens comme en lojban ou toaq, il peut être vague/vaste), donc l'interprétation humaine joue toujours un rôle.

Sinon, je me demandais aussi si on pouvait réinventer la langue écrite française, en écrivant ce que l'on entend et en réduisant au minimum le nombre de règles et autres exceptions, tout en le gardant lisible pour le commun des mortels (pas de nouvelles lettres, etc…)

Si on écrit ce que l'on entend, on obtient plusieurs langues suivant les personnes :-)

Si on se limite au français d'une seule personne, ou qu'on autorise les différentes variantes, une écriture phonétique permet d'obtenir exactement le minimum de distinctions qui sont faites à l'oral ; en pratique, on veut une écriture phonétique simplifiée, car il y a toujours des petites différences de prononciation suivant la position dans un mot etc. qu'on ne veut pas distinguer à l'écrit car ça ne nous aiderait pas à distinguer mieux les mots. Au mieux on veut le résultat le plus simple qui permette de distinguer les mots qu'on distingue à l'oral, en pratique on veut même moins que ça (on perd des intonations etc. qui changent le sens des mots et regroupe plusieurs sens différents à l'oral sous un même mot écrit).

Si on veut que ça marche pour un groupe plus gros, l'idée serait plutôt d'éliminer toutes les règles pour lesquelles aucun locuteur ou presque ne fait la distinction : par exemple, les verbes du premier groupe à l'indicatif présent n'ont que trois formes distinctes, au lieu des cinq artificielles de l'écrit. Pour les exceptions, ça les fera pas toutes disparaître non plus, à moins que ce soit des exceptions purement écrites (du fait des plusieurs façons d'écrire un même son ou d'un découpage particulier en mots), mais l'approche qui en supprime le plus, c'est celle autorisant les différentes formes qu'on entend (en d'autres termes, beaucoup de « fautes » courantes n'en seraient plus).

Après, il reste que si on pousse à l'extrême, on a plus d'homonymes, donc c'est potentiellement plus difficile à lire pour quelqu'un d'habitué, mais ça reste à prouver que l'effet est significatif et que les endroits où on choisit d'introduire des différences actuellement sont les plus utiles : « je chante » vs « tu chantes » apparait comme une différence introduite par l'écriture plutôt redondante et inutile, si on considère que pour d'autres trucs qui s'écrivent pareil de nos jours (tous les mots ayant plusieurs sens), c'est bien plus difficile et on se débrouille avec le contexte sans introduire des variantes d'écriture pour chaque sens, alors que ça aurait peut-être été plus utile. Un autre exemple de distinction historiquement mal placée, c'est pour les liaisons : linguistiquement, la liaison s'accroche au début du mot suivant, donc on devrait écrire « il z'ont » (ou quelque chose comme ça) plutôt que « ils ont » (en français il n'y a qu'un seul pronom troisième personne commun pour singulier et pluriel). D'ailleurs, l'écriture actuelle des liaisons a pour résultat que les gens finissent par douter quand il faut faire une liaison ou non. Mais, suivant les cas, la liaison, on l'aura 100%, 0% ou 50% du temps, pas de réponse absolue en général, donc deux écritures et sons possibles pour la même chose. Bref, l'écriture c'est compliqué, même si clairement on peut faire mieux :-)

Oui, c'est sympa pour débuter la lecture. L'idée d'avoir deux niveaux (en cliquant ou non) est pas mal. Et comme c'est manuel pour rentrer les textes, on pourrait appliquer ça à n'importe quelle langue.

J'ai vu cette approche pour d'autres langues (il me semble que sur lernu.net sur certains textes on avait la traduction des mots en passant la souris, mais ça a changé beaucoup, je sais pas comment c'est maintenant). Pour le japonais il y a un plugin navigateur (rikaikun) qui fait un truc similaire pour les mots, sauf qu'automatique donc vu les ambiguïtés, ça sort toute une liste des possibilités, pas forcément la bonne en premier, donc le travail est moins mâché ; mais c'est quand même sympa.

Il y a plein de jeux où on limite se qu'on peut faire/dire avec les mots ou autre (genre chaud/froid pour trouver des objets, ou le jeu dont je connais pas le nom en français où il faut deviner un objet avec des questions oui/non, ou les jeux où il faut faire deviner un mot sans utiliser certains mots etc.) et c'est justement les restrictions qui nous poussent à réfléchir à des chemins plus compliqués (et rigolos) d'arriver à communiquer quelque chose (donc exercice intellectuel intéressant).

J'aimerais bien plonger un peu plus dans l'ithkuil aussi, pour le moment je me suis contentée de la survoler et vu la complexité du langage, ça sera pour quand je n'aurais plus rien à faire ;)

En découvrant ithkuil au début j'étais émerveillé, car c'est vraiment une mine avec tous les cas grammaticaux possibles et imaginables dans une même langue… mais comme langue, c'est pas trop ça (du pur délire pour dire les choses vraiment ! ^^), même son créateur n'arrive pas à le parler aux dernières nouvelles :-)

C'est d'ailleurs un souci de façon général sur la plupart des conlangs : on trouve une grammaire rédigée pour les linguistes et un dictionnaire, mais les méthodes d'apprentissages en ligne sont souvent médiocres, voir inexistantes, ou alors adaptées à une certaine catégorie de population (ceux qui aiment anki, ou ceux qui sont linguistes).

Ça, c'est assez vrai : la plupart des conlangs n'ont pas de bonnes ressources pour être apprises. L'Espéranto est un peu une exception, et encore, ça pourrait être mieux dans le domaine de l'audio (quand même l'objectif quand on apprend une langue a priori), il manque un cours audio (et en diverses langues) vraiment sympa (on trouve plein de trucs/vidéos/etc., mais c'est un peu chaotique). Si c'était pas du fait du lien théorique facile entre écriture et prononciation (et une prononciation relativement simple — qui n'empêche pas qu'aux premières pratiques d'écoute il faut accoutumer l'oreille aux différents accents/débits/styles), j'aurais eu plus de mal à m'en sortir. À l'époque j'ai initialement utilisé la méthode lecture en masse (recherche dans dico seulement si nécessaire pour comprendre le sens général, ou pour ce qui semble intéressant) jusqu'à ce que ça rentre : pas de flashcards, juste un peu de grammaire au début sur wikibooks et wikipédia en français, puis Gerda Malaperis, puis tous les contes pour enfants (andersen, magicien d'oz etc.) que j'ai pu trouver, puis après tout ce que je trouvais qui n'étais pas trop indigeste :-)

Après, la meilleure méthode dépend de l'objectif (découvrir la grammaire/l'essence de la langue, ou bien vraiment apprendre la langue). Si l'objectif c'est vraiment apprendre une langue (au moins au point de la comprendre quand on écoute), il n'y a pas vraiment de méthode miracle (il y en a des mauvaises ceci dit) : il faut pratiquer un peu tous les jours (pas un jour par semaine comme à l'école), de plusieurs façons (pas juste grammaire ou juste audio/vidéo ou juste lecture), idéalement faire ce qu'on a le plus envie sur le moment.

Honnêtement, la grammaire est probablement pas le premier truc sur lequel il faut se focaliser (au-delà d'une courte intro), même si c'est contre-intuitif (quand on apprend la grammaire au début on a l'impression de progresser plus vite, sauf qu'en fait je doute que ça joue beaucoup à long terme). Au début audio et essayer de lire des trucs faciles, même si on comprend pas totalement grammaticalement, c'est motivant tant qu'on est pas perfectionniste (c'est ce que font les enfants après tout et ça marche). Passé le premier stade, lire régulièrement un peu de grammaire a souvent un côté sympa où on se dit, ah, tiens, je comprends mieux maintenant cette phrase où j'avais du mal à connecter les pièces, et puis après faut juste continuer un peu (genre au moins une demi-heure) tous les jours (ou au moins plusieurs par semaine, faut pas non plus se forcer). L'idée c'est de se dire tous les jours, positivement, tiens, j'ai appris quelque chose, sans trop réfléchir à long terme.

Et anki/etc., ça peut être utile (surtout pour certains trucs spécifiques comme les kanjis en japonais, ou retenir du vocabulaire moins courant), mais, à mon avis, faut vraiment voir ça comme un outil complémentaire parfois très utile (rentrer manuellement des trucs importants qu'on veut pas oublier), pas comme une solution miracle indispensable (il y a plein de monde qui apprend des langues très bien sans), et je conseillerais pas généralement d'utiliser des flashcards déjà toutes faites sans aucune valeur émotive pour soi.

C'est dommage, ça fait partie de la langue française.

Je suis d'accord que lutter contre l'existence de vocabulaire spécialisé est absurde (autrement que comme jeu), mais en lisant tes divers commentaires, il y a un point qui me chatouille : tu sembles considérer que la langue française (ou tout autre langue que tu qualifierais de non artificielle) existe indépendamment des personnes qui la parlent, comme si c'est la même pour tout le monde. L'appartenance d'un mot à la langue d'un groupe d'individus n'est jamais absolue, un mot peu appartenir « un peu » ou « beaucoup » à une langue et pour déterminer le degré le linguiste doit demander aux locuteurs et, suivant les régions/quartiers/familles, il va y avoir des réponses variables.

Le mot « accastillage » est probablement moins français que le mot « cool », car moins de personnes parmi celles qui parlent un dialecte français l'utilisent ou le connaissent. Un mot n'appartient à une langue que tant qu'il est utilisé et reconnu par les locuteurs. Du fait du suffixe « -illage » beaucoup de locuteurs diront que ça à l'air assez français, donc « accastillage » est un mot assez français, peut-être plus que « adio » suivant les régions, mais moins que « salut » qui doit être connu et utilisé par quasiment 100% des locuteurs de dialectes français.

Même lorsqu'un mot est reconnu par deux locuteurs, son sens peut ne pas être tout à fait le même et être source de nuances. Le concept de langue est une simplification pour définir à peu près de quoi on parle, mais des langues, il y en a autant que de personnes (plus, puisque chaque personne peut en apprendre plusieurs).

D'ailleurs, un point qui découle de toute ceci, c'est que toute langue parlée par des locuteurs natifs est naturelle (donc un dialecte parlé du français, l'Éspéranto ou même du lojban, c'est naturel, alors que le toki pona par contre n'a pas de tels exemples), et ce même si la langue officielle ne l'est jamais, qu'elle tente de décrire une langue d'origine artificielle ou non (dans les deux cas créées par des êtres humains, sauf que dans le deuxième cas sans faire exprès).

En tant qu'amoureux des langues, je pense qu'utiliser une langue artificielle a à peu près autant d'intérêt que d'être en couple avec une poupée gonflable.

Toki pona n'est pas une langue pour la communication internationale pratique et n'a jamais été pensée pour cela (contrairement à ce que le journal pourrait laisser penser). Une langue dont le nombre de mots est limité (encore que pas tout à fait vu qu'on peut combiner, mais passons) est un jeu, pas une tentative de créer une langue naturelle. On invente tous régulièrement des mots en famille ou entre amis, certains éphémères d'autres non, l'évolution lexicale (et grammaticale aussi), c'est un truc de base dans une langue et la créatrice de toki pona, qui travaille dans le domaine des langues je crois, le savait sans doute bien. Ça ne veut pas dire que la langue n'a aucun intérêt.

Dit en passant, certaines langues d'origine « artificielle » comme l'Espéranto (qui a plus de locuteurs que le basque probablement), mais avec une volonté d'être le plus proche possible d'une langue naturelle, évoluent naturellement sans restrictions et ne sont désormais pas plus artificielles (au sens linguistique) que ce qu'on appelle les langues naturelles. Elles ont autant d'espoir d'être utiles (dans les contextes appropriés) que les autres. Je parle de l'Espéranto parlé et des langues naturelles parlées, pas des tentatives de normalisation et dictionnaires qui, par nature, décrivent toujours une langue artificielle dont le but n'est pas d'être la langue naturelle réelle, mais un standard, tout comme http, sauf que moins bien défini car c'est des sciences humaines.

Pour en revenir à l'intérêt d'une langue vraiment artificielle (comme toki pona), c'est très simple, c'est le même que celui de n'importe quel jeu : s'amuser, sociabiliser, entrainer son cerveau à résoudre des petits défis intéressants. Comme tout jeu, il peut avoir des conséquences positives sur le reste, entre autres ici nous rendre plus efficaces pour apprendre d'autres langues.

Personnellement, je pense que les langues artificielles (toki pona, lojban, etc.), de part leur nature simplifiée, font découvrir les joies d'apprendre une nouvelle langue plus facilement que la façon assez à la ramasse (par rapport à l'état de l'art en recherche dans le domaine) avec laquelle sont souvent enseignées les langues dans l'enseignement secondaire. Elles ont conduit pas mal de monde sans passion pour les langues (voire frustrés par des mauvais souvenirs à l'école) vers le courage de se lancer vraiment.

En tous cas, avant d'apprendre l'Espéranto, jouer un peu avec le toki pona, le lojban, toaq et lidepla, je parlais juste mes deux langues maternelles (français et espagnol) et un anglais au mieux médiocre. Depuis, grâce à la motivation et diversité apportée par ces langues, j'y ai pris goût, je suis devenu plutôt bon en anglais, je me débrouille assez bien en basque, je suis capable (avec dico et des efforts) de lire un manga en japonais et j'ai plus aucune peur à l'idée de tenter de lire en devinant les langues similaires à celles que je connais (comme le portugais ou le catalan).

Tiens, je viens d'avoir une idée pour améliorer un peu :-)

    echo u:65+('O'&=#27|i.@#)fread'input.carte'
LETTRES

Plus court et plus intuitif (mais c'est facile à dire après coup :p), ça fusionne deux étapes : maintenant il reste juste la création d'un tableau de même taille avec les numéro de colonne (27|i.@#) avec sélection via # des cases où il y a un O ('O'&=).

Et, en pratique, on peut enlever le “echo” si on écrit ça dans l'interface en ligne de commande et pas dans un script.

Bon, faut dire que ça faisait longtemps que je m'amusais pas avec du J ;-)

En J, successeur modernisé d'APL, ça donne :

    echo u:65+(#~0~:])((27|i.@#@])*'O'=])fread'input.carte'
LETTRES
    perl -ne'while(/O/g){print chr(65+$-[0])}' input.carte
LETTRES

S'il y a moyen de faire mieux, ça m'étonnerait que ça soit beaucoup plus, donc au final même longeur en caractères, mais surtout c'est beaucoup plus long d'un point de vue sémantique. Les transformations fonctionnelles successives de tableau nous forcent à tout garder en tête avant d'avoir un truc, contrairement au style impératif qui nous permet de gérer les étapes au fur et à mesure comme dans la description intuitive « à chaque fois qu'on tombe sur un 'O', on affiche la lettre correspondant au numéro de colonne ».

Le code J, par contre, est moins intuitif à expliquer : on construit un tableau identique à la chaîne de caractères de la carte mais avec des 1 à la place des O et des 0 à la place de tout le reste ('O'=]), ensuite on multiplie ça avec un tableau de même longueur construit avec des indices croissants (fonctions composées i.@#@]) modulo 27 (fonction |) pour les retours à la ligne, puis on sélectionne avec la fonction copy #~ (similaire à filter ici) les cases différentes de 0 (0~:]), qui correspondent aux cases où il y avait un O (faut suivre le fil des transformations !), puis on ajoute 65 pour avoir les numéros des caractères, pour enfin appliquer u: au résultat et obtenir les caractères à partir des numéros.

Pour ce genre de trucs, je préfère un langage prévu pour ça comme Perl :-) La charge cognitive du code perl est beaucoup moindre pour quelqu'un qui s'y connait dans les deux langages, je pense (même si je pourrais pas totalement l'assurer vu que je suis pas un expert en J non plus).

Je fais pas de calcul intensif. Ceci dit, je pense que le code fortran compilé ne fait des appels libc que pour les interactions avec le noyau et le système, pas pour les fonctions utilitaires a priori, donc pour du code faisant du calcul intensif, ils ne représentent probablement pas grand chose du code qui est compilé surtout en « des instructions en langage machine directement exécutées par le processeur », pour reprendre le premier point plus haut. Donc peu importe le choix de la libc (glibc, musl, celle d'un des bsd ou autre), la performance ne devrait pas être impactée.

On s'est mal compris : bien sûr qu'en Go tu dois définir une interface statiquement dans ce cas pour éviter un cast.

Ce que je veux dire, pour résumer, c'est qu'il y a deux cas : soit le système de type de Go permet de gérer le cas (comme dans ton exemple), soit le système de type n'est pas suffisant et il faut faire façon Ruby. Dans le deuxième cas on a un cast (explicite en Go avec gestion d'erreur possible, implicite en Ruby avec exception si échec), dans le premier cas on peut éviter le cast (en Go, jamais en Ruby) avec un peu de code en plus (définir l'interface).

En d'autres termes, Ruby c'est conceptuellement proche d'un équivalent de Go avec comme unique type statique interface{} et plein de sucre syntaxique. Pour regarder à l'intérieur d'une variable Ruby, il y a toujours une tentative de cast implicite pour toute action qui ne soit pas totalement indépendante du type.

Donc généralement tu va utiliser un type prédéfini qui possède potentiellement des trucs dont tu n'a pas besoin.

Je vois pas trop à quoi tu fais référence ici.

Mais ça ne fait pas pour autant un cast.

C'est parce que tu penses à l'objet contenu directement (d'ailleurs je parle avant d'objet aussi quand je devrais pas), plutôt que penser variable (le type fourre-tout, à comparer à interface{}). Il n'y a pas de cast explicite, mais dans l'abstrait (peu importe l'implémentation) on peut voir ça comme un cast d'un type implicite qui contiendrait tous les objets (d'un point de vue statique on ne sait en général rien sur le type de l'objet contenu dans une variable, donc interface{}), vers le sous-type des objets qui ont une méthode foo (implicitement défini en Ruby) afin d'appliquer la méthode, avec exception runtime si ce cast échoue (le contenu de la variable, c'est-à-dire l'objet caché derrière interface{}, n'est pas d'un type compatible).

En Go quand on appelle une méthode sur une interface comme en Ruby quand on appelle une méthode, le runtime va regarder une table de méthodes virtuelles pour trouver le code à appeler (ou plusieurs tables s'il y a des question d'héritages).

Ça c'est l'implémentation de l'appel, oui. Mais l'interprétation en terme de typage nous dit qu'en Go un appel méthode n'a pas besoin de faire de cast (on sait statiquement que le type de la variable est compatible avec cet appel méthode), alors qu'en Ruby on part toujours de l'équivalent interface{}, l'unique type statique de toutes les variables en Ruby, qu'on a besoin de caster vers un type (implicitement défini, pas vraiment dans le langage) à chaque appel.

C'est mon point : il est bien plus frustrant de perdre quelque chose que l'on a que de ne pas l'avoir.

C'est un argument qui se défend, plutôt du côté ressenti humain subjectif (frustration) que technique. Je pense que cette source de frustration est en effet assez répandue et a tendance à polariser les langages : le langage dynamique a peur de perdre en flexibilité/pureté en introduisant du statique, le langage statique a peur de perdre en garanties/performances/pureté en introduisant du dynamique.

MyFnc() ne cast pas

En Go ton exemple ne cast pas, vu que c'est exactement un cas d'application d'interface, comme tu le précises, et que l'appartenance ou non à une interface est résolut statiquement. L'interface doit, effectivement, être écrite manuellement explicitement (ici une interface contenant une seule méthode foo() string) contrairement à Ruby où tout est implicite.

Par contre, sauf erreur, en Ruby ton exemple fait un cast que tu n'as pas vu : site.foo() donnerait une erreur runtime si tu passes un objet sans cette méthode. Du moins, ce serait le cas en Perl ou Tcl, je ne sais pas si Ruby fait du typage statique pour valider les appels méthode de classes, a priori non si Ruby résout comme Perl les appels méthode au runtime de façon dynamique, mais je connais pas bien Ruby.

c'est très frustrant pour le développeur de perdre l'information de type juste à cause du système de type.

Information que tu n'as pas statiquement à la base dans un langage à typage dynamique, donc impossible à perdre. Tu n'es pas plus obligé de gérer les “cas inutiles” que dans un langage dynamique : si tu es confiant, tu peux traiter que le cas qui est censé arriver, avec panic sinon (comme dans un langage dynamique). Tu as le choix d'écrire ton code de façon plus défensive, mais c'est pas une obligation (ni même toujours recommandé).

Dans les langages dynamiques il y a des casts aussi, ils sont juste implicites et partout, ce qui apporte plus d'ergonomie et de flexibilité (moins de contraintes comme tu dis), mais aussi justement moins d'info quand on se plante, voire des erreurs silencieuses (cast inattendu mais valide). Go a toute l'information qu'il faut sur ses types “dynamiques” au runtime. Quand je dis que Go a une partie dynamique, c'est pas vraiment d'un point de vue du typage : techniquement parlant Go est 100% statique pour ce qui est du typage en soi, car les casts explicites sont typés (tant la source que le retour), de la même façon qu'une fonction StringToInt dans un langage quelconque renvoyant Int ou une erreur peut être typée statiquement. C'est pas comme un cast en C qui doit impérativement être correct sous risque de faire des trucs unsafe : en Go un cast est safe (d'un point de vue typage), encore plus qu'au sens d'un accès tableau en Rust/OCaml/etc, car on a le choix de gérer le cas d'erreur.

J'achète pas trop non plus l'argument manichéen qu'il faudrait être 100% statique ou 100% dynamique (au sens large). Aucun langage n'est totalement ni l'un (à part l'assembleur peut-être) ni l'autre (outre Coq et compagnie) : les langages à typage statique ont généralement des tests dynamiques pour les accès tableau (avec panic), pour certaines fonctions de marshalling/sérialisation, parfois via réflection (Java ou Go, donc typé statiquement même si dynamique) ou carrément type unsafe (OCaml), exceptions qui échappent au système de types (OCaml et plein d'autres), etc. ; les langages dynamiques offrent parfois un minimum de typage statique pour différencier certaines choses (une fonction d'une variable, voire dans certains langages comme Perl, un tableau d'un scalaire). À mon avis, avec Go, il est prévu par le langage d'utiliser des checks dynamiques pour les cas nécessitant un système de types plus complexe, au même titre qu'en Ruby il est prévu que tout soit dynamique.

Entre dynamique et statique il y a tout un monde : comme mentionné plus haut, même Rust évite un système de types plus complexe qui permettrait d'éviter des checks runtime pour les accès tableau. C'est une question de juste milieu : on sait que les extrêmes sont pas vraiment pratiques pour les usages courants (du genre Coq vs Assembleur), mais par contre il n'y a pas de réponse définitive pour dire où le juste milieu doit se trouver pour un langage généraliste.

tu perds le typage statique et les casts rendent la lecture du code assez moche, je trouve.

Une vision plus positive de la même chose serait : si on veut vraiment filter ou any en Go, on peut du moment qu'on accepte que cette partie du code ait les mêmes garanties qu'en Ruby :-) Quand à la mocheté des casts explicites obligatoires, elle a un avantage : on a plus de chances de repérer les erreurs que dans un langage dynamique aux casts implicites.

Après, il y a quand même un soucis en vrai : on ne peut pas facilement écrire Any avec la signature func(interface{}, func(interface{}) bool) bool, le mieux qu'on puisse faire c'est func([]interface{}, func(interface{}) bool) bool, ce qui force à transformer tout tableau en []interface{} ce qui n'est pas possible avec un cast : il faut céeer un nouveau tableau ou se limiter à utiliser Any pour les tableaux contenant des interfaces.

L'alternative, c'est d'utiliser reflect et d'écrire les fonctions spécialisées (générées automatiquement ou pas) et les utiliser dans la fonction générique, mais du coup, si on a déjà les fonctions spécialisées, le gain à utiliser la fonction générique à base de reflect est très discutable (on perd typage statique et performances pour au final possiblement aucune factorisation de code).

any? ici est une fonction qui renvoie vrai si un des éléments de la liste/tableau renvoie vrai pour un certain prédicat. Sans généricité, c'est impossible d'écrire un telle fonction qui marche pour des listes de n'importe quel type et les interfaces ne couvrent pas ce genre de cas. Le plus proche de any? qu'on puisse faire, c'est quelque chose comme (pas testé bien sûr) :

func anyInHayStack(haystack []couchdb.DocReference, pred func (couchdb.DocReference) bool) bool {
    for _, ref := range haystack {
        if pred(ref) {
            return true
        }
    }
    return false
}

C'est proche de la fonction de Bruno en un peu plus général. Note en passant, cette généralité a peu de chances d'apporter grand chose si c'est utilisé toujours avec le même prédicat et, en un certain sens, la version Go de Bruno est plus lisible que la version Ruby justement du fait que le prédicat plus technique se retrouve dans une autre fonction plutôt qu'inline dans le corps de l'autre fonction. On pourrait voir ça comme un argument en faveur du fait que les limitations de Go nous encouragent parfois à écrire du code plus accessible.

Pour en revenir à nos moutons, on n'a pas moyen de rendre la signature plus générale et les interfaces vont pas pouvoir nous aider ici. Tu ne peux même pas définir l'interface dont la méthode serait Any(func (type de l'élément) bool) bool pour le type []couchdb.DocReference, car type de l'élément devrait être paramétré. Même si l'interface était possible à définir (généricité partielle juste pour les types des méthodes des interfaces), la méthode à définir pour chaque type satisfaisant l'interface serait la fonction que justement on voudrait écrire qu'une seule fois à la base.

Hehe, vu qu'aucun langage non exotique (donc j'exclu idris et compagnie) ne peut prévoir les accès tableaux incorrects dès la compilation, et que la solution C ou assembleur conduit souvent à un segfault (ou pire), il ne reste plus que la solution Perl : renvoyer un undef sans protester :-)

Oui, en Go on n'a pas d'autre choix que de réimplémenter any? pour chaque type de liste qu'on utilise, je suis d'accord, j'ai juste pas l'impression que ça représente en pratique une partie significative ni délicate du code. C'est un manque qu'on constate forcément à un moment ou un autre, mais son impact me semble souvent plus moral qu'autre chose (comparaison inconsciente avec les langages qui ont cette fonctionnalité).

Il y a des fonctions qui me semblent plus délicates donc problématiques à recoder pour lesquelles la généricité serait plus bienvenue (par exemple des fonctions génériques utilisant les channels).

Pour les structures de données, je suis d'accord que ça serait parfois sympa et ergonomique et éviterait quelques répétitions. Après, ça a un certain charme de se dire que quand on voit quelque chose qui ressemble à un map ou un array, c'est exactement ça, pas d'abstractions surprise : ce manque de structures a un côté positif, même si pas évident à mesurer.

Par contre, je vois pas trop ce que tu entends par les panics avec map et array : que je sache, même en Rust/OCaml/etc., si on fait un accès hors du tableau, on a un panic. Le seul truc améliorable qui me vient à l'esprit avec un système de types plus complet (sans compter les vraiment complets avec types dépendants) et qui m'est déjà arrivé, c'est un map non initialisé, mais c'est le genre de truc qu'on détecte et corrige plutôt vite (contrairement à un accès hors tableau).

le langage n'évolue quasiment plus et on n'a toujours rien pour écrire des fonctions map ou filter, c'est très frustrant.

C'est curieux, dans les trucs qu'apporterait la généricité, c'est un point qui revient souvent, alors que perso les fonctions map ou filter c'est vraiment pas le truc qui me manque, car en pratique ça apporte pas grand chose par rapport à une boucle : (à mon avis) à peine plus concis, moins flexible, deux façons d'arriver au même résultat pour un gain en clarité très débatable. Je dis clarité débatable, car un des trucs qui m'a souvent gêné dans le style filter/map/fold etc, c'est que dans ce qu'on trouve dans la nature, ça a tendance à partir dans des fonctions d'itérations lambda inline sur plusieurs lignes avec le nom de la structure qu'on itère perdu à la fin, alors que c'est la première chose qu'on veut voir en général.

Eh bien Frundis est toujours là ! :-) Plutôt stable avec de petites améliorations de temps en temps. Dernièrement, par exemple, remplacement automatique des apostrophes dactylographiques par les typographiques, ou encore amélioration de l'affichage des poèmes dans la version EPUB (en particulier pour les vers trop longs) et quelques autres petits trucs.

Si les premiers euros ne sont pas imposés, c'est entre autre parce que la TVA existe.

Pas vraiment : quand tu n'es pas imposable, ça veut juste dire que tu ne paies pas d'impôts sur la partie très réduite de ton salaire qui te parvient après que l'employeur déduise toutes les charges diverses de ton salaire. En vrai, les premiers euros sont toujours imposés, c'est juste que dans le cas particulier du salarié on a réussi à lui faire croire qu'il ne paie pas d'impôts quand il est pauvre. Les non-salariés savent bien que, même en étant pauvres au point d'être au RSA, ils payent un pourcentage pour les premiers euros.

La TVA, c'est un peu la cerise sur le gâteau, s'appliquant de nos jours mêmes aux besoins de première nécessité.

Après, on fait parfois croire au pauvre qu'il ne paie pas vraiment d'impôts, car il reçoit des aides, donc ce serait même le contraire. La réalité, c'est que quand tu es vraiment pauvre, la société te fait plus payer directement au privé. Les aides publiques sont le moyen qui a été développé pour rendre une situation précaire soutenable, détourner l'argent public vers le privé et rendre possible le fait d'être sous-payé dans une société où les prix des besoins de première nécessité sont artificiellement gonflés.

Ça serait plus intéressant de savoir quel est le revenu qu'ils tirent de ce patrimoine (ça va aussi être beaucoup, mais ça va être moins disproportionné que les écarts de patrimoine; par exemple, si tu as 1 Mrd € de patrimoine qui te rapporte 3%, ça te fait 30 millions de revenus par an. Le revenu médian en France est d'environ 19k€/an, le patrimoine médian est à 114k€; avec notre milliardaire théorique, ça fait un rapport d'environ 1/1500 en revenu, et d'environ 1/9000 en patrimoine. Donc, il y a en gros un ordre de grandeur entre les deux; c'est sûr qu'on choque plus le pékin moyen en faisant les rapports de patrimoine que les rapports de revenus.

Je suis d'accord que comparer les chiffres de patrimoine tel quel c'est pas très parlant. Pour moi, un vrai calcul se ferait sur le revenu en soustrayant la partie dépensée pour les besoins primaires. Donc, par exemple une personne gagnant 1000€/mois et devant dépenser 900€/mois sur des besoins primaires (au pifomètre, ça peut varier beaucoup en plus ou moins suivant la taille de la famille, où on habite, ses dettes, sa santé, etc.) peut utiliser 100€/mois sur des besoins superflus (loisirs) ou pour économiser. À côté, celui avec le salaire médian de 1700€/mois (à peu près de mémoire) a 800€ (sous les mêmes circonstances) pour des besoins non primaires/économiser, donc gagne en fait 8 fois plus. Donc celui qui gagne 30 millions par an, arrondis à 30 millions une fois qu'on enlève les besoins primaires, gagne 300 000 fois plus que celui à 1000€/mois (en vrai 100€/mois), presque 40 000 fois plus que celui à 1700€/mois (en vrai 800€/mois). Ça me semble être un ordre de grandeur ayant plus de sens que celui que tu donnes et plus réaliste quand aux inégalités de revenus en pratique.

Ça illustre aussi qu'on ne néglige pas uniquement la différence entre celui qui gagne des millions et le pauvre, mais aussi beaucoup les inégalités réelles entre celui à 1000€/mois et 1700€/mois, qui dépassent potentiellement de beaucoup le facteur 1.7 étant donné un contexte similaire par ailleurs.

Ayant appris à lire comme ça, je ne me sens nullement perturbé par la lecture de ce genre de textes.

Ce qui nous manque pour rendre plus facile la communication au sujet de cette méthode de lecture intéressante mais trop méconnue, c'est un terme moderne pour s'y référer. En hommage à certains efforts concurrents dans le domaine apparenté de l'écriture, je propose celui-ci : la lecture inclusive :-)

Par contre il y a un problème grave, qui nécessite un professeur : l'apprentissage de la langue et de l'écriture, c'est la base d'une culture. Il y a des classes avec des élèves qui savent à peine parler le français, ou même le lire. Va élever le niveau avec ça.

Tu te focalises sur ça : moi je dirais que c'est un des rares points sur lesquels on a progressé. Avant, les gens apprenaient à écrire sans fautes d'orthographe et de grammaire quitte à négliger le reste. À l'époque de mon arrière grand-père, les gens faisaient beaucoup moins de fautes et écrivaient avec une belle calligraphie, c'est sûr, mais la plupart faisaient des études plus courtes aussi : écrire et compter, puis un peu d'histoire et de géographie et voilà. Aujourd'hui la plupart des jeunes s'intéressent moins à classifier les personnes selon leur niveau de conformité à un système d'écriture, libérant ainsi du temps pour d'autres trucs avec un peu de chance plus créatifs (malheureusement la chance n'est pas toujours là, mais bon).

Évidemment, piège classique pour l'être humain, celui qui a subi le système précédent a tendance à affirmer sa supériorité dans son domaine de spécialisation de l'époque (l'écriture sans fautes) et négliger les points sur lesquels il est inférieur à la nouvelle génération, tout en essayant de faire passer son sentiment aux naïfs de la nouvelle génération afin d'entretenir l'idée « rassurante » qu'on régresse, plutôt qu'on change.

Non, je parle de la lire. Seulement. Rien de plus. La fiche, la synthèse, elle est parfois (souvent) aussi faite pour eux. CQFD

Un truc qui serait intéressant, ce serait de tenter le passage au système de la classe inversée, où les élèves lisent/visionnent le cours chez eux, chacun à son rythme, et le temps ensemble est consacré uniquement à la pratique ou des questions, avec une mise en avant de la communication : il s'agit d'un moment qu'on va associer avec essentiellement des choses positives (comprendre grâce à une question un truc qu'on avait pas compris, explorer des applications intéressantes). Comme ça, ils n'ont pas l'impression de se répéter à lire chez eux un cours auquel ils ont déjà associé des souvenirs non stimulants issus d'une prise de notes passive en cours. C'est pas facile de faire un cours magistral qui réussisse à ne pas plonger les élèves en mode passif : c'est parfois possible, mais pas toujours et puis de toutes façons la plupart des profs n'y arrivent pas bien.

Malheureusement, le système n'est pas super flexible, du coup innover est difficile.

Oui dans certaines zones. Pas partout. Et comme je l'ai écrit plus bas, je ne fais qu'ajouter un élément à une liste mentionnée dans un post. À aucun moment j'ai écrit que l'absence ou le manque de travail était le seul facteur explicatif. Par contre encore une fois le nier, ça c'est se voiler la face.

Mais en même temps, faut se dire que s'ils ne sont pas motivés, c'est parce que la société et le système ne les encourage pas et ne rend pas l'école stimulante pour eux. Il n'y a pas que le côté passif encouragé par le système, renforcé par la surcharge lassante d'heures de cours qui transforme le devoir à la maison en pénitence, contribuant à plus de souvenirs non stimulants associés aux études. il y a aussi que pendant plein d'années ils ne font presque aucun choix et les rares choix qu'ils font n'en sont pas vraiment, ils sont subis, car ils ne sont pas encore capables d'en évaluer les conséquences. Bref, ils ne savent pas pourquoi ils viennent en cours, à part « pour avoir un métier un jour quand ils seront grand », qui n'est, en général, pas une source de motivation suffisante. Ils deviennent passifs à tous les niveaux : en cours ils subissent un cours magistral, chez eux ils subissent des devoirs maisons et des relectures du fameux cours qu'ils ont subi préalablement, ils subissent ensuite des contrôles notés régulièrement et, enfin, ils subissent des choix qui ne leur parlent pas.

Perso, je trouve même incroyable qu'il y en ait autant qui se débrouillent à peu près bien, sans doute parce qu'en soit le contenu n'est pas si difficile et que réviser juste avant les contrôles est souvent suffisant si on a pas encore laissé totalement tomber la motivation. Mais ceux qui échappent le mieux à la passivité et au manque de motivation ont des sources de stimulation dans l'environnement associant l'éducation à des choses positives et une personnalité un minimum robuste et/ou combative.