Re: vs

Oui, et ils confirment que le problème vient du code qui est affreusement lourd. À l'époque ils arrivaient aux mêmes temps de compilation qu'aujourd'hui car il y avait vraiment beaucoup moins de code à lire et interpréter.

J'apprécie quand un langage est expressif, qu'il permet d'exprimer des choses simplement, en abstrayant les détails techniques. Mais là, je pense sincèrement que l'architecture de roff est meilleure. Qu'on ne puisse pas gérer le traitement d'un bout de texte en moins d'une minute sur nos machines qui exécutent des milliards d'instructions à la seconde, c'est ridicule. Des giga de données pour savoir cracher un PDF, c'est ridicule tout pareil.

Ce qui ne veut pas dire que roff est parfait. Parmi les trucs à améliorer, je pense à :

1. la gestion des calculs. La gestion des nombres est un peu foireuse à mon avis, trop exotique.
2. quelques constructions de code qui ne sont pas intuitives.
3. la volonté d'économiser du temps d'écriture pour les auteurs est peut-être trop présente.
4. l'écriture des macros, qui pourrait être revue. À mon avis, baser les macros sur le langage TCL serait plutôt agréable à lire, écrire. Les macros seraient peut-être très légèrement plus longues, mais tellement plus lisibles. Et en plus ce serait accessible à plus de monde, car beaucoup plus intuitif et moins exotique.

J'ai même noté quelques citations drôles dans la documentation de groff hier.

[...] it is better not to use this feature to avoid confusion.

(dans la doc sur les séquences d'échappement)

Don’t use this command! [...]

(dans la doc des requête de dessin)

Despite of being silly, [...]

(également dans la doc des requêtes de dessin)