Las buenas herramientas son invisibles
(gingerbill.org)- Una buena herramienta es una herramienta que desaparece en el fondo mientras el usuario está inmerso en su trabajo; el objetivo de quien la crea también es hacer que no se piense en la herramienta en sí
- Si se empaquetan los defectos de una herramienta como “rompecabezas divertidos”, es fácil confundir la sensación de verse ingenioso con productividad real
- La elección de editores como vim, emacs o Sublime puede ajustarse al flujo de trabajo personal, pero si se defienden incluso sus defectos como una señal de identidad, se vuelve difícil ver honestamente sus pros y contras
- En el debate entre TUI y GUI, tampoco hay que tomar las carencias de las implementaciones actuales como limitaciones inherentes de la categoría en sí; muchos problemas existen porque no hay buenas implementaciones
- Los buenos valores predeterminados son un diseño que ahorra tiempo al usuario, y una alta capacidad de configuración o una curva de aprendizaje pronunciada solo valen la pena cuando se compensan con productividad real
Criterios de una buena herramienta
- Una buena herramienta debe ser invisible
- Cuando el usuario puede seguir trabajando sin pensar en la herramienta en sí, la herramienta desaparece en el fondo
- En el momento en que la herramienta estorba en una tarea específica, el usuario vuelve a pensar en ella
- La actitud de reempaquetar las carencias como “rompecabezas divertidos” enturbia la evaluación de una herramienta
- El placer de encontrar una solución alternativa no demuestra la calidad de la herramienta
- Disfrutar de los defectos como si fueran un pasatiempo y que la herramienta sea realmente buena son cosas distintas
El debate sobre los editores de texto
- vim es solo un ejemplo, y la misma lógica se aplica a otros editores como emacs o Sublime
- Algunos usuarios elogian el proceso de resolver las desventajas de vim como si fueran rompecabezas divertidos, más que sus ventajas
- Hay casos en los que crear una macro para una refactorización puntual de texto resultó divertido
- Si la misma tarea podía resolverse en menos de un minuto con cursores múltiples de Sublime o con un script sencillo, el trabajo con la macro queda débil como criterio de productividad real
- Los editores son importantes para el flujo de trabajo, pero es peligroso seguir casi religiosamente a un editor específico por su “onda hacker”
- Para quienes se acercan por primera vez a vim o emacs, esa atmósfera puede resultar atractiva
- La familiaridad puede ocultar defectos y hacer que uno presuma de ellos como si fueran un juego
Por qué uso Sublime y los límites que reconozco
- Sublime es el editor que he usado durante 15 años, y las razones de esa elección se pueden resumir en algunos puntos
- Sus atajos de teclado son casi un superconjunto de los entornos gráficos de sistemas operativos, por lo que el costo de cambio cognitivo al pasar entre apps es bajo
- Considero que los cursores múltiples son mejores que las macros en el 99.999% de los casos
- Los cursores múltiples ofrecen retroalimentación visual directa
- Es el editor que menos “rompecabezas” plantea en el flujo de trabajo de edición de texto
- Sublime también conserva defectos
- A veces no tiene la herramienta necesaria y hay que usar un plugin o procesar transformaciones de texto con un programa aparte
- No empaqueto esos defectos como “rompecabezas divertidos”; simplemente los acepto como incomodidades
- vim puede ser mejor para la edición básica, pero lo veo más débil para trabajos masivos que no sean del tipo grep
- No siento que los movimientos de vim sean mucho más productivos que el flujo de trabajo de Sublime
- Como casi no escribo código en la terminal, en la práctica no necesito un editor orientado a la terminal
Cuando una herramienta se vuelve identidad
- La elección de herramientas puede funcionar como una bandera que muestra qué tipo de persona eres
- La “onda hacker” puede convertirse en una señal tribal, más allá de una simple estética
- Cuando la identidad queda atada a una herramienta, reconocer sus defectos se siente como negarse a uno mismo
- Por eso uno no solo tolera los defectos, sino que termina defendiéndolos y presumiéndolos
- Es difícil tener una conversación honesta sobre herramientas con alguien para quien la herramienta se volvió parte de su personalidad
La sensación de productividad y la productividad real
- El caso de las macros de editor muestra la diferencia entre la sensación de productividad y la productividad real
- La sensación de ingenio que aparece al resolver un problema difícil se confunde fácilmente con producción real
- Una herramienta que hace que una tarea difícil se sienta heroica y que la inteligencia se sienta como logro puede parecer poderosa
- Al mismo tiempo, la velocidad real de trabajo puede ser silenciosamente lenta
- El criterio honesto no es la inmersión ni el ingenio, sino el tiempo invertido y la cantidad de errores
- Una herramienta que mucha gente recomienda casi como evangelización puede quedar rezagada bajo este criterio
- Si el objetivo es la productividad, hay que poner en duda de verdad las propias creencias y comprobar qué es más productivo
El debate entre TUI y GUI
- Para los usuarios que pasan todo el día en la terminal, las ventajas de las apps de terminal son claras
- Pero la mayoría de los programadores no pasa todo el día encerrada en la terminal
- Criticar que las apps GUI no se puedan navegar solo con teclado no significa que las GUI sean inherentemente malas
- Muchas GUI simplemente no ofrecen suficiente soporte para navegación con teclado
- No hay nada inherentemente imposible en hacer que una GUI sea navegable con teclado
- Muchos creadores de herramientas no lo implementan, o no se dan cuenta de que en muchos casos la navegación con teclado es más productiva que usar el mouse con frecuencia
- Puede ser válida la comparación de que cierta app TUI es mejor que cierta alternativa GUI
- Sin embargo, juzgar que las TUI son inherentemente mejores que las GUI se acerca al error de confundir las limitaciones de las implementaciones actuales con limitaciones esenciales
El escritorio Linux y el placer de configurar
- En 2026, todavía no llegó “el año del escritorio Linux”
- Una de las razones es que a muchos usuarios de Linux les gusta modificar el sistema tocando archivos de configuración como si fuera un rompecabezas divertido
- Aunque uno haya pasado por esa etapa, con el tiempo termina queriendo herramientas que simplemente funcionen bien
- Pasar horas o días configurando ya no es algo deseable
- Los valores predeterminados deben ser buenos y funcionar de inmediato
- Cuando se necesita un pequeño ajuste, debería terminarse en segundos
- La máxima capacidad de configuración no debería ser el objetivo de una herramienta, sino una opción para cuando realmente se necesita
- Diseñar herramientas ergonómicas consiste en ofrecer buenos valores predeterminados junto con vías de escape cuando hagan falta
Buenos valores predeterminados y responsabilidad de quienes crean herramientas
- Los buenos valores predeterminados son responsabilidad de quienes crean herramientas
- Es fácil para quienes crean herramientas trasladar al usuario la carga de configurar, ajustar y aprender
- Muchas de esas cargas son resultado de que el diseñador evitó tomar decisiones
- Una “alta capacidad de configuración” puede convertirse en una excusa para pasarle el problema al usuario sin expresar ninguna postura
- Los buenos valores predeterminados son una forma de respetar el tiempo del usuario
- Si quien crea la herramienta piensa el problema una vez, innumerables usuarios no tienen que repetir la misma reflexión
- Las vías de escape son mecanismos para una minoría real con necesidades particulares
- No deben reemplazar el trabajo de hacer bien el caso común
Una curva de aprendizaje pronunciada no es una función
- También existe la defensa de que la dificultad de una herramienta es central
- La lógica es que filtra a quienes no están comprometidos y que, una vez superado el obstáculo, la recompensa dura toda la vida
- La curva de aprendizaje es un costo, no una virtud
- Ese costo puede valer la pena, pero la recompensa debe ser productividad real
- La satisfacción de haber pagado el costo no debería ser la recompensa en sí
- La lógica de “como aprendí durante meses, esto debe tener valor y los demás también deberían seguirme” empaqueta el costo hundido como si fuera capacidad
- En ese punto, el rompecabezas ya no es el trabajo realizado con la herramienta, sino la herramienta en sí
La actitud importa más que la elección de herramienta
- No es un argumento en contra de una herramienta específica, sino una crítica a la forma de pensar sobre las herramientas
- Se puede usar vim, emacs o Sublime, cualquiera de ellos
- El criterio es si esa herramienta desaparece en el fondo y permite que el usuario siga trabajando
- Ese criterio es personal
- El problema son las historias que se adhieren alrededor de la elección de herramientas
- Se reempaquetan las limitaciones como funciones
- Se vende el esfuerzo de rodear defectos como si fuera una recompensa
- La herramienta asciende de algo que “se usa” a “parte de uno mismo”
- La señal más clara de que una herramienta está sirviendo correctamente es el estado en el que el usuario deja de notarla
- La mejor herramienta no es la que tiene la mejor historia, sino la que hace que el usuario olvide que la está usando
1 comentarios
Comentarios en Hacker News
He diseñado bastantes herramientas internas para equipos de desarrollo y estoy muy de acuerdo
Antes pensaba que, como los usuarios eran desarrolladores, era mejor dejar expuesta la “estructura interna”, pero en la práctica eso solo terminaba siendo un obstáculo para que el equipo hiciera su trabajo principal
El equipo usa las herramientas que hice para realizar lo que la empresa necesita, no quieren —ni tienen por qué querer— ponerse a juguetear con una herramienta pequeña que no van a ver en ningún otro lado
Todavía dejo muchas vías de escape, pero intento diseñar las herramientas internas para que el usuario caiga de forma natural en el pozo del éxito
Y los mensajes de error, los mensajes de error, los mensajes de error, junto con sugerencias automáticas para errores comunes, son importantes
También me decepciona que mucha gente se aferre solo a los ejemplos del texto y no vea su idea central
Si ayuda al usuario a hacer directamente algo que considera importante, la configurabilidad puede ser muy valiosa; pero si es una herramienta que simplemente le quita de encima un problema menos importante, entonces puede volverse un estorbo
Por ejemplo, me encanta cómo Gusto se encarga de la nómina, los impuestos y el envío de formularios. Casi no hay que pensarlo ni tocar nada
Pero para alguien cuyo trabajo principal es nómina, contabilidad o impuestos, o que trabaja en RR. HH., legal o finanzas en una gran empresa, esa simplificación puede ser perjudicial. Porque termina peleándose con la herramienta o, dicho de forma menos amable, porque simplifica demasiado su trabajo
También importa mucho quién es realmente el que paga, si la herramienta tiene un propósito defensivo como auditabilidad, seguridad o restricción de comportamientos no deseados, o si tiene un propósito creativo. Las funciones creativas son más atractivas, pero más difíciles de cuantificar, y los usuarios finales no necesariamente van a pagar grandes sumas por ellas, por mucho que les ayuden en su rol
Se trata de tener valores predeterminados razonables y permitir personalización cuando haga falta. Hay que empezar por el caso del 80% y dejar que quien quiera lo cambie, pero como algo opcional
Sobre todo en herramientas para desarrolladores, suele haber cierta resistencia a incorporar opiniones fuertes. Si no estás seguro de que una opción sea “siempre la correcta”, parece más seguro preguntarle al usuario, y además los desarrolladores suelen ser bastante exigentes con estas cosas
Si dices “probablemente el 95% quiera este enfoque, pero ese 5% también tiene un punto válido, así que mejor lo hago parejo para todos”, terminas con una peor herramienta para la mayoría de los usuarios
Dar soporte a la personalización es mucho más complejo de lo que parece. No es solo un tema de bugs: cada opción adicional dificulta más el pulido de la experiencia de usuario. También aumenta el alcance de las pruebas, y las abstracciones más flexibles son más difíciles de diseñar
Aun así, sigue habiendo un equilibrio que mantener: obligar a las personas a hacerlo de la manera correcta
Siempre habrá gente que se queje de quedar bloqueada por intentar hacer las cosas bien, y muchas veces lo sienten como una pérdida de tiempo
Desde la perspectiva de la organización, el objetivo es generar la curva de rendimiento más alta mientras el empleado siga ahí; desde la perspectiva del empleado, es construir la curva de rendimiento de toda su carrera
Mucho depende de la relación entre las partes involucradas. Si un mudancero hizo ejercicio el día anterior y tiene dolor muscular, desde mi punto de vista eso da un resultado más lento y peor; pero para la empresa de mudanzas puede ser bueno a largo plazo, porque se hace más fuerte y podrá hacer más trabajo. Claro, si ese mismo día renuncia o lo despiden, entonces vuelve a ser un mal resultado
La verdadera evaluación no es si es mejor usar macros o editar en Sublime, sino si el proceso mental de crear macros ayuda también en otras cosas, y qué estaba haciendo la persona antes de eso
Según mi experiencia, casi nadie que dedica tiempo a usar macros o a aprender Vim lo habría dedicado a trabajo realmente significativo. Muchas veces están aburridos o quemados, y por eso quieren pensar en otra cosa que les resulte entretenida en ese momento
El problema no es que los empleados usen scripts aleatorios, sino que no sienten urgencia ni interés por el trabajo actual
El efecto de que una interfaz se vuelva “invisible” es, en realidad, una función del tiempo pasado dentro de esa interfaz
A lo que reacciona el autor parece más bien a la fricción discrecional: cuando diseñadores o responsables de producto agregan funciones o complejidad
Pero para lograr ciertas tareas, esa fricción puede ser necesaria. Basta pensar en resolver conflictos de merge. Y si la usas el tiempo suficiente, hasta esos pasos “molestos” desaparecen al fondo
En concreto, una cabina de mando de un 737 está increíblemente saturada de controles. El avión mismo también tiene múltiples modos y bastante fricción intencional
Pero si le preguntas a un piloto que lleva más de 10 años con el 737, probablemente te dirá que esa interfaz se volvió invisible
Lo mismo pasa con Bloomberg Terminal, que suele considerarse “malo”. En medicina también, para alguien que usa software de escaneo MR más de 8 horas al día y quiere acceso inmediato a todos los controles, una interfaz llena de botones puede ser exactamente la solución correcta
Los programadores tienden a generalizar demasiado rápido su propia experiencia y sus preferencias para aplicarlas a los demás
Fuente: diseñé software para consumidores y para profesionales durante 10 años en IDEO
El texto lo aborda desde el lado del usuario, y plantea que existe un tipo de usuario que disfruta aprender funciones “extra” cuyo valor final es menor que el de las funciones centrales
La parte clave es: “si la gente usa vim, emacs, etc. porque de verdad le parecen buenos y productivos, no los criticaría. Las personas se sienten más cómodas con lo que conocen. Pero la gente de la que hablo no ve los defectos de la herramienta precisamente por esa familiaridad, y termina exhibiendo y alabando esos defectos como si fueran un juego”
Desde la perspectiva de alguien que ha usado la terminal durante mucho tiempo, no me sorprende demasiado que la gente no lo entienda. La conversación normalmente va así
“En la terminal puedes hacer todo tipo de cosas con comandos simples”
“Mi FrobnicatorStudio tiene un atajo Ctrl+Alt+So para eso”
Y así sigue indefinidamente, derivando en comparaciones casi sin sentido como “En Vim puedes borrar 24 líneas con cuatro pulsaciones” frente a “Sublime tiene cursores múltiples”
Probablemente el punto real es que la terminal cubre una cantidad infinita de casos de uso gracias a su forma de combinar pequeños comandos de línea en pipelines, pero tiene una curva de aprendizaje que tarda como un año en volverse cómoda
Una vez llegas a ese punto, puedes ser mucho más productivo que el usuario promedio de GUI, pero para llegar ahí hace falta dedicación y sufrimiento, y mucha gente termina ahí no por elección sino porque no le queda de otra
En mi caso, mi primer trabajo requería administrar servidores de clientes por ssh, y esos servidores tenían lo mínimo instalado. A menudo ni siquiera había vim, solo vi, y no había otra opción más que encontrar la manera de trabajar eficazmente en ese entorno
Si no hubiera tenido esa experiencia, no estoy seguro de que hubiera aceptado el dolor de empezar a trabajar en la terminal
Pero en algún momento sentí que estaba perdiendo demasiado tiempo ahí. Volví a la línea de comandos con tshark y jq, viejo bash/awk/grep y gnuplot, y después usé Python, pero seguí usando la salida de tshark
Al final terminé creando analizadores de pcap y pcapng, manejo de ethernet-ip-udp/tcp e incluso un IDE completo en Java, y ya no volví atrás
Recorrí el mismo camino sinuoso con todas las herramientas de captura y exploración de datos que necesitaba usar repetidamente
Dudo ser la única persona que ha pasado por estas etapas iterativas de mejora de herramientas, y ojalá hubiera una métrica con un buen nombre para describirlo
La terminal te da infinitamente más capacidades, pero en la práctica es probable que solo hagas unas 20 cosas con regularidad. Si esas 20 son todo, la curva de aprendizaje hace difícil convencer a alguien
Por ejemplo, si estás en la terminal y quieres encontrar el script de build, puedes hacer algo como
cat packages.json | jq .scriptsDentro de la terminal eso es útil, pero si ya estás en VSCode, se resuelve con
ctrl-p -> packages.json -> ctrl-f -> scr, y de hecho son menos pulsacionesEl flujo de trabajo de cada persona es muy personal, así que no le diría a nadie que cambie, pero en mi caso prefiero herramientas que entienden la estructura del proyecto antes que herramientas que solo tratan el proyecto como texto, así que un IDE me queda mejor
Las apps de línea de comandos son herramientas como grep, sort, cp, git, ls y tar, donde interactúas escribiendo comandos en el shell. Si conoces su uso general, también puedes usarlas en scripts y, por lo tanto, combinarlas en pipelines
Las apps de interfaz de usuario de texto son apps interactivas como Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander y Claude Code, que toman el control de la terminal mientras las usas
Estas no se combinan en pipelines. O, más precisamente, no se usan así en su modo habitual. Si se puede, probablemente es porque la app ofrece una interfaz de línea de comandos aparte de la TUI
Toma tiempo llegar a poder usar la misma caja de herramientas para resolver cualquier problema, pero al final es más eficiente
Aun así, es difícil convencer a la gente. Hasta que no intentas resolver un problema que cuesta mucho resolver sin herramientas de línea de comandos, no es fácil entender esa simplicidad
Aun así, sigo usando mucho la línea de comandos para todo. Normalmente dejo una ventana de konsole abierta y cuando necesito compilar o correr pruebas, en vez de usar el soporte de “build system” de Sublime hago alt+tab
Solo uso Vim cuando necesito ssh o cuando uso Termux en el teléfono
Herramientas GUI extensibles como Sublime y VSCode también cubren una cantidad infinita de casos de uso y, de hecho, ofrecen un entorno de ejecución más estable y reproducible
Creo que estas discusiones nunca terminan porque la gente suele pensar de forma cerrada. Es difícil ponerse en el lugar del otro, y más difícil todavía tomarse en serio la posibilidad de estar equivocado
Al final, este tema solo les importa a los principiantes. Cuando ya tienes suficiente experiencia, uses lo que uses, el cuello de botella de productividad deja de ser la herramienta. Aunque claro,
edpodría ser la excepciónRespecto a la afirmación de que “no saben que la navegación por teclado es mucho más productiva que estar agarrando el mouse a cada rato”, una buena parte de la gente que dice ser más productiva en realidad nunca lo ha medido
Durante años hubo muchas competencias de teclado contra mouse, y dependiendo de los detalles del diseño de la prueba a veces ganaba uno y a veces el otro, en muchos casos con diferencias bastante grandes
Antes de ver los resultados reales, no era raro que terminara perdiendo el método que los usuarios aseguraban que los hacía más productivos
No se trata de perseguir una métrica absoluta de productividad, sino de querer un entorno que no rompa el flujo
Para mucha gente, agarrar el mouse rompe el flujo y se siente torpe, y a menudo es peor que perder 1 segundo, porque te saca del contexto mental en el que estabas
En mi caso, usar el mouse al trabajar me resulta natural, así que cambiar mi flujo para hacer toda la navegación con teclado sería un esfuerzo adicional enorme solo por la posibilidad de ahorrar un poquito de tiempo en algunas situaciones
En herramientas como procesadores de texto, IDEs o administradores de archivos, donde lo central es leer, escribir, y procesar lo que leíste y escribiste, se puede demostrar que la navegación por teclado es más rápida y natural cuando el usuario ya aprendió los atajos
En cambio, en herramientas centradas en información visual no textual, el debate entre teclado y mouse se inclina mucho más hacia el mouse
Aun así, hay momentos en que atajos efectivos son muchísimo más útiles que menús e íconos. Basta ver software de CAD o modelado 3D: aunque el 90% del trabajo del usuario consiste en manejar datos espaciales representados visualmente, conocer atajos para cambiar de herramienta o modificar la configuración de una herramienta te vuelve mucho más rápido y reduce la necesidad de estar navegando menús anidados una y otra vez
Me preocupa que el autor esté confundiendo el hecho de estar familiarizado con su herramienta con evidencia de que es mejor.
En la práctica, todas las herramientas tienen trade-offs, y si un usuario prefiere la herramienta X sobre la herramienta Y, probablemente no sea porque sea tonto, sino porque aprovecha mejor las affordances de esa herramienta que solo entienden los usuarios expertos.
Si hicieras que un desarrollador use vim, emacs y Sublime Text durante 10 años cada uno, probablemente no podría afirmar con certeza cuál es mejor. Tendría preferencias personales, claro, pero también podría explicar por qué otras personas prefieren herramientas distintas.
Esto parece una discusión nacida de no haberle dado una oportunidad real a software con el que no se está familiarizado.
Creo que la marca de un veterano curtido es una vaga desconfianza hacia todo software y hacia la promesa de que ese software va a mejorar. A largo plazo, todo software converge hacia la mediocridad.
Solo dijo que no está de acuerdo con la idea de ver la fricción de una herramienta como una característica.
Podrías tomar su argumento tal cual y usarlo para mostrar que Vim es un editor perfecto para mí. Cuando uso Vim, no lo veo, y en parte eso es porque lo convertí en la herramienta que yo quería.
Él convirtió Sublime en la herramienta que quería. Aun así, el punto central se mantiene. Si estás creando algo para que lo usen otras personas, hacer que esa herramienta sea invisible para el usuario es una propiedad poderosa.
Mediocridad significa “calidad común o corriente”.
Puede que no necesites la tecnología extraordinaria más nueva y mejor para construir la siguiente app CRUD.
Si citas lo que escribí, sería esto: “Lo que me desconcierta es que mucha gente trate esa fricción —ese esfuerzo por esquivar las limitaciones de una herramienta— como la parte ‘divertida’, y la promueva como si fuera evidencia de que la herramienta es excelente.”
Esto no tiene que ver con por qué yo u otras personas elegimos cierta herramienta, sino con la actitud de tratar los defectos como algo que hay que rodear como si fuera un juego de acertijos.
Los mantenedores de buenas herramientas suelen percibirlas de forma mucho más negativa de lo que realmente las ven los usuarios.
Es difícil distinguir entre “hoy 10 personas se quejaron de un bug o de una función faltante y 9990 la usaron sin problemas” y “hoy 10 personas se quejaron y solo 90 la usaron sin problemas”. Pero el esfuerzo necesario para pasar de 90% de satisfacción de usuarios a 99.9% es enormemente distinto.
Sospecho fuertemente que este es un factor importante en mucho burnout de mantenedores de código abierto.
Los usuarios insatisfechos destacan muchísimo más que los satisfechos, y conforme crece la cantidad de usuarios nuevos, la proporción de usuarios insatisfechos que genera la misma cantidad de reportes de bugs y solicitudes de funciones va disminuyendo.
Al final, para el mantenedor se crea la ilusión de que, por mucho que mejore las cosas, la percepción global de calidad no cambia, y eso le erosiona la motivación para seguir.
No tengo claro cuál sería una buena solución para este problema. La respuesta obvia es elogiar más seguido cuando algo funciona bien, pero en la práctica se parece más a un problema de acción colectiva que casi nunca ocurre.
En lo personal, cuando algo funciona bien intento dar retroalimentación positiva de forma deliberada, frecuente y entusiasta, pero es difícil que eso haga una gran diferencia a menos que todos hagan lo mismo.
Me recordó esta cita:
“Siempre notamos a la persona encorvada, apresurada y servil, y probablemente decimos: ‘¡Qué humilde es!’. Pero la persona verdaderamente humilde no se nota. El mundo no la conoce.”
~ Tito Colliander
La parte que dice “la señal más clara de que una herramienta te sirve bien es que dejas de ser consciente de ella, es decir, se vuelve invisible. No conviertes sus defectos en un pasatiempo, así que no los glorificas; solo los esquivas con una ligera molestia” parece depender más del usuario que de la herramienta.
Claro, distintas herramientas atraerán a distintos usuarios, y seguramente se podría medir una correlación fuerte.
Además, esta postura carece de equilibrio. Las herramientas nunca son perfectas, y a veces uno se da cuenta de que pueden mejorarse, por lo que hay que sopesar implementar ese cambio frente al impacto que tendrá en los hábitos.
Cuanto más tiempo se usa una herramienta, más pequeños serán esos cambios, pero la forma de usarla evoluciona a lo largo de toda la vida, y es natural que las herramientas también cambien así.
Es una interpretación bastante peculiar.
Es raro que el autor insista en que Vim “se ve”, mientras insinúa que los cursores múltiples y las funciones de Sublime no. Que tu cerebro haya sido entrenado para dejar de pensarlo ya no hace que sea menos visible.
Los cursores múltiples no son una función básica en muchas herramientas y, si incluimos usarlos con eficacia, también son algo que hay que aprender. Igual que los atajos de teclado de Vim.
Además, Vim es más que una opción TUI para usuarios exclusivos de terminal. También son atajos de teclado que usa gente que aprendió el teclado como una extensión natural de su cuerpo para no estar yendo y viniendo con el mouse. Del mismo modo que los cursores múltiples pueden llegar a ser eso para alguien que haya usado Sublime durante 15 años.
“He visto gente hablar de lo ‘divertido’ que es crear una macro para resolver un problema puntual de refactorización de texto. Pero cuando vi lo que hacían y cuánto tardaban, mi reacción honesta fue esta: lo habría hecho en un minuto con cursores múltiples en Sublime, o simplemente habría escrito un script corto.”
Y además: “Lo que me desconcierta es que mucha gente trate esa fricción —ese esfuerzo por rodear las limitaciones de la herramienta— como la parte ‘divertida’, y la promocione como si fuera una prueba de que la herramienta es excelente.”
Está bien si puedes usar las macros de Vim de forma efectiva. Pero si no puedes hacerlo incluso después de décadas usando Vim, entonces no deberías promocionarlo como la parte “divertida”.
La postura más común es que tiene una curva de aprendizaje, pero que al final vale la pena.
No entiendo a qué se refiere. Las macros de Vim también dan retroalimentación visual directa mientras las escribes. Grabas mientras editas como siempre, y luego reproduces esa edición después.
No sé si técnicamente es posible usar macros sin ver el efecto en tiempo real sobre el texto mientras se crean, pero yo nunca lo he hecho así.
Por curiosidad busqué lo de los cursores múltiples, y parece que su ventaja es ser una sola interfaz fácil de explicar. En la práctica, yo usaría varios comandos de Vim para reemplazar eso.
Sí estoy de acuerdo en que, para la mayoría de las tareas donde usarías cursores múltiples, estos pueden ser mejores que las macros. Pero normalmente no uso macros para ese tipo de cosas.
La mayoría de las cosas que hago con macros no parece que se puedan hacer con cursores múltiples.
Si hay un ejemplo de “en esta situación los cursores múltiples son excelentes y Vim no tiene una buena alternativa”, me gustaría que me demostraran que estoy equivocado.
Eso no significa que los cursores múltiples no tengan curva de aprendizaje. Igual tienes que pensar cómo colocar los cursores en la posición correcta.
La expresión “no se ve” la usé antes para explicar emacs magit.
Es una capa delgada sobre la salida de git: aparece, infiere parámetros a partir del estado de la UI, invoca los comandos habituales de git y luego desaparece.
Es liviano y rápido. Parece que no tanto en proyectos grandes, pero bueno.