freem a écrit 4934 commentaires

La dernière fois que j'ai fait du c++, je n'ai pas réussi à linker un pointeur de fonction vers une fonction compiler avec un compilateur c. Le B.A.-BA. Je sais pas quelle pédanterie il aurait fallu (genre un proxy bien dégueulasse)…

Donnes-nous donc un PoC de ce qui rate, on pourra peut-être t'expliquer le pourquoi du comment?

Ceci dit, je me demande déjà ce que tu appelles lier un pointeur de fonction vers une fonction C… j'ai suffisamment codé en utilisant des lib C et pourtant je n'ai pas souvenir d'avoir eu ce type de problème?

Un truc genre

#include <cstdio>

int hello(int i, float j){puts("hello ");return 0;}
int world(int i, float j){puts("world!");return 0;}

int main(void)
{
  int (* pFoo) (int, float);
  pFoo = hello;
  pFoo(1,0.2);

  pFoo = world;
  pFoo(1,0.2);

  return 0;
}

compile parfaitement et fonctionne sans souci.

Bon, si c'est un souci de linkage, sache que j'ai fait le même genre de trucs avec la SDL 1.2, pour être précis, j'ai utilisé du std::unique_ptr avec SDL_Surface, en lui passant en destructeur la fonction qui remplace le destructeur. Donc, j'ai déjà fait aussi avec un truc compilé par un compilo C.

Le matériel, ça coûte cher, très cher à concevoir, c'est ça le souci.
Là ou un logiciel ne coûte quasiment rien à part du temps, du matériel nécessite d'avoir un véritable laboratoire, avec des composants qui ont un coût matériel.
Il y à aussi les compétences qui ne sont pas les mêmes: j'aurai tendance à dire que l'électronique nécessite des connaissances plus larges que la programmation, puisqu'en programmation on peut se reposer sur des bibliothèques qui nous évitent de nous taper le bas niveau: quand je code, disons, un casse-brique, je n'en ai rien à rien à faire de l'impédance des hauts-parleurs, ni de la fréquence du bus PCIe.

En électronique, tu dois (si ça marche de la même façon que ce que j'ai fait en STI électronique il y à 10 ans, bien sûr), commencer par étudier ton circuit dans un monde idéal pour avoir des calculs/formules qui tiennent à peu près la route, puis vérifier que le comportement ne posera pas de problèmes avec les marges d'erreur des composants que tu utilises (oui, parce qu'un condensateur, même si la théorie dit qu'il n'a qu'une capacité, en fait il à aussi une impédance, et ça impacte. Et même si un transistor en régime saturé bascule théoriquement d'un état à l'autre de façon instantanée, dans la pratique c'est complètement faux… entres autres.). Ces phases sont plus complexes que dans le cas d'un logiciel classique (on parle bien des bureaux là, hein?) ou il n'y à pas besoin d'être calé en maths (niveau seconde, à peu près: équation du 2nd degré quoi, et encore).
Bien sûr, une fois les calculs faits, en espérant ne pas s'être planté, il faut prototyper, histoire de tester. Là, il y à un premier coût en matos bien réel, qui n'existe pas en dev. Pire, si on s'est planté, on risque de cramer quelques composants.
Une fois cette étape passée, on à un prototype, l'équivalent d'une version debug d'un soft. C'est à dire un truc qui est gros, moyennement voire peu performant, et pas beau.
Il faut donc encore industrialiser tout ça, et je dois t'avouer: je n'ai aucune idée du coût que ça peut représenter, mais je doute que n'importe qui peut se le permettre.

Bien sûr, dans le cas d'apple, ils ne s'arrêtent pas là: une fois le matos fait, ils font également les pilotes… logiciels, qui ne sont pas non plus aussi simples à faire que des logiciels de bureau (j'insiste sur le "de bureau") j'imagine.

Le monde du libre, malgré quelques essais plus ou moins concluants (j'ai lu des doc sur une carte graphique il y à quelques mois), ne peut pas vraiment se payer un tel investissement, et même si c'était possible à cause de la faible échelle de production, ça coûterait nettement plus cher que du matos apple, pour des perfs ridicules (à cause du fait que le matos efficace ça coûte plus cher, et que des électroniciens dans leurs garages ne pourrons pas faire aussi bien qu'une horde d'ingénieurs spécialisés dans des labos de pointe).

Donc, pour le "pas trop compliqué" tu repasseras. Le matos, c'est bien ce qu'il y à de plus coûteux et de plus cher à développer amha. Et je n'ai bien sûr pas abordé la question des brevets…

simplement parce que la notion de binaire persistant n'existe pas en java.

J'aurai dis que c'est parce qu'en Java, il n'y à qu'une machine, une API, et un seul compilo (le tout, de référence, hein, je suis au courant qu'il existe des clones, mais l'interop est-elle si parfaite dans les faits? J'en sais rien…) en fait, alors que pour C++, il y à une pléthore de machines, une chiée d'OS différents qui impactent, et une flopée de compilos.
Forcément, ça rend les choses moins simples.

Je comprends pas, si gtk a eut le soutient de tout les gros acteurs, et est en c, c'est que l'abi du cpp pue (même aujourd'hui).

Pas de tous les gros acteurs, quand même, au moins nokia à soutenu Qt, au point de l'acheter.
Sinon, WxWidgets, même si je sais que ce n'est pas apprécié ici, à été utilisé par google (en version 2.9, je n'arrive pas à retrouver le lien en moins de 60s, mais si tu insistes, j'essaierais plus fort).
Bref, il n'y à pas que GTK, loin de là et heureusement.

Et pour ce qui est de l'ABI du C++, oui, c'est sûr, c'est moche, mais il y à des solutions, un peu plus bas un commentaire parle de pimpl. Je me suis aussi amusé à faire une archi de plug-in un jour, et donc me suis pas mal renseigné. Certes, c'est la merde, c'est clair, mais on peut contourner.

Si java a eut du succès c'est sûrement pas grâce aux qualité du c++.

En effet, Java est bien plus simple à maîtriser que C++, ce qui fait qu'il est intéressant pour pas mal de monde. Il y à aussi une grande quantité de dev Java, contrairement au C++.
Ce genre de choses jouent.

Qt utilise des pointeurs vers des struct pour masquer les évolutions de la structure interne et sauver son ABI.

Effectivement, c'est une des solutions utilisées pour contourner le problème.

e ne peux toujours pas prétendre connaitre le c++ globalement sur toutes les plateformes, je ne connais bien que le sous ensemble de ce qu'en fait Qt.

Je suis d'accord, C++ est un langage réellement riche, ce qui peut faire peur. Mais personne n'est obligé d'utiliser C++ au complet, non plus.
Dis-moi, est-ce plus simple d'optimiser la charge CPU en C qu'en C++? Et si oui, pourquoi? Je suis réellement intéressé par ta réponse pour le coup.

Aieuuuu…. la tuile de w8? Une innovation?

Moi, j'appelle ça une copie avec 10 ans de retard, mais bon… les twm sous linux, ça existe depuis perpette, hein. Je veux bien, à la rigueur, accepter le fait qu'ils aient fait un truc plus user-friendly, mais pas plus.
D'ailleurs, même dans windows, les tuiles existent plus ou moins depuis perpette, c'est juste que, bah, personne ne s'en sert (faut dire que c'est bien moins automatique qu'un wm full-tiling aussi).

Quand j'ai vu w8, et son système de tuile, je me suis dit que ça allait peut-être pas être si mal, j'ai même défendu ce truc à diverses reprises. Puis, j'en ai testé un dans je ne sais quel magasin. Et là, ben… changé d'opinion, genre changement radical.

Ça bouffe de la ressource à bloc, ce n'est pas aussi pratique que ça en à l'air, les icônes (puisque ce système reste mouse-oriented, elles sont importantes. À moins qu'il soit possible d'en fait un keyboard-oriented, mais j'en serais très surpris) absolument non évocatrices.
Je me souviens avoir essayé d'imprimer un truc sur la machine de ma mère (à sa demande), et ne m'en être sorti que parce qu'ils ont eu le bon goût de ne pas changer les raccourcis clavier depuis 20 ans.

Je ne parlerai même pas du fait qu'une interface tuilée, avec un seul workspace, c'est juste un wm castré. Enfin, là, y'a 2 workspace, pour être précis: un en tuile, un en stack. Youpi, mais non.

Mais mon opinion viens certainement du fait que j'utilise un wm réellement orienté vers les tuiles. Et un peu aussi vers les poweruser, je suppose. Je me demande ce que ça ferait si on collait un décorateur de fenêtres sur i3 d'ailleurs.

Et je suis obligé de pertinenter… mais surtout parce que je sais qu'un root sous linux peut péter le système sans le moindre souci, et ironiquement, j'ai envie de dire que ce n'est pas si mal: le système laisse son maître faire ce qu'il veut.
Mais effectivement, ce n'est pas user-proof.

Par rapport à l'auto-destruction de windows, je suppose que mes standards sont assez anciens, mais… j'ai encore récemment entendu parler de MaJ foireuses sur un w8.
Et quand je parle d'autodestruction, je parle d'une destruction sans action de la part de l'utilisateur, chose qui m'est arrivée tant de fois que je ne pourrais pas te dire combien. Mais, encore une fois, tant mieux si ça s'est amélioré sur les systèmes plus récents.

Tu as omis la réputation historique auprès des graphistes, je pense. Ils ont eu une base d'utilisateurs prêts à raquer à mort (milieu professionnel) lié au fait que, si je ne m'abuse, les MAC étaient les premières machines capables d'avoir un rendu à l'écran très proche du rendu imprimé.
Je gage d'ailleurs que c'est pour ça qu'ils ont développé leur réputation de truc cool: on vend pas à un graphiste un truc qui à une sale gueule, j'imagine.

C'est pas comme s'ils connaissaient réellement windows, de toute façon. Ou alors tu évolues dans un environnement 'achement plus savant que le mien…

GTK… tiens, je vais marcher dedans, pour le fun.

Me semblait que si GTK est plus utilisé que Qt, c'est parce qu'à l'origine, Qt n'était totalement libre. Les deux semblent plus ou moins autant utilisés en C++, au pifomètre.

Depuis 1992 on reproche les mêmes choses encore et encore au c++

Marrant, je pense qu'en fait, le premier standard (qui est de 98) à dû résoudre pas mal de problèmes, par exemple les soucis de compatibilité entre les compilo (du moins ceux qui acceptent de respecter les standards).

Les nouvelles normes foutent la merde? Je ne pense pas, honnêtement, je pense même que c'est tout le contraire.
Par exemple, si je prend C++11:
* std::array permets d'utiliser les algo standards avec des tableaux à dimension fixe, et donc de ne pas réinventer la roue. Ce n'est pas une mauvaise chose pour moi.
* std::unique_ptr, uniquement possible grâce à la move semantic, permets de lutter contre les memory leaks en augmentant la garantie qu'un seul propriétaire contrôle un espace mémoire (on peut contourner, comme toujours en C++, et je parie que cette possibilité est conservée du fait qu'on doive interagir avec du C…).
* for( auto i : foo ){ i*=10; }, c'est quand même vachement plus lisible (et sûr) que les alternatives plus anciennes for( int i = 0; i < foo.size(); ++i ){ foo[i]*=10; } ou for( std::vector<int>::iterator it = foo.begin(); it != foo.end(); ++it ){ *it*=10; } non?

Ça, c'est pour les critiques sur les nouvelles normes, mais pour être juste, je me dois de mentionner une fonctionnalité de C++03 (ou 98?) que seul commeau à implémenté, conseillant fortement aux autres dev de compilo de ne pas le faire, parce que ça n'apporte au final rien, semble-t-il. Quelques recherches devraient pouvoir en dire plus.

Maintenant, dire que C++ c'est de la merde contre le C… allez, je marche encore :)

Ça me fait assez sourire quand je vois des gens dire que C++ c'est de la merde comparé au C, en fait. Il suffit de lire du code C pour comprendre ce que C++ à ajouté.
La RAII permets de rendre un code bien plus maintenable et sûr, et les templates ou les fonctions inline permettent de s'affranchir en grande partie des macros, ce qui évite pas mal d'emmerdes.

Avant, les jeux, comme quake par exemple, étaient stables. Ils étaient codés en C. Il faut dire que, les malloc y étaient rares, tous les tableaux étant statiquement alloués, donc les problèmes de mémoire simples à éviter.
Ceci dit, j'ai quelques souvenirs de jeux pour lesquels le dépassement de buffer est simple à causer. En même temps, c'est logique: en C, il faut vérifier le retour de la moindre fonction, manuellement, pour être sûr que tout s'est passé comme prévu.
En C++, et dans tous les langages évolués, la mécanique des exceptions permets de s'affranchir de ce problème. Mais ici, l'avantage du C++ sur d'autres langages, c'est qu'on peut s'affranchir de ces fameuses exceptions.

Et quand on lit un code source C qui utilise de manière intensive de la construction de chaînes de caractères, quelle joie que de voir des buffer alloués avec des tailles impressionnantes, et ensuite une succession de strcat, parce que strcpy( foo, bar ); strcat( foo, "world" ); c'est vrai que c'est tellement plus lisible que foo += bar + "world";.

Je vais m'arrêter là, je pense. Je veux bien que l'on compare C++ avec Java, C# ou d'autres, mais avec le C… soyons sérieux un instant, le seul avantage que je puisse voir du C sur C++ réside de son ABI stable en toutes circonstances (utile pour les plugins).

Dans le cas du C++, l'ABI n'est stable que si l'on n'utilise pas de méthodes virtuelles, voire si l'on utilise des structures pures. En d'autres mots, si on se restreint à des fonctionnalités C.
Ah, non, il y a aussi un cas ou j'ai eu un comportement différent selon les compilos, mais il faut avouer que j'avais cherché la merde, et le workaround était relativement simple.
Ça, ça bug: foo( bar[++i], bar[++i], bar[++i] ); avec VS2008 "i" faut la même valeur à chaque fois, donc la même valeur est utilisée dans les 3 arguments, contrairement à ce que GCC fait. Et les deux comportements semblent être standards, pour une question d'optimisation. Pour l'info, le workaround était, de mémoire, ceci: foo( (bar[++i]), (bar[++i]), (bar[++i]) );.
Mais c'était une construction sale, qui n'avait pour unique but que celui de réduire encore un peu le nombre de lignes de code d'une encapsulation que j'avais fait autour d'une API sur laquelle je n'avais aucun contrôle et qui sans ça demandait de répéter les informations jusqu'à 3 fois, dans 3 fonctions différentes… (powerbuilder, vous connaissez?).

Le meilleur moyen de communication que je connaisse, ça reste d'aller dans les bar et les pubs.

Il y à aussi une technique pour invoquer les gens chez soi: servir l'apéro.

essaye d'ouvrir les fichiers attachés dans ce document (notamment les PDF/ZIP) avec n'importe quelle suite office (libre ou pas) sous Linux,

Je viens d'essayer avec Microsoft Office 2010 sous wine (donc, bien sous Linux) et ça marche je pense.
Quand tu utilises un format spécifique à un logiciel, il est logique qu'il faille utiliser le logiciel en question pour ouvrir le fichier…

Bref, dire que Linux est "prêt" n'est vrai qu'au cas par cas

Je suis d'accord.
Ceci étant dit, c'est la même chose pour Windows: la lenteur à toute épreuve, la faculté d'auto-destruction, l'empêchement de bidouiller en rond (oui, ça, c'est pas pour Mme Michu, mais dans tes arguments aussi, il y avait des trucs de geek), le gestionnaire de fenêtre tout sauf efficace, tout cela ne fonctionne que tant bien que mal dès lors que l'on à une machine qui n'est pas hyper performante.
Si on prend une machine de 10 ans d'âge, Windows (je parle d'un truc encore maintenu) n'est jamais prêt, alors que si on prend Debian, je la fait tourner avec bonheur sur une bécane "design for Windows Millenium". Une Debian stable, bien entendu.

Bref, dire que Windows est "prêt" n'est vrai qu'au cas par cas :) et je ne parle pas du fait que je ne connaisse aucun Microsoft Office qui sache ouvrir correctement un fichier de LO ;)

Ah, au sujet de MS Office, j'ai une anecdote. Figures-toi qu'il y à 5 ans, j'ai été obligé d'utiliser gnumeric pour pouvoir ouvrir correctement un fichier excel, ce dernier étant incapable de gérer correctement des formules qu'il avait générées lui-même (via l'outil interactif). La raison, c'est que l'éditeur de formules de ce truc n'était pas capable d'afficher (mais il les traitait puisque la formule fonctionnait) plus de 1024 caractères.
Comme quoi… les alternatives à MSO sont parfois plus efficaces que MSO sur le format MSO.

Je ne suis pas d'accord. Elle ne pourrait s'en balancer que si elle s'en apercevait, et je doute que ce soit le cas. Après tout, on parle bien de la personne qui utilise quotidiennement IE6 ou IE7?

Exact, je l'avais oubliée, mais faut dire qu'on s'y fait vite :)

+1 pour la résistance au changement. Il s'agit même d'une des facette du métier de chef de projet, que de lutter contre ça (selon des cours que j'ai eu).

Sinon… pour les innovations du bureau, de l'environnement graphique & co.
L'OP à cité un et un seul contre exemple, alors je vais me permettre de compléter:

• utiliser une touche pour déplacer et redimensionner les fenêtre sans s'emmerder à essayer de choper un coin (qui, quand il est arrondi, ne facilite pas les choses).
• les bureaux virtuels.
• ENFIN un usage pour la touche œ.
• ENFIN une solution SIMPLE pour taper des trucs comme: ÀÇÉÈÊ…
• les bureaux 3D, les vrais. Compiz-fusion, ça existe depuis bien longtemps, et les sélecteurs de fenêtres apportaient vraiment des choses utiles. Et pour les gens qui aiment ça, on pouvait transformer un bureau fonctionnel en bureau tape-à-l'œil.

Ça, c'est pour les bureaux classiques utilisables par les non geeks. Hé oui. pendant ce temps, Microsoft:

• enlève la possibilité de disposer ses fenêtres en mosaïques (faisable sous XP de la manière suivante: cliquer un bouton de fenêtre de la barre des tâches, appuyer sur la touche contrôle et cliquer sur une autre. Répéter cette étape jusqu'à avoir sélectionné toutes les fenêtres voulues, puis clic droit sur l'un des boutons et… lisez.). Idem, ce n'était pas difficile à utiliser, et surtout bien pratique.

Maintenant, passons aux fonctionnalités pour les "geeks" (j'ajouterai bien des guillemets mais ça deviendrai illisible): tiling window managers.
Je crois avoir lu que kwin supportait ce type de fonctionnalités à un moment, même sans utiliser un WM spécialisé. Franchement, les outils spécialisés se disent pour les geeks, mais quand on voit la difficulté d'utiliser i3… à mon avis c'est surtout parce que les dev ne veulent pas de trucs bling bling ni être emmerdés à devoir faire de l'assistance pour zombies.

Bref, non, ce n'est pas à cause de la facilité d'utiliser un truc pré-installé que seul Windows est prêt pour le bureau, mais à cause du fait que les habitudes ont la peau dure, très dure. Je connais tant de gens qui disent qu'il est compliqué d'installer un truc sous linux alors que sous Windows, c'est si "simple"!!

L'idée est fun, à voir comment ça va évoluer. Bon courage en tout cas.

Si on considère les possibilités, et non les usages effectifs, de l'assembleur, ce qui semble être le cas de la définition de wikipedia, alors leur catégorisation tiens la route, c'est surtout ça que je voulais dire.

Après… je n'ai pas assez de théorie des langages pour savoir si bidule ou machin est généraliste. D'ailleurs, franchement, je m'en cogne. Dans un langage, je veux surtout connaître son point fort et être capable de le lire/écrire aisément, ce qui n'est jamais le cas sans un minimum d'apprentissage, et ça ne tiens jamais sur 2 heures :)

En Java au bout de deux heures le simple utilisateur serait incapable de faire grand chose d'utile encore, car obligé de comprendre une plus grande part du langage avant de faire quelque chose.

Hum… je ne suis pas d'accord, en Java en 2H, tu peux apprendre à faire des trucs de base je pense. Bon, je suis biaisé, mais je pense qu'apprendre via un tuto qui explique un pendu en mode texte ou le "plus petit/plus grand" (toujours en mode texte, parce que c'est AMA clairement les trucs les plus simples à coder) doit être faisable pour un non dev (mais pour quelqu'un que ça intéresse et n'est pas 100% ignare en info, hein, faut pas pousser non plus).

Après, pour les dev de métier, c'est différent, ça dépend je pense surtout des langages racines qu'ils connaissent déjà. Quelqu'un qui connaît C ou C++ peut apprendre des trucs poussés en Java rapidement, mais ce ne sera peut-être pas le cas de quelqu'un qui ne connaît que lisp ou pascal par exemple?

Passe pas chez moi?

C'est un fait, que l'ASM est généraliste, surtout quand on lis la définition de généraliste:

A general-purpose language is a computer language that is broadly applicable across application domains, and lacks specialized features for a particular domain.

Traduction grossière: "Un langage généraliste est un langage informatique qui peut être utilisé pour un large éventail de domaines d'application, et manque de fonctionnalités spécialisées pour un domaine précis."
L'ASM entre effectivement dans cette catégorie, il me semble.

Si on prend la liste des DSL de wikipedia, on a, par exemple, HTML. Là, je ne pense pas qu'il soit nécessaire de démontrer qu'il ne s'agit pas d'un langage généraliste?

Du côté d'AWK, selon la liste des fonctionnalités de wikipedia, on à un langage capable de manipuler des fichiers textes. Bien, mais c'est quelque chose de quand même franchement généraliste, je trouve. Je ne dis pas que c'est pourri pour autant, certains langages généralistes sont meilleurs que d'autres dans des applications données, par exemple si on veut de la performance maximale, on s'orientera en général plutôt vers le C ou le C++, alors que si on veut un truc le plus robuste possible, ADA semble être le choix le plus pertinent.

Merci, je ne le savais pas. Ça me sera toujours utile un jour ou l'autre.

Mais bon, c'est bien ce que je dis: WTF! Un coup on mets 2 ";", un coup on en mets qu'un. Un coup on écrit une fin de bloc en faisant un miroir d'un mot-clé, un coup on utilise do/done en guise de début/fin de bloc…
Bref, ce "langage simple" ne l'est pas tant que ça, soyons réalistes.
Après, c'est sûr, si on demande à un connaisseur, ça lui semble simple. Après tout, lire et écrire du C++ ne me dérange pas plus que ça, alors je pourrais dire que c'est simple, mais soyons réaliste, ça ne l'est pas, même si ça me semble l'être.
Bah pareil pour shell.

Pour en revenir à shell (qui est le sujet de discussion, C++ n'était qu'un exemple, j'aurai pu prendre lisp, mais j'aurai été emmerdé pour citer des cas de syntaxes subtilement casse-pied, si on me les demande), je peux aussi citer les subtiles différences entre foo et $( foo ). Parce que je suis sûr qu'il y en a, même sans les connaître. Il y a aussi la gestion des chaînes de caractère, et pas mal de trucs qui deviennent rapidement complexes.
J'aimerai tant que les aficionados du shell comprennent que ce n'est pas un langage simple… ce qui ne signifie pas que c'est pas un mauvais langage, bien entendu. Il est efficace pour ce pour quoi il à été conçu après tout.
Et sur ce point très précis, systemd lui est supérieur.

awk est juste un petit langage (imparfait !) qui s'apprend en une heure ou deux sans aucun prérequis théorique

Hum… je suis toujours hyper sceptique quand on m'annonce que tel ou tel langage s'apprend en 2H… en 2H, tu apprendras peut-être les notions de base (pas les bases, hein, juste les notions de base) mais tu ne connaît pas un langage en 2H.

Pour info, quand j'étais à l'école, les profs passaient plus de 4 heure pour les structures de contrôle de base: if/then/else, do/while, while et for. Ce n'est pourtant pas bien compliqué, mais ils avaient jugé qu'il fallait plus de temps que ça.
Et si je lis bien, awk semble en être doté.
Il est aussi doté de choses comme les tableaux associatifs, chose absente dans le premier langage que j'ai appris, entres autres.

Bref, tu dis qu'il ne faut que 2H parce que toi, tu le connais déjà. Perso, je mettrai sûrement assez peu de temps à l'apprendre, mais je suis biaisé: je sais déjà programmer dans plusieurs autres langages. Ceci dit, je doute que je ne mettrai que 2H pour être capable de comprendre n'importe quel programme awk.

Déjà pas mal je suppose. Merci pour les tuyaux.

Je m'en sers dès qu'on ne m'impose pas de travailler avec des doc et docx, en fait. Et ça me casse nettement moins la tête :)

Bon, après, je t'accorde que je ne m'amuse pas à créer mes propres styles, ou ce genre de choses, qui ont l'air d'être effectivement plus complexes, je me contente d'utiliser ce qui existe, et je trouve que c'est nettement moins pénible que les 2 solutions que je connaissais avant: traitement de texte et HTML.

Je suppose que tout est relatif après. Quand on arrive à comprendre les erreurs de compilation de GCC 4.6 impliquant des templates, LaTeX semble assez simple xD

Modeste

Tant qu'il se prend pas pour Leroy…

Hum. LaTeX marche très bien aussi pour ce qui est de faire des documents propres, sans se prendre trop la tête, versionnable et diffables, et ça, putain que c'est agréable!!! (bon, tout texte brut l'est, c'est sûr, mais c'est surtout envers les traitements de texte que j'ai une dent).
Sans compter que ça évite de se faire pendre pour cause d'HTML dans le mail et qu'on peut même faire des petites macros pour s'épargner de retaper tout le temps des mots/noms/blocs de mots un peu trop longs :)