Dinosaure a écrit 89 commentaires

Je pense que le véritable problème se retrouve dans le paradoxe entre l'individualisme caractéristique du statut d'indépendant et la notion de commun sur lequel ce base ces différentes protections.

Ce paradoxe amène souvent les indépendants à ne pas connaître la macro-réalité que peut être l'allocation chômage/retraite/santé puisque ce statut omet l'aspect social du travail (puisqu'il y a une atomisation de la tache). Et certains peuvent tenir un discours tel qu'ils ne comprennent pas l'utilité de la sécurité social puisqu'il n'ont jamais été malade (une vision somme toute individualiste).

Mais avoir ce genre de raisonnement est complétement faux¹ par rapport à la problématique que résout ces sécurités car il n'est pas question de savoir si tu as été malade mais d'offrir une sécurité s'appliquant à tout le monde (le domaine commun) face à des problèmes qu'on ne maîtrisent pas (et de surcroît, les lois du marché n'en n'ont que faire).

Finalement, la question à se poser est: est ce qu'il est normal que ces sécurités soient optionnels pour un indépendant ? Je pense que non. En tout cas c'est mon opinion que chacun doit participer à des sécurités communes (parce que justement, c'est commun). Alors après, on peut parler des sommes, du pourcentage sur le salaire brute et de la qualité des différents services (dans les hôpitaux) mais la contrainte (car elle peut être vu comme une contrainte) individualiste du statut d'indépendant peut amener plus facilement celui-ci à omettre ces sécurités - en ayant une vision de l'investissement plus court-termiste.

On peut donc continuer l'atomisation et considérer de surcroît que la cotisation devrait être un choix individuel mais à partir de ce moment là, comment faire pour les gens voulant cotiser mais n'ayant pas économiquement la possibilité ? Ainsi peut se créer une inégalité mécanique puisque comme il serait (et il est déjà) question que ces aides soient optionnels, puisque le rapport entre indépendant/client n'est pas égal, ce dernier peut exiger une baisse du "salaire" ne laissant plus la possibilité à l'indépendant de cotiser, et lui serait amener à accepter cette précarité² puisqu'il est d'autant plus soumis aux lois du marché et à la concurrence.

Il peut donc en résulter un effet boule de neige et un nivellement vers de bas de la valeur de la prestation jusqu'à une rationalisation total du "salaire" ne laissant plus de place, pour l'indépendant, à un quelconque investissement possible.

PS: cette vision est profondément marxiste si on considère le rapport indépendant/client comme n'étant pas égal (comme le rapport salarié/patron) et la soumission aux lois du marchés et à la concurrence qui poussent certains à alimenter une baisse général des salaires en considérant (par erreur) que plus de contrat coutant moins cher (rationalisation) est mieux que peu de contrat coutant cher et amener finalement à précariser de plus en plus le statut.

On peut sembler que je fais l'apologie de l'anti-capitalisme (et peut être un peu) mais le fait d'empêcher finalement la cotisation et/ou l'investissement à ces personnes empêche l'économie de tourner. Et cette vision, même pour un libéral, n'est pas acceptable (ou sinon, c'est considérer que l'économie ne devrait tourner que pour une certaine classe et accepter l'inégalité comme état de fait).

Je suis depuis peu dans le télétravail et c'est un statut qui est selon moi profondément individuel où l'émancipation de la personne depuis une structure telle que celle d'une entreprise ajoute des responsabilités que l'on peut s'appliquer qu'à soit même par rapport à notre mode de vie.

Et heureusement, on a tous une vision différente de ce que peut être notre mode de vie. Dans mon contexte, je voyage beaucoup et je loge dans des maisons d'hôtes sans avoir véritablement une adresse fixe (en mettant de côté ce qu'exige la fiscalité). Ce qui fait que les contraintes et avantages que j'ai ne sont pas du tout de l'ordre de quelqu'un qui travaille chez lui. Pourtant, c'est du télé-travail.

Le paradigme est différent et quand certains vont voir des avantages au télé-travail comme pouvoir récupérer un colis, cela ne s'applique pas à moi. Mais j'ai d'autres avantages qui découlent directement de la définition que j'ai d'une vie épanouie (et c'est des avantages pour moi mais l'extrême mobilité que je chérie peut être considérer comme une contrainte pour d'autres personnes - on peut notamment parler des personnes ayant une famille par exemple).

Cela montre une dimension bien plus complexe de ce que peut être le télé-travail qui dépends véritablement des gens mais aussi de la nature même du travail qu'on vous propose (quand bien même on soit dans l'informatique). Certains soulignent que la communication peut être vécu comme un frein mais après, tout dépends aussi de la communication nécessaire entre la personne et les collègues (et dans mon cas, un rapport suffit car j'ai un projet très indépendant des autres).

Ce qui fait que la question d'un télé-travail est complexe pour tout le monde car on a encore du mal à définir de façon exhaustive ce que peut être le télé travail. Et même si on commence à créer des grilles de calcules pour négocier en connaissance de cause le salaire (comme considérer qu'on a pas le prix du transport par exemple et que l'entreprise peut faire des économies sur les locaux), elles ne peuvent véritablement pas s'appliquer à tout le monde sauf si on considère une forme spécifique et stricte du télé-travail (qui est celle de travailler à la maison).

PS: bon après, peut être que c'est moi qui est fou et que je ne suis qu'une minorité, mais dans ce cas, on remet en cause le propre du télé-travail (à savoir son individualisme qui multiplie ses définitions)

Je ne peux que plussoyer !

J'aurais tout autant aimé que l'e-mail soit décrit sur une seule et unique RFC mais c'est sans compter le legacy avec la RFC 822/2822, le MIME avec la RFC 2045 (2046 .. 2049), les patches comme la RFC 6532 ainsi que quelques arcanes de la RFC 5321 (SMTP) - je me suis amusé¹ à faire un tri topologique des dépendances entres les RFCs d'ailleurs.

Et encore, ce n'est qu'une partie de l'iceberg. Le problème devient plus épineux avec l'encoding (Base64, Quoted-Printable, UTF-{7,8}, ISO …) où tu peux prier que le mail spécifie la langue dans laquelle il te parle en lieu place de définir un standard partagé entre les développeurs-réptiliens s'échangeant en secret des règles tacites de ce que devrait être un e-mail en faisant fît du véritable standard (et le gagnant reste Outlook).

Bref, tu t'attaques à un gros morceau pour le coup et il existe déjà, je pense (je ne suis pas adepte du milieu CPP), des librairies qui font ça très bien, qui se sont posé les bonnes questions et qui connaissent ce qui révèle du cas particulier à une résilience assumé face aux erreurs possibles que tu peux retrouver dans les e-mails.

La question est clairement pas simple car, au delà du fait qu'il faut avoir une connaissance assez large de se que tu peux retrouver dans l'intermail (et donc avoir une bonne base, j'ai eu la chance d'avoir ~ 2 000 000 d'e-mails à ma disposition), tu dois aussi connaître au minimum 7 RFC différentes² pour avoir une vision globale et te poser des vraies questions sur l'API, sur ce qui est acceptable (mais pas autorisé par le standard) et sur ce qui ne l'est pas et trouver un juste milieu qui ne dépends que d'une étude empirique de ce qu'est, dans la vraie vie, l'e-mail (donc au delà du standard).

Je continuerais toujours à dissocier le traitement automatique de l'e-mail du MUA d'ailleurs considérant que ces 2 parties sont déjà assez complexes intrinsèquement qu'une fusion nécessaire des deux demanderait un travail d'autant plus important. Pour le coup, je remets pas tellement en cause l'idée de refaire un MUA (même si d'autres diront que ça existe déjà) mais le traitement automatique d'un e-mail est un travail beaucoup trop conséquent qui fait toujours frétiller les développeurs qui ont été face aux dates de la RFC 822 ou encore à l'adresse e-mail en général¹. Une question que je ne peux que te conseiller d'éviter donc.

Désolé mais j'ai pas tout lu. Enfin j'ai lu pour de vrai la moitié, puis j'ai compris et j'ai donc arrêté. J'ai compris que tu as décidé de pondre un pavé parsemé de moi quand j'ai vraiment bossé pour de vrai sur les RFC j'ai vu ceci-cela pour essayer de gagner par KO poids + argument d'autorité.

Puisque je me réfère aux RFCs, oui c'est des arguments d'autorités.

Ou alors malgré ton boulot apparemment technique, tu as une conception de l'architecture logicielle très archaïque et brouillonne où tout serait corrélé, où ton modèle de données ne serait pas séparé ni séparable de ton interface qui reçoit les courriels, donc si y a pas le champ tel que tu l'attends exactement tout pète. Ça me parait tellement basique que je sais même pas comment l'expliquer simplement. Pense aux compilateurs qui ont généralement un modèle interne AST qui permet plus de choses que le langage dans lequel le programmeur a écrit.

Pour le coup, j'ai aussi pas mal d'expérience dans les compilateurs (et ce n'est pas très étonnant puisque je suis dans la communauté OCaml). Et oui, la résilience du logiciel par rapport aux emails est très importantes - encore aujourd'hui, j'y travaille car cela concerne surtout des cas particuliers issus d'emails spécifiques (c'est donc désormais un travail empirique).

Mais c'est tout mon propos, cette résilience s'applique avant même le MUA. Elle s'applique dès le standard. Ce qui fait qu'avant même le MUA, tu as déjà tout et n'importe quoi. Et c'est là où je dis que la difficulté d'un MUA est déjà, en partie, issue du standard.

Mon deuxième propos, c'est que de cette complexité inhérente, les concepteurs de MUA (ce dont je ne suis pas) font des choix sur la manière de traiter un email (avec ces histoires de bruit et de convention imposé par les providers) qui ne correspondent pas forcément à tout le monde - après, oui on arrive, après tant d'années, à trouver des concepts communs.

Enfin mon troisième propos, c'est de considérer cette caractéristique qu'est cette complexité comme une qualité appartenant complétement au medium de la communication et qu'on a besoin de cette liberté effroyable de la mise en forme d'un email - puisque les standards ne parle que de la forme.

PS: plus bas quelqu'un parle d'HTML. Mais en vérité c'est le même problème:

• la complexité de parser du HTML
• les choix des différents navigateurs d'interpréter l'HTML (le clivage IE/FF était - et reste encore dans une moindre mesure - le plus parlant)
• la considération de cette complexité comme une qualité intrinsèque à ce que peut être un medium de communication

Je dis pas que c'est pas possible. Je dis juste que c'est complexe et que cette complexité est inhérente à l'email.

Et oui il y a un gap énorme entre ce dont je parle et ce que propose Thunderbird. Mais dans ce gap, il y a pas du vide mais du code.

Donc oui on peut faire un super MUA, mais:
* C'est très compliqué
* Ce MUA correspondra à votre utilisation

On prend position sur "ce que mon MUA de 2016 arrivera à tirer de tes vieux mails" mais pas forcément "ce que tu seras encore en droit de faire avec ton logiciel qui te plait".

Si on considère le vieux email comme marginal mais en vérité non. Le standard des emails est une évolution. Dans mon implémentation je ne pouvais strictement pas considérer seulement la RFC5322 (qui est le dernier vrai standard des emails) sans ses antécédents qui sont RFC2822 et RFC822 - dans la première, on fait une distinction entre règle obsolète (ce qui correspondrait à l'email legacy) et les règles de cette dite-RFC.

Donc en vérité, le legacy n'est certainement pas disjoint du dernier standard (comme peut l'être Python 2 et Python 3 par exemple) et il faut le gérer. Il faut le gérer d'autant plus que la RFC2045 qui parle du format MIME (donc l'essentiel de tes emails) se dit compatible avec la RFC822 (et non pas la RFC5322, donc la dernière en date). Donc en vérité, il n'y a pas de vieux/nouveaux mails mais des mails dont la définition s'étale depuis 1982.

La finalité est qu'on a un standard qui est décrit sur environ 8 RFCs différentes et qui définissent chacune certains aspects de l'email. Pour preuve, la RFC822 n'a jamais dit formellement si il devait y avoir des espaces entres l'en-tête et les deux points. La finalité est que certaines personnes ont mis des espaces et d'autres non et que la RFC2822 à considérer qu'il ne devait pas y avoir des espaces mais qu'un MUA devait les gérer. Alors oui, c'est de l'ordre du détail mais ça montre surtout une évolution à la fois basé sur des contraintes techniques (pour que l'email reste compréhensible pour l'ordinateur) et des comportements qui, à la base, étaient indéfinies.

La RFC2231 définit elle une contrainte technique qui n'a plus lieu d'être aujourd'hui si on considère la RFC5322 et la règle des 80 colonnes qui ne concernerait qu'une utilisation très marginale - quoique. Un MUA doit donc gérer ce cas même si il ne se présente que très peu.

Ces différents points (et tu peux en trouver pas mal sur l'histoire des emails) ont laissé place à une liberté très forte sur le format de l'email en général. Et de cette liberté, il y en ait résulté des manières d'utilisations différentes qui sont devenus la norme (leurs normes) pour certaines personnes.

Un MUA digne de ce nom n'a pas à essayer de tirer le mieux possible les informations d'un email. Il le doit. Et ce n'est pas une question d'user-experience mais vraiment une question du standard. Il s'agit même parfois de faire des concessions sur les règles elles-mêmes afin de fournir cette fois-ci le best-effort de traitement car il existe beaucoup d'emails qui ne respectent pas le standard - et je pourrais te parler de cas précis comme le préambule ou l’inexistence du close-delimiter dans un email multipart (dieu sait que ça arrive), pour le coup ce genre de cas qui sont hors des règles mais qui existent, il y en a beaucoup.

Ce qui fait que du bruit, il y en a et certains vont trouver ça normal d'avoir la possibilité de lire/écrire l'épilogue d'un multipart alors que concrètement, pour mon utilisation, ça ne sert strictement à rien. L'email se retrouve donc à la fois tirailler entre des règles qui doivent être strictes et bien définis pour qu'il puisse être manipuler par un ordinateur mais aussi par des cas d'usages qui se sont tout simplement définis avec le temps et qui sont hors du standard (ou à posteriori comme pour la RFC6532 et le support de l'UTF-8 - d'ailleurs on retrouve encore des emails qui utilisent le Latin1 alors que le standard ne l'autorise pas).

Parce qu'une hiérarchie de dossier n'est qu'une projection d'un système multi-dimensionnel sur une dimension, donc qui peut le plus peut le moins.

En vérité, la question à se poser est: qu'elle est le critère permettant de considérer que cette email appartient à tel tag ou pas (après, je suis d'accord avec toi sur l'histoire des dossiers). Et c'est une vraie question. On peut considérer que le From: suffit alors que d'autres vont considérer qu'il faut aussi baser sa recherche sur le Subject: ou encore rajouter (et bon dieu que ça arrive) un en-tête hors de la norme qui puisse réellement correspondre aux axiomes qu'on souhaite. Sur ce dernier, c'est un peu les portes de l'enfer qui laisse place à une règle que j'apprécie vraiment qui est le unstructured data où on a, à la fois, les commentaires, le folding-whitespace et une notion d'espace significatif ou pas selon la RFC2047 (quand bien même on ait la RFC6532 et le support de l'UTF8) ce qui laisse donc un degré de liberté phénoménal que les providers d'email usent et abusent.

La aussi le MUA peut difficilement en tiré quelque chose de manière exhaustive puisque ce sont des règles considérées par le provider et la manière dont Google gère ces informations est différente de celle de Laposte. Lequel est le meilleur ? Lequel le MUA doit traiter, doit il le traiter ? Bref, des surprises qu'un MUA peut juste parser (et en soit, ce n'est pas difficilement parsable, il faut tout de même utiliser un certain trick) mais doit il considérer l'information comme pertinente ou pas ?

La détermination de la valeur de ce prédicat pour un courriel donné implique la disponibilité d'un en-tête H absent de la RFC originelle.

C'est là où nous avons un problème. Les seules en-têtes obligatoires selon la RFC5322 sont From: et Date: (dont certains emails se fichent d'ailleurs). Se rajoute ensuite le Content-Type: de la RFC2045 mais qui n'est même pas obligatoire. Mais en vérité c'est les 3 seules en-têtes que tu es un peu près (oui parfois ils ne sont pas dans l'email) sûr de toujours retrouver. Difficile derrière de considérer une quelconque recherche avec ce peu d'information. Mais c'est le point de l'email. C'est que tu puisses justement laisser tes informations qui peuvent être en contradiction total avec d'autres MUAs - on peut imaginer que tu veuilles insérer des informations avec XXX-From: par exemple alors qu'il peut exister un provider ou un MUA qui traite cet en-tête selon sa norme (et pas la tienne), dans cette situation, comment doit réagir ton MUA ? Échouer ? Ignorer ? Essayer et mettre cette email sous le tapis ?

C'est là où intervient une notion qui est, à la fois définit par le standard, et à la fois totalement extérieur. C'est les conventions d'utilisations. Elles existent puisque le standard le permet et ce sont des règles mais personne n'assure que tout le monde les respectent.

Non je ne vois pas pourquoi. Si, à la limite, si ton workflow est "j'ai absolument besoin de dossiers et surtout pas de tags" ; maintenant j'attends un exemple concret. Et si vraiment tu es dans ce cas-là, bah utilise pas mon MUA.

Ton MUA prends partie forcément. Après, on peut considérer qu'il se débrouille bien (ou pas) mais il essaye car le degré de liberté d'un email est bien trop grand pour qu'il puisse s'y appuyer et en sortir quelque chose de pertinent tout le temps - il va même utiliser ce degré de liberté dans la génération des tes emails (en tout cas, c'est ce que fait Google). Il va donc forcément omettre des cas d'utilisation (il va tout simplement omettre des en-têtes définis par d'autres providers) et quand bien même il essayerait d'en tirer le meilleur, ce sera jamais de manière exhaustive.

De plus en plus d'ailleurs germe l'idée du Machine Learning pour trier les emails - tu te doutes bien à partir de là de la complexité de la question.

Non. Même si une RFC plus stricte permettrait sans doute de faciliter les choses, rien ne t'empêche d'avoir un MUA ultra avancé qui répond à 99% des attentes de 98% des gens grâce à de puissantes heuristiques (hormis le temps, l'argent et les compétences évidemment). Le tout sans empêcher quoi que ce soit (tu peux par exemple très bien implémenter ta super recherche à base d'Elastic Search en y dénormalisant les données de tes courriels, permettant ainsi de les lire avec un MUA rustique à côté (et les courriels pourris du millénaire dernier ne remonteront pas sur des recherches structurées, uniquement en fuzzy ; et ?)).

Bah en faite, c'est ma comparaison avec les langues naturelles. Cela évolue avec le temps et les comportements. Il n'y a pas une définition claire et précise de ce que devrait être un email de manière canonique et en vérité, c'est normal. C'est un moyen de communication qui a évolué avec les moyens qui nous sont mis à disposition (rien que l'idée de pièce jointe). Et cela continuera à évoluer et cela continuera à être un bordel sans nom.

Le point particulier de l'email et c'est se qui fait sa force, c'est qu'il a réussi à être un tandem entre la rigidité d'une machine et notre liberté d'expression (que ça soit dans le fond mais surtout dans la forme) et c'est pour cette raison qu'il n'y aura pas de best MUA. Considérer qu'il n'y a qu'une façon de lire et d'écrire ses emails, c'est faux et le standard le montre rien que par son nombre hallucinant de RFCs (j'en ai fait des RFCs mais en faire une dizaine pour un seul format, c'est bien la première fois). L'idée qu'il n'y est une seule et unique manière de communiquer n'est pas envisageable. Et là, la meilleur preuve qu'on est c'est la manière dont on communique avec les gens autours de nous, il y a certes un socle universel (et c'est le propos de ces RFCs) mais tellement pauvre qu'on est limité (et c'est là où on est bien loin de se que devrait proposer un MUA). Donc on rajoute des règles (de manière illégitime souvent), on essaye de comprendre les autres tant bien que mal (selon leurs règles) et on essaye d'échanger quelque chose.

L'email n'est qu'une extension rudimentaire de notre moyen de communication, et de ce faite, il ne fait qu'en découler. Le standard essaye d'évoluer en bien, mais il doit rester accessible sans prendre partie d'où sont aspect très rustique (le CC: par exemple veut dire Carbon Copy) et rudimentaire. Le MUA lui, est plus haut niveau mais il repose sur les libertés que lui offre le standard pour étayer son cas d'utilisation quitte à fermer les yeux sur d'autres règles.

Une des plus parlante reste la RFC6532 avec le support de l'UTF8. C'était une vraie question surtout pour les asiatiques. On s'est bien contenté pendant longtemps de la RFC2047 (nous européen avec nos accents) mais comment faisait les asiatiques d'après toi pour communiquer ? Et, était-il légitime à l'époque de considérer l'UTF8 comme étant le standard de facto ? Comme il était légitime de considérer un email en Latin1 valide ? L'IETF a tranché en faveur de l'UTF8 (et c'est normal) mais non seulement on a attendu 2012 pour ça mais en plus, ça n'invalide en aucun cas le reste des emails (qu'on puisse le considérer comme legacy ou pas d'ailleurs).

Alors bien entendu, c'est facile (et même normal) de dealer avec l'UTF8 de nos jours. Mais ça montre surtout que ce n'est pas un simple standard fixe sur des règles strictes et qu'il évolue et qu'il a intérêt à évoluer et que ces évolutions ne font pas partie de quelque chose de définissable formellement.

Je parle pas de SMTP mais surtout de l'email à la base déjà - SMTP rajoute une autre complexité et des limitations qui se répercutent sur l'email d'ailleurs ou sur les protocoles (comme IMAP). Mais le fond du problème reste avant et pour tout cette définition informelle du standard de manière général et toutes les possibilités¹ que peuvent proposer l'email de manière globale.

Ceci rajoute un bruit dans le traitement qui pourrait être ignoré mais c'est justement à ce moment là qu'on prends position. Mon point n'est pas de considérer que l'email et unparsable ou encore que le legacy email venant de la RFC822 pose fondamentalement un problème (il en pose un ceci dit mais pas fondamental) mais de signaler que la complexité du MUA vient en partie (mais pas que) de la complexité de l'email et pour une simple raison:

Les possibilités d'utilisation d'un email ne sont pas exhaustives.

En cela, on peut considérer comme tu le dis un système avec des tags (mais pourquoi on utiliserait pas les dossiers ?), une interface sympa, une intégration avec d'autres services (qui ne feront que traiter un subset de l'email) et une recherche puissante (qui se définira forcément sur certains axiomes).

Mais dans tout ces cas, il y a une prise de parti qui se fera forcément au détriment de d'autres possibilités des emails. Et c'est un peu là tout le mauvais côté mais aussi le succès de l'email. C'est que chaque utilisateur a sa propre utilisation des emails - et il suffit de voir la complexité des fichiers de configuration d'exim et postfix pour s'en rendre compte. Et c'est en cela que faire le best MUA pour tout le monde n'est pas possible.

Et toutes ces possibilités de l'email ne sont que pas liées au MUA, ou encore au protocole ou même à l'environnement desktop qu'on utilise mais à l'email lui même en réalité. Et c'est bien pour ça qu'on l'utilise :) !

Après, bien entendu on peut faire tout ce que tu dis et ça correspondra à ton utilisation et si tu y trouves ton bonheur, tant mieux. Mais puisque le standard nous le permet, nous pourrions utiliser l'email d'une autre manière que la tienne et y trouver tout autant notre compte.

Je viens à peine de terminer une mission pour un laboratoire qui consiste à implémenter un logiciel permettant de traiter des emails en OCaml: MrMime.

Cette mission m'a permis de comprendre quelque chose d'essentielle à propos des emails et des MUAs: un email, c'est extrêmement compliqué.

Tout le monde le sait plus ou moins et rien que parler d’adresse email, cela hérisse le poil de beaucoup de développeurs qui ont eu la curiosité de se renseigner sur le sujet (je ne parle pas, bien entendu, des personnes qui se contentent d'une regex).

En effet, on a environ 8 standards différents (selon ce qu'on souhaite gérer) à propos des emails avec des limitations datant de la RFC822. Cette dernière ayant pas mal de zones d'ombres (le folding-whitespace et les commentaires entre autre) heureusement clarifiées par la dernière RFC5322. On rajoute à cela le support de l'UTF-8 (depuis 2012 avec la RFC6532) sans oublié la RFC2047 (si on est resté old-school) à propos de l'inline encoded string et pour finir le couple RFC2045/RFC2046 concernant le format MIME. Après, il y en a d'autres ici ou là concernant certaines mises à jour.

Bref, un vrai bordel où il devient difficile d'allier compatibilité et performance, résilience et erreur - bref, tout les problèmes d'un développeur lambda.

Mais le point et c'est ce qui caractérise les emails, c'est que l'email reste le moyen de communication sur internet par excellence. En faite, sa complexité, pour moi, découle du simple fait que c'est le protocole de communication entre nous tous. En ce sens, il est tout aussi brouillon ou hasardeux que nos langues naturelles dans une moindre mesure (puisqu'il doit être compris aussi par un ordinateur).

En somme, je considère que faire un MUA est très/trop complexe dans le sens où la définition globale d'un email reste (heureusement) très informelle et qu'on peut difficilement trouver une façon de lire/traiter/manipuler des emails d'une manière qui conviendrait à tous. Il n'y a heureusement pas une manière standard d'extraire l'information que l'on cherche dans un email et que, même si on arrive à trouver des patterns (comme un multipart/alternate avec le même message au format texte ou au format HTML) il n'empêche qu'on tombe toujours sur des surprises pas si exceptionnelles que ça.

Tout ça pour dire que une large partie du problème (à savoir pourquoi on a pas un best MUA) reste enraciner dans le format même de l'email et que d'une certaine façon, c'est mieux comme ça.

L'argument d'autorité n'a jamais été valide - et c'est le point que je soulignais avec humour. Et il vaut mieux avoir une méfiance auprès des médias, en particulier BFMTV, dont la première ambition n'est pas de divulguer une information valide.

Après, si pour toi il te suffit qu'un tel dise une connerie pour y croire, très bien. Je préfère me renseigner de mon côté et recouper avec des institutions/médias alternatifs - cela ne veut pas dire que je considère comme factice, de facto, tout ce que peut dire l'[institution de votre choix] mais qu'il est certainement plus sain d'avoir la curiosité de comprendre réellement le propos.

Alors peut être que tu as raison (en vérité, j'y connais rien en PAE, mémoire et tout ça) mais ta manière d'argumenter ton propos n'est certainement pas la bonne - c'est du même niveau des pubs pour les produits amincissants où plusieurs personnes valident le propos en disant: "cela a changé ma vie" (et me dit pas que, c'est Linus Torvalds qui l'a dit donne plus de légitimité à ton propos, il en dit aussi des conneries ce messieurs - avec tout le respect que je lui dois).

si c'est … et BFM TV qui le disent, certainement que j'y croirais.

Tout s'explique.

Perso, j'ai du mal à lire tes commentaires aussi - enfin dans ce dernier, la parenthèse est trop longue ce qui nous fait perdre l'idée de la phrase.

Oui, donc il faut encore plus une syntaxe spécifiée, c'est à dire, avec une spécification. Parce que bon, dépendre d'un truc qui peut casser à tout moment je trouve que c'est pas super. Ou alors il faut que ocaml puisse garantir une certaine stabilité de cette représentation intermédiaire, ce qui apparement n'est pas à l'ordre du jour.

C'est en fait le point clef d'utiliser un scheme plutôt qu'une représentation qui de l'avis même de l'auteur, n'aurait jamais du être exposée en dehors du compilateur.

Encore une fois, la syntaxe importe peu. Malfunction permet d'utiliser le back-end d'OCaml (donc tout la compilation d'un bytecode bas niveau vers du code natif) comme c'est le cas avec LLVM-IR. LLVM-IR a aussi une syntaxe et on peut très bien soit produire à partir d'une librairie du code LLVM-IR et le piper vers le compilateur LLVM (et c'est le cas avec Kaleidoscope) ou utiliser une librairie qui fait cette glue entre représentation intermédiaire et code natif (comme c'est le cas avec le compiler-libs d'OCaml).

Il est en effet dit que le bytecode Lambda d'OCaml n'a pas l'ambition d'être stable. Maintenant, je pense que Malfunction peut se doter de cette caractéristique en étant lui même une abstraction de Lambda (et donc de faire la glue nécessaire entre les différentes versions de Lambda).

Le point est surtout d'offrir un outil qui permet de produire du code natif spécialisé pour des langages fonctionnels. La comparaison, selon l'objectif de Malfunction, avec Scheme ne se porterait, en l'état pour l'instant, que sur les performances - on peut pas vraiment parler encore de stabilité et de compatibilité vu le numéro de version du projet. Un propos, et c'est ce que souligne Gasche, c'est une comparaison des performances entre le runtime OCaml et le runtime des différentes implémentations de Scheme.

De plus, j'ai l'impression que du confonds la syntaxe de malfunction et la syntaxe de Lambda. Qui sont apparemment deux langages différents,

Encore une fois, si la différence est purement syntaxique (en incluant les sucres syntaxiques qui peuvent faire la glue entre les différentes versions de Lambda), elle n'est pas importante.

Ce qui veut dire que même une fois que ton langage devient « mûr » tu veux continuer à utiliser cette architecture ? Même si de ton propre avis

si pour cela il faut piper dans un fichier texte au milieu, je ne vois pas vraiment le soucis

Ce qui (pour moi) sous-entends que c'est une phase « alpha », prototype, enfin, quelque chose de pas propre.

C'est ce que fait un compilation de manière général, piper une représentation intermédiaire d'une passe à une autre et c'est l'objectif même de LLVM-IR ou de Malfunction: passer d'un dialecte à un autre. Si techniquement ensuite, on utilise un pipe nommé ou whatever, ça reste un détail technique qui je pense peut être très facilement remplacé (et qui n'a que peut d'importance et qui, surtout, ne concerne en rien la qualité propre du dit langage).

Et quand on voudra le faire proprement, voilà ce qu'il va se passer :

manipuler directement la compilation (mais encore une fois elle n'est pas stable)

Ah, bah, on repose sur un truc instable, génial.

Justement, Malfunction peut s'assurer d'une API stable en étant lui même une abstraction d'une représentation intermédiaire (le Lambda) qui, heureusement, évolue - tout comme LLVM-IR évolue et a aussi des casse de compatibilité mais qui offre des librairie permettant de produire cette représentation intermédiaire qui garantissent un minimum de stabilité (et c'est le cas pour les librairies disponibles en OCaml et en C++).

Je veux bien te croire sur parole (étant donné qu'il n'existe pas de spécification du langage), mais cet argument est quand même bien foireux, je te le refais

ASM x86 a bien une représentation des valeurs qui permet de manipuler les types sommes (puisque c'est la représentation du compilateur OCaml, qui en a)

Hophophop, voilà ! Bon, j'ai retiré « intermédiaire » et changé le nom … Soit ce que tu dis est qu'il est possible de le faire simplement, ce qui est le cas dans à peu près n'importe quel langage (même x86) soit tu dis qu'il existe une syntaxe spéciale, et alors l'argument n'a aucune valeur.

C'est là où on voit que tu as une méconnaissance de l'objectif réel de Malfunction. Bien entendu que tu peux faire toi même un back-end vers ASM x86 ayant une représentation optimisé des types sommes mais la véritable question est: est ce que tu veux réellement produire toi même de l'ASM x86 ? et quid des autres ASM ? Malfunction réponds à cette question en te proposant un langage intermédiaire qui produit du Lambda pouvant être directement manipuler par le back-end d'OCaml et ainsi compiler vers du natif (et pas uniquement du x86) en proposant un runtime optimisé pour les langages fonctionnels (comme c'est le cas pour Idris).

C'est comme LLVM-IR mais qui reste un langage intermédiaire bas niveau et pas forcément optimisé pour les langages fonctionnels de base - il peut bien sûr être complété par un runtime optimisé pour un langage fonctionnel (comme c'est le cas pour Haskell - mais ça demande des manipulations qui ont d'ailleurs eu lieu en plein dans la spécification de LLVM-IR). Le point est surtout de proposer un runtime avec un garbage-collector pensé pour les langages fonctionnels (et pour le coup, l'intégration d'un GC fait maison dans LLVM-IR est une tâche difficile).

C'est minime, c'est juste que bon, tu n'as pas à construire :

Un lexer
Un parser
Un programme qui va compiler un AST vers un autre langage

Bah euh, c'est justement le point. Malfunction offre juste un langage intermédiaire. Après c'est à toi de faire le langage haut niveau par dessus Malfunction qui reste une représentation intermédiaire pour un back-end spécifique aux langages fonctionnels. Et pour preuve, l'auteur a réussi à utiliser Malfunction dans Idris - il a rien changé Idris (même si il dénote que certaines constructions du langage ne sont pas disponible avec Malfunction - mais je pense que c'est surtout une question de temps et de travail) mais il a changé le back-end avec, selon ses dires, un gain de performance non négligeable.

Donc oui, tu devras toujours faire un lexer/parser/passe vers Malfunction comme c'est le cas aussi pour LLVM-IR. Mais c'est l'intérêt même de Malfunction. Donc je vois pas trop ce que tu essayes de dénoter ici.

On ne peut pas le faire en utilisant un programme C intermédiaire ? Ça revient presque au même (parce que la glue et l'analyse de type tu la feras quand même). C'est plus complexe techniquement, certes.

"C'est plus complexe techniquement, certes." et c'est bien la raison de Malfunction.

L'avantage de la communauté OCaml encore aujourd'hui, c'est qu'elle reste assez petite et toute contribution dans le monde OCaml de près ou de loin a un impacte non-négligeable dans la communauté. Les retours se font rapidement et avec beaucoup d’enthousiasme.

En plus de cela, la communauté OCaml se compose essentiellement de personnes venant du milieu académique qui ont toujours un retour très constructif sur la manière de faire un programme en OCaml (de façon général). Mais on trouve des acteurs de l'industrie très actifs qui ajoutent des contraintes "du monde réel" dans le savoir-faire OCaml (optimisation, scalabilité, etc.).

Bref, on est dans un entre-deux qui laisse parfois quelques scènes dramatiques par ci par là mais allant, AMHA, toujours dans le bon sens - autant si on est industriel, autant si on est chercheur. Je trouve que c'est le seul langage (à contrario de Haskell par exemple) qui a réussi à allier deux communautés différentes (autant sur les objectifs qu'ils ont que sur la manière de faire).

Donc il y a véritablement deux point à noter:

• Le premier c'est que, quoi que tu fasses, la communauté recevra avec enthousiasme ce que tu fais. Cela peut être un tout petit logiciel pas très compliqué. Pas besoin d'essayer de faire un build-system en OCaml. C'est pour cette raison que je reste attaché à cette communauté puisque la majorité des logiciels que j'ai entrepris sont utilisés (Syndic, Decompress et bientôt MrMime). Ainsi, on a vraiment l'impression de participer à quelque chose de plus grand et c'est important de se rendre compte qu'on est acteur d'un mouvement (et non pas simplement utilisateur comme dans de plus large communauté comme JavaScript).

• Le deuxième point est ton apprentissage individuel. Les personnes qui composent la communauté OCaml sont souvent des chercheurs qui ont un savoir assez impressionnant (et qui dépasse souvent le simple cadre de la communauté OCaml) se qui fait qu'il est toujours intéressant de discuter avec ces personnes qui vont te pointer vers des documents qui t'en apprendront plus sur les langages informatiques (domaine de prédilection d'OCaml), les algorithme et les paradigmes. L'avantage est qu'on garde toujours une réalité de ces connaissances qu'on peut appliquer (et qu'on applique) dans l'industrie. Ce qui fait que même si la courbe d'apprentissage est rude, elle n'en est pas moins impossible - par exemple, je viens tout droit d'un milieu très industriel (et j'ai ignoré presque tout les aspects théoriques de l'informatique) et pourtant j'arrive à m'en sortir en comprenant des concepts que je n'aurais jamais eu la chance de voir dans le milieu d'où je viens.

Tout ça pour dire que tu peux te lancer sur pas mal de projet. MirageOS tient une liste de projet intéressant mais tu peux tout autant entreprendre autre chose qui ne soit pas forcément théorique (comme ce genre d'outil ou encore ce genre de logiciel) qui ne sont pas très difficile à faire mais qui sont tout autant intéressant.

Bref, lance toi et j'espère que tu ne regretteras pas l'aventure :) !

En réalité, c'est exactement ce qu'il cherchait à faire. Je pense que dans son texte, il ne souhaite certainement pas penser "comme un motard". Il mets en avant des données factuelles du code de la route (qui sont non-négociable comme le souligne @passant) qui pénalisent le motard.

En ce sens il met en opposition ces données avec le comportement du motard et ce qu'il critique, c'est justement la pensé du motard qui décide d'ignorer (en pensant être dans son bon droit) le code de la route au travers de ses actes.

Là où tu es tombé dans le piège (d'une certaine manière), c'est que toi-même tu dis qu'on devrait reconsidérer son argumentation sous le point de vue du motard ici:

ton chapitre sur le code de la route démontre une ignorance totale de la route du point de vue d'un motard

Et donc reconsidérer ces pénalités sous le point de vue d'un motard.

Mais en vérité, c'est exactement ce qu'il dénonce, c'est qu'on a considéré les actes sous le point de vue d'un motard en ignorant le code de la route et que factuellement, ces actes sont considérés comme interdits par le code de la route - après on peut reconsidérer le code de la route mais c'est un autre débat.

Ainsi, il repointe se qui a été dit sous l'unique point de vue du code de la route (donc en ignorant délibérément la pensé du motard) pour dénoncer justement cette pensé du motard qui cherche à s'émanciper des règles du code de la route et démontre qu'au final, ces gens qui essayent d'argumenter leurs actes (sous l'aspect écologique) ne sont que des dangereux de la route - si on considère toujours le code de la route.

Enfin, ce que demandais ensuite @adonai ici:

Et sinon, en quoi tu as montré qu'il "avait une connaissance très limitée de son sujet", à part en disant qu'il n'a pas montré qu'il "pensait comme un motard" quand il citait des infractions au code de la route ?

C'est justement savoir si tu étais capable de critiquer les faits qu'énonce l'OP sur le code de la route. En somme, si tu es capable de dire que se que décris l'OP sur le code de la route est faux (donc d'enlever le caractère factuel de l'OP dans son paragraphe "Tou"). Si c'est le cas, on peut reconsidérer son argumentaire, sinon, ça montre justement que tu ignores (ou essayes d'ignorer) la conclusion de l'OP sur les motards: à savoir que certains ne sont que des dangereux de la route.

PS: il doit y avoir quelques fautes surtout entre les se/ce mais pour le coup, j'ai du mal aujourd'hui :(

Il faut surtout savoir si une programmation multi-coeur peut potentiellement être intéressante pour la problématique. Utiliser plusieurs cœurs c'est entre autre mettre des lock pour garder l'intégrité de certaines données partagées et ces derniers ont un coût.

Dans le cas de la compression sans perte par exemple, il s'agit de calculer la fréquence des caractères et, dans le cas d'une compression LZ77 (ou dérivé), il s'agit de maintenir un dictionnaire de pattern pour obtenir les distances. L'accès à ces éléments (en écriture principalement) se fait presque à chaque caractère, il s'agirait donc de mettre un lock à chaque fois qu'on lit un caractère. Dans ce contexte, on peut facilement inférer qu'utiliser plusieurs cœurs pour un seul document n'est pas la bonne stratégie - l'idée ensuite qu'on puisse considérer qu'un processus puisse s'occuper de N caractère (et donc locker tout les N caractères) n'est pas envisageable puisque cela invaliderait les distances pour la compression LZ77. On peut toujours trouver des solutions mais qui ne ferait que ralentir l'algorithme en général avec des partages de contexte fastidieux.

Là où l'on peut par contre utiliser le multi-coeur, c'est dès qu'il s'agit de compresser plusieurs documents indépendamment (et de merger ensuite les fréquences obtenues pour générer un arbre de huffman commun) - les distances seront alors limitées au document mais si on se place dans un ratio vitesse/taille, cela reste négligeable.

Se placer dans une problématique multi-coeur de facto n'est pas toujours la bonne solution, il s'agit surtout de cibler le niveau d'atomicité de notre algorithme. Je sais pas si c'est vraiment le bon terme mais dans l'exemple, on peut considérer que chaque document peut être compressé séparément alors qu'on peut difficilement atomiser l'algorithme compressant un document en plusieurs petits algorithmes indépendants. On considère donc l'algorithme comme atomique mais pas ce qu'il compose.

Il est donc normal de voir encore des logiciels mono-coeur car ils seront plus efficaces que si ont se forcé à ce qu'ils utilisent plusieurs cœurs. La problématique reste difficile est elle est au centre de certaines langages hauts niveaux qui souhaiterait abstraire la programmation parallèle. C'est à mettre en opposition au global lock présent dans le garbage collector (comme en Python, JavaScript ou encore OCaml).

Malheureusement, avoir un garbage collector multi-coeur peut amener un coût non négligeable qui pourrait ralentir des programmes mono-coeur (pour assurer la validité des pointeurs entre garbage collector partagé et garbage collector spécifique au cœur utilisé) d'où la réticence de certains développeurs à vouloir absolument intégrer le multi-coeur dans certains langages (comme OCaml). Bien entendu, des efforts sont fait dans le bon sens pour éviter l'overhead imposé.

Tout ça pour dire qu'on aura toujours des programmes mono-coeur :) !

En général, je n'attache pas une grande importance à la mort des grands artistes car ainsi va la vie et ils ont eu à mon humble avis leurs périodes de gloires qui, bien entendu, nous a tous marqué. Cependant, pour David Bowie, c'est différent.

Je pense que c'est différent car on peut retrouver au moins une musique de David Bowie qu'on a kiffé (perso, c'est Ashes to Ashes) tellement qu'il a eu des styles si différents. Car, si je reste honnête, il y a certaines musiques que je n'aime pas mais il est tellement insaisissable qu'il est difficile de se faire une critique de lui en écoutant que 2 ou 3 de ses musiques.

Encore aujourd'hui, j'entends certains groupes avec une instru tel que celle de David Bowie et qu'ils ignorent ce patrimoine et cette inspiration qui reste dans la conscience collective de chacun et faisant partie de l'identité de ce monde occidentale. Ainsi, je considère qu'il a fait la musique de demain et qu'on ait tout aimé ou pas, ça reste un personnage qui a marqué plus d'une génération.

Je pense qu'on se trompe sur les objectifs initiaux de la création d'IRC. En effet, nous ne sommes pas dans cette logique de créer un n-ième protocole de messagerie qui les supplanterait tous. Cette logique est même contraire à la philosophie du libre qui prévaut l'aspect du choix avant tout.

Maintenant, il faut être au courant des outils que nous utilisons et au courant du peu que Slack laisse paraître, sur l'utilisation d'un tel outil et de son aliénation. On peut considérer l'utilisation de Slack - mais aussi d'IRC - en ces termes puisqu'il s'agit de se déposséder de nos moyens de communications au travers de ces outils (et qu'on ne me juge pas marxiste).

Slack investi de plus en plus sur son bot et a pour objectif même d'implémenter un apprentissage pour celui-ci afin qu'il réponde mieux aux utilisateurs. Entant qu'informaticien, nous connaissons les dangers et les travers d'une tel ambition - il faut toujours avoir à l'idée que Slack est une entreprise qui cherche à faire du profit et si ils peuvent collecter des données pour les étudier ou directement les revendre, je ne pense pas qu'ils ferment les yeux sur cette poule aux œufs d'or.

On me concédera un aspect paranoïaque maintenant mais c'est bien la différence fondamentale entre IRC et Slack en vérité. Et il s'agit d'être en phase avec ces hypothèses réalistes. Je ne suis pas contre l'utilisation de Slack mais il s'agit toujours de connaître ses outils et ses potentiels risques avant de dire que: Slack > IRC

IRC ne mourra pas car beaucoup de gens gardent en tête sa protection de sa vie privée (dans une certaine mesure) et certains ne voudrons pas utiliser Slack comme ils refusent d'utiliser Facebook. D'autres acceptent l'aliénation avec ces outils mais personnes n'est a blâmer - l'un n'est pas plus hype que l'autre et l'autre n'est pas moins inconscient (enfin je l'espère).

Il y a donc déjà des divergences si on ne considère pas le côté technique entre les deux et rien que ces divergences montrent qu'IRC existera toujours car la cible est juste différente.

En gros, cette article montre seulement que tu ne sais pas définir un opérateur infixe en OCaml:

let ( >>= ) = bind

Quel est le niveau théorique des exposés ?

C'est un des aspects que nous travaillons en effet. Les requis pour comprendre les conférences peut être assez important (et l'a été pendant certaines conférences) cependant, il y a un consensus au niveau des organisateurs sur le niveau théorique et nous cherchons à mettre en avant des exposés plus compréhensible.

Bien entendu, la communauté Caml est largement représenté par des chercheurs et nous ne pourrons et ne voudrions pas boycotter les exposés un peu plus techniques car ils peuvent amener le néophyte à apprendre de nouvelles choses. Ce qu'il faut surtout maintenir, au delà du contenu que propose le OUPS, c'est l'aspect pédagogue que l'on retrouve sur la majorité des participants. Donc pour ceux qui ne connaissent pas OCaml, c'est une bonne occasion de sonder cette communauté et apprendre pleins de choses indépendamment du langage.

ces rencontres OUPS peuvent-elles intéresser un non-informaticien qui souhaite voir ce que les camlistes parisiens font ?

Au delà de rassembler des acteurs de la communauté OCaml participant au compilateur ou à des projets satellites, on y retrouve des personnes participant à l'industrie OCaml - nous avons par exemple pour le prochain OUPS deux intervenants de Jane Street. Mais nous avons aussi des représentants d'OCaml Pro, de LexiFi, ou encore Cryptosense (et d'autres que j'oublie). Et pour quelqu'un qui s'intéresse à ce qui peut être fait avec OCaml et ce qui est fait, c'est vraiment la bonne occasion de rencontrer ces personnes.

Le premier exposé est dans la langue de Shakespeare, les discussions sont-elles dans la langue de Molière ?

C'est un dernier point sur lequel nous discutons encore. Pour l'instant, la ligne directrice, c'est de s'ouvrir à l’international en complément avec ce que fait OCamllabs. Nous donnons donc la possibilité aux intervenants de faire leurs exposés en anglais - mais ce n'est pas une obligation. Ensuite, la communauté est bien entendu majoritairement francophone et les discussions se feront sûrement essentiellement en français. Cependant, je ne suis pas pour qu'il y est l'un ou l'autre mais les deux.

Donc l'anglais ne devrais sûrement pas être une barrière pour participer à cette événement mais c'est un plus optionnel.

Voilà, en espérant avoir bien répondu à tes questions.

En France on a finalement très peur. On parle de la "croissance" comme un petit animal mystérieux qui sort de sa tanière plus ou moins aléatoirement. La créativité est découragée par un état qui se mêle de tout au motif qu'il se dit capable de maintenir une situation du passée en décrépitude, comme si il pouvait maintenir un banc de corail dans un état fixe de façon permanente (c'est à dire faire mieux que la nature, hum). La façon dont le dossier UberPop, bien que complexe, a été géré, est un exemple frappant de notre pessimisme et de notre peur de l'avenir (on confond souvent capitalisme et capitalisme de connivence).

Nous sommes paralysés, coincés entre les deux mondes. Incapables d'abandonner un peu de notre sécurité pour tirer parti du nouveau monde incroyable qui est sous nos yeux. A la décharge des politiques le discours "vous-en faites pas tout va redevenir komavent" marche beaucoup, beaucoup mieux que "bon ben là désolé mais faudrait se sortir les doigts".

Tu mélanges tout ici. Tu parles de croissance, raccroche vers de la créativité avec une petite touche politique pour finir sur UberPop et balancer "le capitalisme" ce qui dénote plusieurs problèmes qui sont économiques, sociétales et politiques - je ne veux pas dire que c'est thèmes n'ont pas de liens mais là c'est trop gros pour en faire une analyse pertinente.

Cependant, il y a point tout de même sur lequel il faut se concentrer. On est d'accord pour dire que des robots vont pouvoir (ont déjà) remplacer des métiers. L'idéal serait qu'au travers de cette mouvance qui semble être fataliste, l'éducation offre des cursus concernant les nouvelles opportunités car il est vrai aussi qu'à remplacer les transports par exemple par des robots, on pourrait imaginer une plus grande demande de programmeur (bon après, dans un aspect de rentabilité, on sait très bien que pour 1000 emplois supprimés dans le domaine des transports vaudra 1 programmeur - l'échelle n'est peut être pas exact mais elle donne l'idée général du documentaire, à savoir la rentabilité d'un point de vu humain).

Ainsi, si on ne considère pas sous un certain pessimisme le changement qu'il risque d'arriver, la question serait plutôt, avons nous les moyens aujourd'hui d'offrir une nouvelle porte de sortie à tout ces employés qui vont être remplacé par des machines ? Il faut une remise à niveau sur le plan des compétences demandées par ce nouveau marché. Il faut aussi que la nouvelle génération ne se retrouve pas à faire un travail qui va être remplacé dès l'obtention du diplôme. Il faut peut être revoir le système éducatif tel qu'il est pour qu'il soit plus flexible face à la rapidité de ce changement. Bref, pas mal de question sans réponse.

L'argument du "chez moi ça marche" est tout aussi pertinent …

L'âge n'a rien à voir. COBOL a 40 fois moins de lignes modifiées que Rust, c'est justement l'argument : C/C++ sont encore des langages très actifs (et pour une bonne raison) !

En lisant tes commentaires, on peut facilement inférer que tu serais près à déduire la qualité d'un langage par sa popularité. Si c'est le cas, je te conseille de lire L’Art d’avoir toujours raison de A. Schopenhauer, stratagème XXX pour bien que tu comprennes que ton argument d'autorité qui est la citation du Programming Language Popularity Index reste une vision bien trop simpliste pour juger de la qualité d'un langage comme le souligne d'ailleurs Christophe B.. Et il est certains que le C et le C++ ne sont LES langages d'hier, d'aujourd'hui et de demain car le monde serait non seulement bien triste et dangereux avec tous ces segfault mais qu'il existe (heureusement) beaucoup d'autres solutions qui ont, eux aussi, des qualités et des défauts. Bref, Rust a autant sa place dans le panel des langages informatiques utilisable comme l'a le C, le COBOL, le Python et l'ATS.

Java n'est pas du tout sur le même segment que C/C++. Il y avait un manque qui a été comblé. Rust comble quel manque en terme de marché ? Aucun.

C'est malheureusement là où je ne serais pas tout aussi catégorique que tu ne l'es et nous avons déjà partagé un tel débat ensemble. Je vais pas faire le perroquet ici mais Rust détient une part du marché. Après, est ce que les moyens observés sur Rust conviennent à l'importance du secteur ? Est ce qu'il ne fallait pas plutôt travailler sur l'existant ? Est ce que le bruit est à la hauteur de l'impact hypothétique qu'aura Rust dans l'industrie ? C'est là qu'il y a un débat, et c'est ici que nous ne sommes pas d'accord. Mais Rust convient à des problématiques pour lesquelles le C ou le C++ ne conviennent pas, il appartient donc à un marché (d'une importance relative) qui ne semble pas être sous le joug d'un langage semblable.

Par contre, et là je te rejoins, il est vrai que Rust ne supplantera pas le C ou le C++ et c'est, je pense, ce qu'a voulu dire sinma d'une manière un peu implicite. C'est une erreur courante qui peut, certes, embêter (comme quand on m'embête en me disant qu'OCaml, c'est naze à cause du (+.)) mais qui n'enlève rien - si on s'y intéresse - au fond de ce que peut être Rust.

Faisant de l'OCaml tout les jours, je ne peux que approuver ce conseil.

Il faut bien le dire avant toute chose, OCaml est un langage qui brille dans le domaine de l'analyse statique et la compilation. Il y a plusieurs raisons à cela.

La première concerne la programmation fonctionnel. Le principe de la programmation fonctionnel est que tout est fonction. Mais en disant cela, on a rien dit. En vérité, la programmation fonctionnel offre une manière de penser qui, justement, est parfaite pour ce qui est de l'analyse et de la transformation. Un langage impératif offre une vision d'états de la machine (un nombre d'état qui peut devenir exponentielle dès qu'il s'agit de faire de multi-threads) de manière séquentielle comme la recette de cuisine qu'on nous ressort à chaque fois qu'on souhaite apprendre l'informatique. Mais dans une problématique de recherche et de transformation, cette notion d'état n'a pas grande importance. Ce qui est important dans un compilateur par exemple, ce n'est pas l'état de celui-ci, c'est les règles de transformations qu'il va appliquer, et c'est bien là la nature d'un compilateur, c'est les règles lexicales, syntaxiques et sémantiques de transformation qui nous intéresse. C'est en ce premier point qu'OCaml (mais tout langage fonctionnel de manière général) est plus propice au travail de compilation et d'analyse du code.

La deuxième concerne le milieu d'OCaml. OCaml est un langage qui vient de l'Inria et qui est encore maintenu par pas mal de chercheur (notamment le laboratoire Gallium). Il est au final très plaisant de travailler avec où l'important n'est pas la date de la prochaine release d'OCaml mais l'intégration d'un travail qui correspond à l'état de l'art de toutes leurs recherche. Ceci donne alors un compilateur associé à pas mal de papiers de recherches (pas si difficile à lire que ça) qui offre un aspect qui va bien au delà du simple hype au langage. En somme, je considère que tout travail dans OCaml fait objet d'une confiance difficile à rétorquer sous le coup de l'humeur - comme par exemple, pourquoi on a l'opérateur (+.) pour les flottants - car chaque choix est argumenté en prenant compte un point de vu de recherche mais aussi, il y a peu, d'industrie. Et c'est bien un des rares langages à pouvoir mélanger les deux.

La troisième raison concerne bien entendu son système de type qui fait qu'OCaml est OCaml. Dans un domaine comme celui de la compilation, le premier point le plus important est que le compilateur ne produise pas quelque chose qui ne fonctionne pas. Ce serait bête de faire un "Hello World!" en C et que gcc nous produise un "Hello Toto!". Sur ce point qui parait bête, les problématiques de la compilation vont bien plus loin que de simplement produire ce qu'on nous demande. On doit aussi vérifier ce que nous produisons. Une des solutions aujourd'hui est le test unitaire qui permet à fortiori de savoir si le comportement de notre programme correspond à nos attentes. Bien que cette manière est très bien, elle n'est pas exhaustive, elle se limite à l'imagination que peut avoir le développeur sur les cas d'utilisations possibles de son logiciel. Ainsi, les chercheurs ont cherché (c'est leurs jobs il parait) une solution permettant de vérifier statiquement la validité d'un programme. Bien entendu, ce n'est pas possible de vérifier qu'un programme ne plantera jamais mais on a déjà pas mal de piste qui permettent d'élaguer le plus de bugs possibles et l'une de ces solutions est le système de type. C'est bien pour cette raison qu'on dit qu'un programme OCaml qui compile à 90% de chance de ne pas planter.

Au final, au travers de ces trois points, et de manière simplifié, on comprends pourquoi OCaml brille dans ces domaines là mais le mieux reste de le pratiquer pour s'en rendre compte. J'ai vraiment l'intime conviction qu'OCaml peut être une très bonne solution pour ton logiciel bien qu'il faut ré-apprendre un nouveau langage et surtout ré-implémenter le moteur dans ce langage. Cela peut paraître chiant (et ça l'est je pense) mais le gain que tu gagneras est juste énorme. Un vieux fou m'a demandé de faire mon petit interpréteur de Scheme en OCaml alors que je le faisais en C, il reste fou mais il avait raison de me demander ça et c'est bien un des meilleurs conseils qu'on m'ai donné. J'ai perdu alors pas mal de temps à ré-implémenter mais force est de constater que je suis allé beaucoup plus loin qu'un simple interpréteur de Scheme aujourd'hui et c'est bien grâce à OCaml.

Je pense qu'une analyse statistique peut être intéressante. Concernant par exemple l'étiquetage morphosyntaxique, on utilise les modèles de Markov cachés qui reste un outil statistique auquel on va lui apprendre (il semble d'ailleurs possible de faire de l'apprentissage semi-supervisé) l'étiquette que peut avoir le mot. Cela m'étonnerait pas que tu en trouve dans les autres correcteurs orthographiques puisque c'est typiquement un outil qu'on utiliserait dans la phase d'analyse lexicale d'une langue naturelle.

Bien entendu, il y a une limitation de moyen derrière. Certains laboratoires de recherche comme le LIRMM ont des BDDs contenant une centaine d'articles du journal Le Monde auxquels des linguistes ont étiquetés chaque mot. Mais cela ne veut pas dire qu'il ne faut pas creuser de ce côté !