Emacs y "rendimiento autorreforzante"

En resumen, mi pregunta para los usuarios hardcore de Emacs es la siguiente: ¿han logrado este "rendimiento autorreforzante" del que habla Steve Yegge ?

Emacs se aloja a sí mismo: escribir cosas en él hace que el entorno en sí sea más poderoso. Es un ciclo de retroalimentación: un efecto recursivo, autorreforzante y multiplicativo que ocurre porque estás mejorando el entorno que estás utilizando para crear mejoras.

¿ Realmente siente que mejorar sus Emacs eventualmente lo hizo 10 veces más productivo , y su productividad continúa aumentando exponencialmente, y así sucesivamente?
¿Tienes algunos ejemplos / experiencia para compartir?

En cuanto a mí, yo estaba usando ambas Emacs y Vim para el desarrollo (actualmente seguir con Vim), mi .emacsy .vimrcson a la vez muy configurado a la habitación de mis necesidades y aprecio poder de ambos de estos editores. Pero no experimenté este "ciclo de autorreforzamiento" de Emacs, ni conocí a alguien que sí lo hizo (por supuesto, esto podría ser porque no soy realmente Emacser incondicional, y todavía no he conocido a tantos Emacsers).

Por ejemplo, en Facebook, el chico a mi lado estaba usando Vim, y el chico a su lado estaba usando Emacs. Ambos fueron rápidos y productivos como el infierno, y lo atribuyo no al editor que estaban usando, sino a su propia inteligencia y actitud.

Pero de todos modos, me alegraría ver ejemplos sorprendentes de los defensores de Emacs que me devolverían a la Iglesia de Emacs.

10 veces más productivo ? No es probable. Tiendo a pensar que los factores multiplicativos se parecen más a 1.1, que se acumula después de un tiempo.

De lo que Steve Yegge está hablando es realmente una reflexión sobre ser un experto en Emacs, y eso es muy raro. Las personas que están logrando este efecto multiplicativo están personalizando activamente su experiencia con Emacs al escribir elisp para adaptar Emacs a sus necesidades específicas. Por ejemplo, Yegge escribió ejacs . Interpretar la cita de Yegge implica estrictamente que está personalizando Emacs para que sea más fácil personalizar / extender Emacs.

Así es como desglosaría los diversos niveles de experiencia que se aplican a Emacs:

• Un novato sabe cómo ejecutar Emacs, mover el cursor, hacer algunas ediciones y salir de Emacs.
• Un principiante avanzado sabe cómo poner algunas personalizaciones básicas en ellos .emacs, o ha copiado completamente fragmentos de otras personas .emacsen los suyos. Saben cómo hacer enlaces de teclas globales, requirepaquetes integrados, habilitar modos menores.
• Los usuarios competentes de Emacs tienen .emacsarchivos grandes , posiblemente divididos en múltiples archivos. Descargan y usan paquetes no estándar, saben cómo encontrar documentación para comandos, modos, ven las combinaciones de teclas existentes, se sienten cómodos con las diferencias entre los modos menores y los modos principales. Los usuarios competentes generalmente mantienen una sola instancia de Emacs ejecutándose durante días / semanas, escribiendo, compilando, ejecutando y depurando programas desde sus Emacs.
• Los usuarios expertos se sienten cómodos escribiendo emacs lisp, creando sus propios comandos interactivos, y se sienten cómodos escribiendo modos menores. Los usuarios expertos miran el código emacs lisp para obtener una mejor comprensión de los modos que están usando, usan el depurador elisp y comúnmente usan procesos inferiores (shells, procesos lisp, ...).
• Los usuarios expertos de Emacs escriben nuevos modos principales desde cero, miran y modifican el código C para Emacs, saben qué es la edición recursiva y la usan, usan la comunicación entre procesos para integrar Emacs con herramientas externas. También leen la lista de correo de emacs-devel .

Y dado que está pidiendo experiencia personal, aquí hay ejemplos de lo que he hecho personalmente que me hace sentir que soy más productivo. Nota: Trabajo en una empresa en la que no estamos cerca de la vanguardia de los entornos de desarrollo, por ejemplo, todavía usamos CVS.

• Integré Emacs con la herramienta de seguimiento de errores: cuando hago commits, registra el nombre de archivo y la versión en los campos del error, y desde Emacs puedo ver mis errores, asignarlos, resolverlos, etc.
• Escribí un puente que conectaba mi producto (trabajo diario) y Emacs, convirtiendo efectivamente mi producto en un proceso inferior, permitiéndome realizar cambios en el código fuente sobre la marcha.
• Extendí el manejo de TAGS con find-file-in-tags que proporciona una serie de accesos directos que se adaptan a mi entorno de desarrollo.
• Escribí un modo que toma resultados de regresión y me permite saltar a fallas, examinar archivos de registro, volver a ejecutar una o más pruebas o ingresar una ejecución de depuración, con un mínimo de pulsaciones de teclas.
• Mi informe de estado semanal (sí, uso Emacs para el correo electrónico) se genera automáticamente utilizando los compromisos que he realizado durante la semana.

Esos son los cambios que he hecho para adaptar específicamente Emacs a mi entorno y mi flujo de trabajo.

¿Soy 10 veces más productivo que otros a mi alrededor? No.

Sin embargo, para mi trabajo diario, hay muchas tareas que puedo hacer con un par de pulsaciones de teclas que otros pasan mucho más tiempo haciendo en su entorno no personalizado, y que generalmente requieren que cambien entre su editor y un navegador web o un shell .

¿Son ejemplos asombrosos? No. Estoy seguro de que gran parte de lo que he hecho ya está disponible en Visual Studio . ¿Te devolverá mi artículo a la Iglesia de Emacs? Probablemente no.

Sin embargo, si ve un patrón de comportamiento en su entorno de desarrollo y tiene ese picor que le dice: "Realmente no debería tener que hacer X / Y / Z una y otra vez, si solo pudiera ..." Recomiendo tratar de usar Emacs para rascar esa picazón. Ese rasguño podría ser el primer paso en ese camino "autorreforzante" del que habla Steve Yegge.

Nota menor: no sé que muchos (¿alguno?) Usuarios verdaderamente expertos de Emacs están utilizando activamente los sitios de desbordamiento de pila, o, al menos, no están respondiendo preguntas relacionadas con Emacs. Lo digo en función de los principales usuarios de las etiquetas emacs y elisp en el desbordamiento de pila.

Esta evidencia es anecdótica, por supuesto, pero su pregunta explícitamente requiere evidencia anecdótica.

Soy un estudiante que hace investigación en un laboratorio académico que involucra montones de computación científica y escritura. En dicho entorno (piense: python, SQL, utilidades académicas de línea de comandos especiales, archivos de texto, LaTeX / BibTeX), el aprendizaje de emacs marcó la diferencia entre una llana de mano y una retroexcavadora. Después de un año de emacs (en el que me calificaría como Competente sólido con un dedo del pie sumergido en Competente)), Me encuentro ansioso por manejar los problemas que temen mis compañeros de laboratorio. No porque sean flojos y yo soy diligente, sino porque es divertido derribar montañas con una retroexcavadora y oneroso rascarse una montaña con una llana. En al menos dos ocasiones, mi equipo comenzó a discutir sobre hacer un cambio complicado en el formato del informe, solo para descubrir que la tarea ya se había completado antes de que incluso terminaran de discutir sobre quién tenía que hacerlo. Regexp replace + incrustado elisp.

Entonces, en el sentido de primer orden, sí, emacs me ha hecho mucho más productivo.

Parece que está preguntando acerca de las ganancias de la productividad en el sentido de segundo orden: ¿se componen mis retornos de emacs? Aunque no me calificaría como totalmente competente , y mucho menos a Yegge , creo que estoy empezando a ver el pie de la curva exponencial, y que mi uso de emacs hace que el emacc sea aún más productivo. Algunas estadísticas breves y anecdóticas del repositorio para cuantificar esto:

• En un equipo de 7, fui responsable de más de la mitad de los commits. Ajustándome por antigüedad, todavía me comprometo casi el doble de veces. No porque sea casi el doble de asombroso, sino porque emacs casi maneja el control de versiones por mí. Debido a que puedo comprometerme, actualizarme y fusionarme sin problemas, me registro con fragmentos discretos más pequeños, como todos deberíamos hacer. Pero eso significa que me siento más libre para tomar "riesgos mayores" (debo mencionar que estamos escribiendo código experimental para investigación científica, no para producción), lo que significa que aprendo más sobre programación y mi tema.

• En el último informe que escribimos, svn blame me dice que fui responsable de más líneas que tres veces los otros dos autores combinados . (Esto no es solo porque tuve la última confirmación. Tenía curiosidad sobre esto por un tiempo, así que comencé a rastrearlo y los resultados fueron bastante estables en todo el historial de versiones). ¿Porque soy 6 veces un escritor más rápido? No: porque emacs es una motosierra para texto. Esto significa que puedo hacer los tipos de cirugía LaTeX que nunca me hubiera molestado en probar antes. Lo que significa que termino entendiendo más sobre LaTeX, lo que me hace aún más productivo en el futuro.

• El 100% de la documentación (tanto para el código como para las notas de investigación internas) es mía. ¿Porque a mis compañeros de laboratorio no les importa la documentación? Bueno, tampoco me importó antes de encontrar el modo org. Si bien generalmente soy súper-tipo-B sobre estas cosas, el modo org se convirtió en una adicción leve. La exportación instantánea de Org-mode a html de aspecto agradable y LaTeX eliminó todas las barreras a la documentación responsable y la convirtió en una especie de juego. Entonces ahora lo hago. Si no fuera así, no lo haría, o al menos lo temería, lo pospondría y dejaría que derramara energía mental.

Otros comentaristas sugieren que la conexión causal puede ser precisamente al revés: tal vez emacs recompense lo altamente productivo, lo que robaría la confianza de la hipótesis de que el usuario medio probablemente disfrutará de cualquier ganancia. También podría sugerir un tipo de efecto placebo autocumplido: si emacs me ha hecho más productivo (y, por supuesto, nunca lo sabremos, ya que no tengo un gemelo idéntico que no haya aprendido emacs), tengo ciertamente experimenté una epifanía en mi relación con el texto estructurado. Estoy emocionado de usar emacs, lo que significa que lo uso más, lo que significa que aprendo más al respecto, me emociono más, etc. Cuando descubrí el modo BibTeX, recuerdo sentir que acababa de invitar a una chica a salir en mi primera cita.

En caso de que te lo hayas perdido: emacs me hizo aturdir la idea de editar bases de datos bibliográficas. En mi trabajo eso vale algo, creo.

Por ejemplo, en Facebook, el chico a mi lado estaba usando Vim, y el chico a su lado estaba usando Emacs. Ambos fueron rápidos y productivos como el infierno, y lo atribuyo no al editor que estaban usando, sino a su propia inteligencia y actitud.

Este comentario suena muy cierto y es algo aplicable a todo tipo de consejos de productividad.

Las personas que están interesadas en aumentar / optimizar su productividad tienden a ser más productivas debido a su enfoque o comportamiento en la vida, independientemente de la eficiencia de la punta de productividad en sí.

Podría resumirse como: "No eres un mejor desarrollador porque estás usando Emacs o Vim, pero el tipo de personas que están lo suficientemente dedicadas a dominar estas herramientas tienden a ser buenos desarrolladores" [1].

1. Esta es una generalización horrible, por lo que no es una verdad absoluta y no significa mucho de todos modos (¿qué es un desarrollador bueno / malo? Etc.)

He sido un usuario de Emacs durante unos 20 años y tengo que decir que no, no he llegado a ese punto.

Para llegar al "emacsvana" del que habla, realmente tienes que convertirte en un elisp experto en . He hecho un poco, pero realmente mis habilidades casi terminan en el nivel de poder configurar un nuevo modo que alguien más escribió. Intentar depurar (o Dios no quiera arreglar) el elisp de otra persona está un poco más allá de mí, y escribir el mío desde cero ni siquiera un pensamiento.

Esto es de alguien que realmente ha usado lisp antes y tiene más de 20 años de experiencia profesional en desarrollo de software.

Quizás solo estoy siendo un wuus o algo así, pero sospecho que muy pocos usuarios de Emacs llegan al punto del que está hablando.

No hay nada malo en eso realmente. Sé cómo hacer macros, lo que solo me hace mucho más productivo con Emacs de lo que puedo ser con cualquier otro editor de texto. En ocasiones, mucho más de 10 veces más productivo. Sin embargo, no me hace mejor que alguien que conoce vi igualmente bien (ya que también puede hacer macros).

No, no lo he hecho, y nunca he oído hablar de nadie que lo haya hecho. No creo que pase. Creo que Steve Yegge está haciendo lo que hacen los bloggers populares: está haciendo una declaración controvertida y exagerada para expresar su punto de vista y ser más visible. No creo que lo diga en serio. Lo que probablemente intenta comunicar es esto: "Emacs es realmente eficiente para empezar, y si lo personalizas mucho, aprendes cómo ser aún más eficiente con eso, lo cual es genial, mmm-kay".

Si hubiera dicho eso, no estarías confundido y él no tendría la mitad de lectores.

Míralo de esta manera: Emacs y Vim sobresalen en la cirugía de texto y la automatización de pulsaciones repetitivas, sin mencionar la navegación de grandes fragmentos de texto. Esto es de lo que habla Yegge, aunque de una manera más predicadora.

Si tiene un archivo de 10000 líneas donde debe agregar un número de línea al comienzo de cada línea, también podría pasar medio día haciéndolo manualmente en el Bloc de notas.

O, inicie una macro o use una función incorporada de Emacs para este tipo de cosas. Luego ahorras medio día de trabajo y eres más de 10 veces productivo.

Se trata de detectar la repetición y eliminarla. Eso requiere inteligencia, experiencia, práctica y habilidad, por lo que no todos los que usan Emacs verán beneficios de productividad.

No sé acerca de "N veces más rápido", pero una adición cuidadosa de las funciones de utilidad puede hacer que Emacs sea bastante bueno para completar plantillas. Combine eso con un poco de conocimiento del idioma de destino y puede hacer cosas como "decirle a emacs que desea crear una función, decirle los argumentos de entrada (tipos, si el idioma requiere información de tipo) y devolver el valor, haga que emacs cree un esqueleto para más llenando".