Emacs et «performance auto-renforçante»

En bref, ma question pour vous, les utilisateurs inconditionnels d'Emacs, est la suivante: avez-vous atteint cette "performance d'auto-renforcement" dont parle Steve Yegge ?

Emacs est auto-hébergé: y écrire des choses rend l'environnement lui-même plus puissant. C'est une boucle de rétroaction: un effet multiplicateur récursif, auto-renforçant qui se produit parce que vous améliorez l'environnement que vous utilisez pour créer des améliorations.

Pensez-vous vraiment que l'amélioration de vos Emacs vous a finalement rendu 10 fois plus productif et que votre productivité continue d'augmenter de façon exponentielle, et ainsi de suite?
Avez-vous des exemples / expériences à partager?

Quant à moi, j'utilisais à la fois Emacs et Vim pour le développement (collons actuellement avec Vim), mes .emacset .vimrcsont tous les deux assez configurés pour répondre à mes besoins et j'apprécie la puissance de ces deux éditeurs. Mais je n'ai pas fait l'expérience de la "boucle auto-renforçante" d'Emacs, ni rencontré quelqu'un qui l'a fait (bien sûr, cela pourrait être parce que je ne suis pas vraiment un Emacser hardcore et que je n'ai pas encore rencontré autant d'Emacsers).

Par exemple, sur Facebook, le gars à côté de moi utilisait Vim, et le gars à côté de lui utilisait Emacs. Tous deux ont été rapides et productifs comme l'enfer, et j'attribue cela non pas à l'éditeur qu'ils utilisaient, mais à leur propre intelligence et attitude.

Mais de toute façon, je serais heureux de voir des exemples étonnants de partisans d'Emacs qui me ramèneraient à l'église d'Emacs.

10 X plus productif ? Pas probable. J'ai tendance à penser que les facteurs multiplicatifs ressemblent plus à 1,1, ce qui s'additionne après un certain temps.

Ce dont parle Steve Yegge est vraiment une réflexion sur l' expertise d'Emacs, et ceux-ci sont très rares. Les personnes qui atteignent cet effet multiplicatif personnalisent activement leur expérience Emacs en écrivant elisp pour adapter Emacs à leurs besoins spécifiques. Par exemple, Yegge a écrit des éjacs . L'interprétation de la citation de Yegge implique strictement que vous personnalisez Emacs pour faciliter la personnalisation / l'extension d'Emacs.

Voici comment je décomposerais les différents niveaux d'expertise qui s'appliquent à Emacs:

• Un novice sait comment exécuter Emacs, déplacer le curseur, effectuer des modifications, quitter Emacs.
• Un débutant avancé sait comment mettre quelques personnalisations de base dans leur .emacs, ou a complètement copié des morceaux d'autres personnes .emacsdans le leur. Ils savent comment faire des liaisons de clés globales, requiredes packages intégrés, activer des modes mineurs.
• Les utilisateurs Emacs compétents ont de gros .emacsfichiers, éventuellement divisés en plusieurs fichiers. Ils téléchargent et utilisent des packages non standard, savent comment trouver la documentation des commandes, des modes, affichent les raccourcis clavier existants, sont à l'aise avec les différences entre les modes mineurs et les modes majeurs. Les utilisateurs compétents conservent généralement une seule instance d'Emacs pendant des jours / semaines, écrivant, compilant, exécutant et déboguant des programmes à partir de leurs Emacs.
• Les utilisateurs compétents sont à l'aise pour écrire des lisp emacs, créant leurs propres commandes interactives, et sont à l'aise pour écrire des modes mineurs. Les utilisateurs expérimentés examinent le code lisp emacs pour mieux comprendre les modes qu'ils utilisent, utilisent le débogueur elisp et utilisent généralement des processus inférieurs (shells, processus lisp, ...).
• Les utilisateurs experts d' Emacs écrivent de nouveaux modes majeurs à partir de zéro, recherchent et modifient le code C pour Emacs, savent ce qu'est l' édition récursive et l'utilisent, utilisent la communication interprocessus pour intégrer Emacs avec des outils externes. Ils ont également lu la liste de diffusion emacs-devel .

Et puisque vous demandez une expérience personnelle, voici des exemples de ce que j'ai personnellement fait pour donner l'impression d'être plus productif. Remarque: il se trouve que je travaille dans une entreprise où nous sommes loin de la pointe des environnements de développement, par exemple, nous utilisons toujours CVS.

• J'ai intégré Emacs à l'outil de suivi des bogues: lorsque je fais des commits, il enregistre le nom de fichier et la version dans les champs du bogue, et à partir d'Emacs je peux voir mes bogues, les affecter, les résoudre, etc.
• J'ai écrit un pont reliant mon produit (travail de jour) et Emacs, ce qui fait de mon produit un processus inférieur - me permettant d'apporter des modifications au code source à la volée.
• J'ai étendu la gestion des TAGS avec find-file-in-tags qui fournit un certain nombre de raccourcis qui conviennent à mon environnement de développement.
• J'ai écrit un mode qui prend les résultats de la régression et me permet de passer aux échecs, d'examiner les fichiers journaux, de réexécuter un ou plusieurs tests ou de lancer un débogage, avec un minimum de frappes.
• Mon rapport de situation hebdomadaire (oui, j'utilise Emacs pour le courrier électronique) est généré automatiquement à l'aide des commits que j'ai effectués tout au long de la semaine.

Ce sont des changements que j'ai apportés pour adapter spécifiquement Emacs à mon environnement et à mon flux de travail.

Suis-je 10 fois plus productif que les autres autour de moi? Non.

Cependant, pour mon travail quotidien, il y a de nombreuses tâches que je peux faire avec quelques touches que d'autres passent beaucoup plus de temps à faire dans leur environnement non personnalisé, et qui les obligent généralement à basculer entre leur éditeur et un navigateur Web ou un shell .

Sont-ils des exemples étonnants? Non, je suis sûr qu'une grande partie de ce que j'ai fait est déjà disponible dans Visual Studio . Mon article vous ramènera-t-il à l'église d'Emacs? Probablement pas.

Cependant, si vous voyez un modèle de comportement dans votre environnement de développement, et que vous avez cette démangeaison qui vous dit: "Je ne devrais vraiment pas avoir à faire X / Y / Z encore et encore, si je pouvais seulement ..." alors Je recommande d'essayer d'utiliser Emacs pour éliminer cette démangeaison. Cette égratignure pourrait être le premier pas sur cette voie "auto-renforçante" dont parle Steve Yegge.

Remarque mineure: je ne sais pas que de nombreux utilisateurs d'Emacs vraiment experts utilisent activement les sites de débordement de pile ou, du moins, ne répondent pas aux questions liées à Emacs. Je dis cela en fonction des meilleurs utilisateurs pour les balises emacs et elisp sur le débordement de la pile.

Ces preuves sont anecdotiques, bien sûr, mais votre question appelle explicitement des preuves anecdotiques.

Je suis un étudiant effectuant des recherches dans un laboratoire universitaire qui implique des tas de calculs scientifiques ainsi que l'écriture. Dans un tel environnement (pensez: python, SQL, utilitaires académiques à ligne de commande spéciale, fichiers texte, LaTeX / BibTeX), l'apprentissage d'emacs a fait à peu près la différence entre une truelle à main et une pelle rétro. Après un an d'emacs (au cours duquel je me considérerais comme un solide compétent avec un orteil plongeant dans compétent), Je suis impatient de gérer les problèmes que redoutent mes camarades de laboratoire. Non pas parce qu'ils sont paresseux et que je suis diligent, mais parce que c'est amusant de démolir des montagnes avec une pelle rétrocaveuse et difficile de se gratter sur une montagne avec une truelle. Une fois au moins à deux reprises, mon équipe avait commencé à discuter de la nécessité d'apporter des modifications compliquées au format du rapport, pour constater que la tâche avait déjà été accomplie avant même d'avoir fini de se disputer sur qui devait le faire. Regexp replace + embedded elisp.

Donc au premier ordre, oui, emacs m'a rendu beaucoup plus productif.

Il semble que vous posiez des questions sur les gains de productivité dans le sens du deuxième ordre: est-ce que mes retours sur emacs sont composés? Bien que je ne me juge pas totalement compétent , sans parler de Yegge , je pense que je commence à voir le pied de la courbe exponentielle, et que mon utilisation d'emacs rend encore plus productif l'émaciation. Quelques statistiques anecdotiques brèves du repo pour quantifier cela:

• Dans une équipe de 7 personnes, j'étais responsable de plus de la moitié des commits. En ajustant pour l'ancienneté, je m'engage toujours presque deux fois plus souvent. Pas parce que je suis presque deux fois plus génial, mais parce qu'emacs gère le contrôle de version pour moi. Parce que je peux valider, mettre à jour et fusionner sans douleur, je vérifie avec de plus petits morceaux discrets, comme nous devrions tous le faire. Mais cela signifie que je me sens plus libre de prendre des "risques plus importants" (je dois mentionner que nous écrivons du code expérimental pour la recherche scientifique, pas pour la production), ce qui signifie que j'apprends plus sur la programmation et mon sujet.

• Dans le dernier rapport que nous avons écrit, svn blame me dit que j'étais responsable de plus de lignes que trois fois les deux autres auteurs réunis . (Ce n'est pas seulement parce que j'ai eu le dernier commit. J'étais curieux à ce sujet pendant un certain temps, alors j'ai commencé à le suivre et les résultats ont été assez stables tout au long de l'historique de la version.) Parce que je suis 6 fois un écrivain plus rapide? Non: car emacs est une tronçonneuse pour le texte. Cela signifie que je peux faire les types de chirurgie LaTeX que je n'aurais jamais pris la peine d'essayer auparavant. Ce qui signifie que je finis par mieux comprendre LaTeX, ce qui me rend encore plus productif à l'avenir.

• 100% de la documentation (pour le code et les notes de recherche internes) est à moi. Parce que mes collègues de laboratoire ne se soucient pas de la documentation? Eh bien, je ne m'en souciais pas vraiment avant de trouver le mode org. Bien que je sois généralement de type B sur ces choses, le mode org s'est transformé en une légère dépendance. L'exportation instantanée d'Org-mode vers du HTML agréable à regarder et LaTeX a supprimé tous les obstacles à une documentation responsable et l'a transformée en une sorte de jeu. Alors maintenant je le fais. Si ce n'était pas le cas, je ne le ferais pas, ou du moins je le redouterais, je le mettrais de côté et le laisserais perdre l'énergie mentale.

D'autres commentateurs suggèrent que le lien de causalité peut être précisément à l'envers: peut-être qu'emacs récompense les personnes très productives, ce qui priverait la confiance de l'hypothèse selon laquelle l'utilisateur médian est susceptible de bénéficier de gains. Je pourrais également suggérer une sorte d'effet placebo auto-réalisateur: si emacs m'a rendu plus productif (et bien sûr, nous ne le saurons jamais, puisque je n'ai pas de jumeau identique qui n'a pas appris emacs), j'ai a certainement connu une révélation dans ma relation au texte structuré. Je suis ravi d'utiliser emacs, ce qui signifie que je l'utilise plus, ce qui signifie que j'en apprends plus à ce sujet, que je suis plus excité, etc. Quand j'ai découvert le mode BibTeX, je me souviens avoir eu l'impression d'avoir demandé à une fille de sortir pour mon premier rendez-vous.

Au cas où vous l'auriez manqué: emacs m'a étonné à l'idée de modifier des bases de données bibliographiques. Dans mon travail, cela vaut quelque chose, je pense.

Par exemple, sur Facebook, le gars à côté de moi utilisait Vim, et le gars à côté de lui utilisait Emacs. Tous deux ont été rapides et productifs comme l'enfer, et j'attribue cela non pas à l'éditeur qu'ils utilisaient, mais à leur propre intelligence et attitude.

Cette remarque sonne très vrai et s'applique quelque peu à tous les types de conseils de productivité.

Les personnes qui souhaitent augmenter / optimiser leur productivité ont tendance à être plus productives en raison de leur concentration ou de leur comportement dans la vie, quelle que soit l'efficacité de la pointe de productivité elle-même.

Cela pourrait se résumer comme suit: "Vous n'êtes pas un meilleur développeur parce que vous utilisez Emacs ou Vim, mais le genre de personnes suffisamment dévouées pour maîtriser ces outils a tendance à être un bon développeur" [1].

1. C'est une horrible généralisation donc ce n'est pas une vérité absolue et cela ne veut pas dire grand-chose de toute façon (qu'est-ce qu'un bon / mauvais développeur? Etc.)

Je suis un utilisateur d'Emacs depuis environ 20 ans maintenant, et je dois dire que non, je n'ai pas atteint ce point.

Pour arriver à l '"emacsvana" dont il parle, vous devez vraiment vous faire un expert élisp . J'ai fait un peu, mais mes compétences se terminent vraiment au niveau de la possibilité de configurer un nouveau mode que quelqu'un d'autre a écrit. Essayer de déboguer (ou Dieu ne plaise pas) l'élisp de quelqu'un d'autre me dépasse un peu, et écrire le mien à partir de rien n'est même pas une pensée.

Il s'agit d'une personne qui a déjà utilisé lisp et qui possède plus de 20 ans d'expérience en développement logiciel professionnel.

Peut-être que je suis juste un wuus ou quelque chose, mais je soupçonne que très peu d'utilisateurs d'Emacs en arrivent au point dont il parle.

Il n'y a vraiment rien de mal à cela. Je sais comment créer des macros, ce qui à lui seul me rend beaucoup plus productif avec Emacs que je ne peux l'être avec n'importe quel autre éditeur de texte. À l'occasion, beaucoup plus que 10 fois plus productif. Cependant, cela ne me rend pas meilleur que quelqu'un qui connaît vi aussi bien (car il peut aussi faire des macros).

Non, je ne l'ai pas fait, et je n'ai jamais entendu parler de quelqu'un qui l'a fait. Je ne pense pas que cela arrive. Je pense que Steve Yegge fait ce que font les blogueurs populaires: il fait une déclaration controversée et exagérée pour faire passer son message et être plus visible. Je ne pense pas qu'il le pense comme tel. Ce qu'il a probablement l'intention de communiquer est le suivant: "Emacs est vraiment efficace pour commencer, et si vous le personnalisez beaucoup, vous apprenez à être encore plus efficace avec lui, ce qui est génial, mmm-kay?"

S'il venait de dire cela, vous ne seriez pas confus et il n'aurait pas la moitié autant de lecteurs.

Regardez-le de cette façon: Emacs et Vim excellent dans la chirurgie du texte et l'automatisation des frappes répétitives, sans parler de la navigation de gros morceaux de texte. C'est de cela que parle Yegge, bien que d'une manière plus prêche.

Si vous avez un fichier de 10000 lignes où vous devez ajouter un numéro de ligne au début de chaque ligne, vous pourriez aussi bien passer une demi-journée à le faire manuellement dans le Bloc-notes.

Ou, lancez une macro ou utilisez une fonction Emacs intégrée pour ce genre de chose. Vous économisez ensuite une demi-journée de travail et vous êtes plus de 10 fois plus productif.

Il s'agit de détecter la répétition et de l'éliminer. Cela nécessite de l'intelligence, de l'expérience, de la pratique et des compétences, donc tous ceux qui utilisent Emacs ne verront pas les gains de productivité.

Je ne connais pas "N fois plus vite", mais un ajout soigneux des fonctions utilitaires peut rendre Emacs assez bon pour remplir des modèles. Combinez cela avec un peu de connaissance du langage cible et vous pouvez faire des choses comme "dire à emacs que vous voulez qu'une fonction soit créée, lui dire les arguments d'entrée (types, si le langage nécessite des informations de type) et renvoyer une valeur, demander à emacs de créer un squelette pour plus remplir".