Emacs contre Vim

Je suis tombé sur ce commentaire sur reddit:

How do you manage files? Using a file manager of course. Vi is a great editor, it's not a file manager. The Unix way is do one thing and do it well, programs that try to do everything suck.

"Comment gerez-vous les fichiers? En utilisant un gestionnaire de fichier, évidemment. Vi est un bon éditeur, ce n'est pas un gestionnaire de fichiers. La philosophie Unix est de ne faire qu'une chose mais la faire bien, les programmes qui essaient de tout faire sont 'nazes'."

Ce commentaire a retenu mon attention car c'est l'un des points de départ de Lama.

La guerre de clochers entre Vim et Emacs est représentative d'un type de choix qui se présente souvent dans l'univers du logiciel: utiliser de petits logiciels spécialisés et performants dans leur domaine, ou un gros logiciel tout-en-un.

Contrairement à ce que pense ce commentateur, il n'y a pas un bon choix et un mauvais choix, car les avantages d'une alternative sont les inconvénients de l'autre.

Les logiciels tout-en-un comme Emacs, Opera ou les suites logicielles ont l'avantage de l'intégration: les différentes parties du logiciel dédiées à certaines tâches s'échangent général facilement les données, et l'interface utilisateur est cohérente. Le revers de la médaille est que ce sont en général des logiciels énormes, parfois limités dans les domaines qu'ils couvrent, et relativement fermés sur eux-mêmes. Si une des parties du logiciel est boguée ou a des capacités trop limitées par rapport à vos besoins, vous perdez beaucoup des avantages du logiciel intégré car vous devez contourner ses handicaps. Bien souvent, il faut attendre longtemps que ces points bloquants soit résolus par une mise à jour, car la taille du logiciel confère une grande inertie au projet.

Les logiciels spécialisés sont plus petits et plus pointus. Ils sont en général conçus pour communiquer avec d'autres logiciels, donc on peut choisir quel logiciel on utilise pour chaque tâche ou domaine. Le revers de la médaille est que la communication n'est pas toujours efficace. Il faut parfois faire soi-même les adaptations nécessaires pour faire communiquer deux logiciels, et le résultat n'est pas toujours satisfaisant. L'interface utilisateur est aussi fortement hétérogène, car chaque logiciel définit son interface utilisateur, malgré les personnalisations possibles. Enfin, bien que chaque logiciel spécialisé soit individuellement beaucoup plus petit que le logiciel tout-en-un, la taille cumulée de tous les logiciels spécialisés peut excéder celle du logiciel tout-en-un.

Comment réconcilier intégration et liberté de choix?
Une solution presque satisfaisante serait de définir une interface de communication entre logiciels vraiment standard. C'est le créneau qu'occupe XML sur le web en ce moment, et qui a été transposé pour certaines applications de bureau. Mais XML est à mon avis le pire standard de communication possible. Certains ont je crois déjà transposé cette remarque désobligeante qui portait à l'origine sur les expressions régulières: "ils ont choisi les expressions régulières pour tenter de résoudre leur problème. Maintenant ils ont deux problèmes". La communication par un format texte comme celui de XML est, pour commencer, complètement inefficace. Donc inadaptée à des gros volumes de données ou à des traitements ultra-rapides. L'idée absurde d'utiliser les syntaxe de balise de HTML n'arrange rien.

Une autre solution est de programmer ces logiciels dans un langage unique, et de faire communiquer ces logiciels par l'intermédiaire d'une programmation dans ce langage, qui servirait également de langage de script et de configuration. C'est je crois l'idée de TCL, qui a connu un certain succès à une époque. Le principe est bon, mais TCL n'est plus en vogue sans doute pour deux raisons: sa syntaxe et son mode de fonctionnement un peu particuliers, et son inefficacité.
Python est sans doute le TCL d'aujourd'hui. C'est un langage que je pourrais utiliser (ou plutôt Lua, qui est moins populaire, mais plus efficace et plus simple - j'en ai déjà parlé), mais je doute que l'utilisateur type de Lama tel que je me le représente l'apprécierait (c'est un langage de programmeur)

Lama est une tentative de reprendre cette idée en l'améliorant: être accessible à ceux qui ne programment pas toute la journée, être efficace et être ouvert.