flan a écrit 1830 commentaires

Et ça perd les IDE, qui ne peuvent plus t’aider.
Je préfère conserver la signature, voire ajouter le type attendu et avoir un IDE qui me prévient dès que je fais une erreur de type.

J'ai mis trop longtemps pour éditer mon message, alors je me réponds pour compléter :

Concernant le git, je ne suis donc pas concerné mais je pense que c'est illusoire de penser que la fusion fonctionnera mieux que sur du HTML sous prétexte que les balises s'écrivent **toto** et non <strong>toto</strong> .

Ah non, je ne le prends pas du tout pour du troll :)
En fait, de mon côté, les vraies contraintes étaient différentes car je voulais entre autres :

• limiter les applications métier à utiliser,
• du versioning (simple, sans chercher à pinailler par ligne),
• imposer un style très uniforme en fonction du type de document,
• personnaliser à ma manière les impressions faites,
• permettre de lier des méta-données (qui proviennent d'une application web) à ces documents et les ajouter à l'affichage ou à l'impression.

Au final :

1. Intégrer l'éditeur de texte à l'application web a été la solution de moindre coût pour permettre ces points,
2. utiliser un éditeur Markdown a été la solution à moindre coût pour permettre une mise en forme minimale (avec la possibilité de tags propriétaires et de notes de bas de page),
3. la transformation en LaTeX a été la solution à moindre coût pour imprimer les documents avec un rendu correct¹,
4. cela permet de tout faire dans une seule application web.

D'un point de vue technique, je me moque totalement des autres choix (WYSIWYG, WYGIWYM ou à balises), ce sont les utilisateurs (dont je suis également) qui choisiront, mais si je peux proposer un WYSIWYG qui remplisse tous mes critères, les utilisateurs seront les plus heureux du monde.

Dans mon cas :
- j'ai la chance d'avoir des utilisateurs obéissants et de bonne volonté à défaut d'être geek,
- ils savent qu'ils n'ont aucune chance de repasser à Word ou LibreOffice (ils ont eu une phase transitoire avec LO, et leur réaction face à Markdown a été unanime : c'est toujours mieux que LO),
- un éditeur WYSIWYG (style Word) pourrait très bien être castré pour se limiter à un sous-ensemble simple et donc obtenir un rendu homogène ( https://ckeditor.com/docs/ckeditor5/latest/examples/builds/document-editor.html ),
- il est illusoire d'utiliser git sur du Markdown et espérer avoir en permanence du texte valide lors d'une fusion (des étoiles ou des underscores sur deux lignes différentes, par exemple) — on se retrouve à égalité avec du HTML à ce niveau : de toute façon, si tu ne peux pas garantir que la transformation vers le produit final est viable, on se moque de pouvoir faire un diff.

Pour avoir mené une expérience similaire (du Markdown dans des mains de non-geek), je pense que c'est une mauvaise idée.

Pour autant, je ne rejette pas la faute sur les utilisateurs, mais plutôt sur le Markdown, qui est finalement un langage beaucoup moins simple qu'il n'y paraît quand il s'agit de faire des listes imbriquées, des listes numérotées avec plusieurs paragraphes (« mais pourquoi ça me numérote à 1. alors que j'ai mis 2. ???? »), etc. Les réponses sont toujours du type « faut sauter une ligne » ou « fallait rajouter 4 espaces au début de chaque ligne ».
D'autre part, il faut trouver un éditeur Markdown qui permette les correcteurs orthographiques, ce qui n'est pas évident, et un rendu temps réel bien synchronisé (j'ai souvent des décalages verticaux entre l'interface de saisie et l'aperçu du rendu).

De mon côté, c'est encore du Markdown mais je pense partir sur du « HTML » avec ckeditor. Je mets les guillemets car c'est un HTML très expurgé qui devrait interdire de faire n'importe quoi (je veux forcer un style très uniforme des documents) et une conversion facile vers d'autres formats.

Un processeur normal est constitué de « portes logiques » qui laissent ou non passer le courant en fonction des courants électriques en entrée (à traduire par « ça produit un 0 ou un 1 en fonction des 0 et 1 en entrée). Tu as des portes pour faire un AND, un NOT, un OR, etc. Quand tu en as quelques millions mises bout à bout, ça donne des enchaînements complexes capables de produire des additions, divisions et autres opérations dont sont capables les processeurs modernes.
Ces portes sont gravées dans le silicium et donc non modifiables. Si tu te plantes lors de la gravure de ton processeur, tu mets tout à la poubelle et tu recommences.

Un FPGA est la même chose, sauf que ce n’est pas gravé dans le marbre et que tu peux regraver les portes logiques pour adapter les opérations faisables par le processeur (en contrepartie les opérations sont faites moins vite). Pratique pour faire des prototypes ou des processeurs hyper spécialisés.

Mais en pratique, combien de sites ont vraiment besoin de perfs aussi élevées ?
Quand je vois que des sites comme Libération, Disqus, Instagram, Spotify, The Washington Post sont (ou ont été) avec du « bête » Django, je me dis que 99% des sites web devraient pouvoir tenir sans trop de souci avec des technos très classiques.
À nouveau, je ne suis pas développeur web, mais quand je compare le coût annuel du développeur avec celui d'un serveur, j'imagine que la rapidité de développement doit largement primer la performance (sauf quand on s'appelle Google ou Facebook ou qu'on fait partie du 1% ci-dessus, bien sûr)

Ce n'est pas la première fois que je me fais cette réflexion, vu que la question des perfs revient régulièrement (par exemple avec les framework C++).

Si elles sont gratuites, ça ne risque pas d’être de la vente liée ;)
Peut-être de l’abus de position dominante, mais c’est tout autre chose.

Combien coûtent ces applications si elles ne sont pas fournies par défaut ?

Fondamentalement, tu as raison. Cependant, je pense que comme les rustines fonctionnent suffisamment bien et que de toute façon il faudra conserver le SMTP pendant longtemps (en partie à cause de toutes les applications qui utilisent SMTP pour envoyer des alertes automatiques), les gens vont être vraiment frileux à l'idée de déployer autre chose.

Enfin, ça finira bien par changer un jour, on ne va pas conserver SMTP pendant des siècles…

Mais dans ce cas, pourquoi faire ?
JMAP apporte quelque chose par rapport à IMAP + SMTP (même s'il restera toujours loin derrière ActiveSync/Exchange en termes de possibilités). En revanche, qu'apporte concrètement JMAP par rapport à SMTP ?

L’historique ; c’est facile de mettre en place un serveur JMAP à côté du couple IMAP/SMTP, tout comme on a déjà des Exchange. Ça n’affecte que ton client et tu peux donc changer ton serveur sans rien demander à personne.
Remplacer SMTP va demander un peu plus de coordination.

JMAP ne veut pas remplacer le SMTP.
JMAP veut remplacer le SMTP entre le client final et son premier relais.

Le but n'est pas du tout de corriger les problèmes de SMTP (ce qui est loin d'être simple), mais de simplifier la vie de l'utilisateur final pour qu'il n'ait qu'un seul compte à configurer, comme sur Exchange.

L'idée est donc de faire du JMAP entre ton client et ton serveur mail, puis du SMTP entre ton serveur mail et le prochain relais SMTP.

Mais "_" est également souvent utilisé pour gettext/i18n (avec '_("text")').
Du coup, on le voit également souvent doublé pour éviter des conflits.

Tu peux tout à fait installer Linux sur un MacBook Pro récent (avec puce T2) ; il suffit de désactiver la vérification d'intégrité du bootloader.

Quant au clavier nul et au trackpad trop grand… c'est une question de goût, personnellement j'aime beaucoup ce nouveau clavier (bien plus que celui des vieux MacBook Air).

Mais d'un autre côté, le terrorisme ne fait quasiment aucun mort en France parce que la grande majorité des attentats a été déjouée. Si cela n'avait pas été le cas, les chiffres seraient peut-être différents.

De plus, lutter contre le terrorisme islamiste est aussi lutter contre la mise en place d'un État islamiste en France (c'est quand même leur but, à la base).

Python est sûrement l'un des plus polyvalents : admin sys (scripts « à l'ancienne » ou personnalisation d'Ansible), web, « middle » data (permet d'utiliser les outils Big Data pour tester des algos, par exemple), analyse de données, calcul numérique, …

Comment fais-tu pour savoir ce que les auteurs éprouvaient comme sentiments quand ils ont nommé le logiciel ?

Dans un monde de pub non ciblée et sans contrainte, c'est très simple : tu auras de la pub pour des sites de cul.
Si tu rajoutes des contraintes en interdisant le porno dans les applications (c'est le cas sur les iPhone, par exemple), tu auras de la pub pour des sites de rencontre.

Ah ? Pourquoi n'aurait-on pas le droit de regarder d'autres critères (par exemple, et même si ça ne s'applique pas toujours à Free, les conditions de travail des employés, la provenance des matières premières, etc.) ?

Mais une constitution peut très bien être changée. Simplement, les conditions pour la changer sont un peu plus contraignantes que pour une loi classique, pour éviter les changements sur un coup de tête.

Quand on dit « une mafia qui a réussi » essaye de t’imaginer un parrain de la mafia qui n’a plus d’état(s) qui luttent contre lui.

Il y a malheureusement beaucoup de cas, actuellement (quelques petits états d'Afrique complètement corrompus) ou dans l'Histoire. On peut difficilement dire qu'ils œuvrent pour le bien de l'humanité…

A priori c'est comme le SMTP : le numéro d'émetteur est purement indicatif.

À la place du numéro d'expéditeur. C'est par exemple le cas pour les textos envoyés par Chronopost pour te prévenir que tu as ton colis dans la main. À la place d'un numéro à 5 ou 10 chiffres, tu as « Chronopost ».

Dans le même genre, il est possible de choisir n'importe quel nom d'émetteur à la place du n°.
Ça doit être assez facile de faire du spoofing en se faisant passer pour quelqu'un de connu…