Boas ferramentas são invisíveis
(gingerbill.org)- Boas ferramentas são ferramentas que desaparecem no fundo enquanto o usuário está imerso no trabalho, e o objetivo de quem as cria também é fazer com que a ferramenta em si deixe de ser percebida
- Quando falhas da ferramenta são embaladas como um quebra-cabeça divertido, fica fácil confundir a sensação de esperteza com produtividade real
- A escolha de editores como vim, emacs e Sublime pode combinar com o fluxo de trabalho pessoal, mas se até os defeitos forem defendidos como um sinal de identidade, fica difícil enxergar com honestidade os prós e contras
- Mesmo no debate entre TUI e GUI, não se deve tratar deficiências das implementações atuais como limitações essenciais da categoria em si; muitos problemas existem por falta de uma boa implementação
- Bons padrões são um projeto que economiza o tempo do usuário, e alta possibilidade de configuração ou uma curva de aprendizado íngreme só valem a pena quando são compensadas por produtividade real
Critérios para uma boa ferramenta
- Uma boa ferramenta deve ser invisível
- A ferramenta desaparece no fundo quando o usuário consegue continuar trabalhando sem estar consciente dela
- No momento em que a ferramenta atrapalha uma tarefa específica, o usuário volta a percebê-la
- A atitude de reembalar limitações como um “quebra-cabeça divertido” distorce a avaliação da ferramenta
- O prazer de encontrar uma solução alternativa não prova a qualidade da ferramenta
- Gostar dos defeitos como hobby e a ferramenta ser realmente boa são questões separadas
O debate sobre editores de texto
- O vim é apenas um exemplo, e a mesma lógica vale para outros editores como emacs e Sublime
- Alguns usuários elogiam o processo de resolver as desvantagens do vim mais do que suas vantagens, como se fosse um quebra-cabeça divertido
- Há casos em que criar uma macro para um refatoramento textual pontual foi considerado divertido
- Se a mesma tarefa pudesse ser feita em menos de um minuto com multicursores no Sublime ou resolvida com um script simples, o trabalho com a macro perde força em termos de produtividade real
- Editores são importantes para o fluxo de trabalho, mas é perigoso tratar um editor específico de forma quase religiosa por causa de uma “vibe hacker”
- Para quem está tendo contato com vim ou emacs pela primeira vez, essa atmosfera pode parecer atraente
- A familiaridade pode esconder defeitos e fazer com que eles sejam exibidos com orgulho como se fossem um jogo
Por que usar o Sublime e quais limites reconhecer
- O Sublime é o editor usado há 15 anos, e os motivos da escolha podem ser resumidos em alguns pontos
- Os atalhos se aproximam de um superconjunto do ambiente de um sistema operacional gráfico, então o custo cognitivo de troca ao alternar entre aplicativos é baixo
- Multicursores são considerados melhores que macros em 99,999% dos casos
- Multicursores oferecem feedback visual direto
- Há o menor número de “quebra-cabeças” a resolver no fluxo de trabalho de edição de texto
- O Sublime também continua tendo falhas
- Às vezes falta uma ferramenta necessária, exigindo plugin ou um programa separado para fazer transformações no texto
- Esses defeitos não são embalados como um “quebra-cabeça divertido”, mas aceitos simplesmente como inconveniências
- O vim pode ser melhor para edição básica, mas é visto como mais fraco em trabalho em massa que não seja do tipo grep
- Não se sente que os movimentos do vim sejam muito mais produtivos do que o fluxo de trabalho no Sublime
- Como quase não se escreve código no terminal, um editor orientado ao terminal na prática não é necessário
Quando a ferramenta vira identidade
- A escolha de uma ferramenta pode funcionar como uma bandeira que mostra que tipo de pessoa alguém é
- A “vibe hacker” pode ir além de uma estética simples e se tornar um sinal tribal
- Quando a identidade fica amarrada à ferramenta, reconhecer defeitos passa a parecer uma negação de si mesmo
- Por isso, a pessoa não apenas tolera os defeitos, mas os defende e se orgulha deles
- É difícil ter uma conversa honesta sobre ferramentas com alguém para quem a ferramenta virou parte da personalidade
Sensação de produtividade e produtividade real
- O caso das macros em editores mostra a diferença entre a sensação de produtividade e a produtividade real
- A sensação de esperteza que surge ao resolver um problema complicado é fácil de confundir com resultado real
- Ferramentas que fazem tarefas difíceis parecerem heroicas e transformam esperteza em sensação de conquista podem parecer poderosas
- Ao mesmo tempo, a velocidade real do trabalho pode estar silenciosamente mais lenta
- O critério honesto não é imersão nem esperteza, mas o tempo gasto e o número de erros
- Muitas ferramentas recomendadas quase como evangelização podem perder nesse critério
- Se o objetivo é produtividade, é preciso realmente duvidar das próprias crenças e verificar o que é mais produtivo
O debate entre TUI e GUI
- Para quem passa o dia inteiro no terminal, as vantagens de aplicativos de terminal são claras
- Mas a maioria dos programadores não fica presa ao terminal o dia todo
- A crítica de que aplicativos GUI não podem ser navegados só com o teclado não significa que a GUI seja essencialmente ruim
- Muitas GUIs apenas não oferecem suporte suficiente à navegação por teclado
- Não há nada intrinsecamente impossível em tornar uma GUI navegável por teclado
- Muitos criadores de ferramentas não implementam isso ou não percebem que, em muitos casos, a navegação por teclado é mais produtiva do que usar o mouse com frequência
- Comparar um TUI específico com uma alternativa GUI específica pode ser válido
- Mas concluir que TUI é essencialmente melhor do que GUI é quase um erro de confundir os limites das implementações atuais com limites essenciais
Desktop Linux e o prazer da configuração
- Mesmo em 2026, “o ano do desktop Linux” não chegou
- Um dos motivos é que muitos usuários de Linux gostam de mexer em arquivos de configuração e alterar o sistema como se isso fosse um quebra-cabeça divertido
- Mesmo que alguém tenha passado por essas etapas, com o tempo passa a querer ferramentas que simplesmente funcionem bem
- Gastar horas ou dias configurando já não é mais algo desejável
- Os padrões devem ser bons e funcionar imediatamente
- Quando um pequeno ajuste for necessário, ele deve levar apenas alguns segundos
- A máxima configurabilidade não deve ser o objetivo da ferramenta, mas uma opção para quando ela realmente for necessária
- Um projeto ergonômico de ferramenta é aquele que oferece bons padrões e uma rota de escape quando preciso
Bons padrões e a responsabilidade de quem cria ferramentas
- Bons padrões são responsabilidade de quem cria ferramentas
- Quem cria ferramentas tende a repassar ao usuário o peso de configurar, ajustar e aprender
- Grande parte desse peso é resultado de o designer evitar decisões
- “Alta configurabilidade” pode virar uma desculpa para empurrar o problema ao usuário sem oferecer nenhuma opinião
- Bons padrões são um respeito ao tempo do usuário
- Se quem cria a ferramenta pensar uma vez, inúmeros usuários não precisam repetir a mesma reflexão
- A rota de escape existe para a minoria real com necessidades incomuns
- Ela não deve substituir o trabalho de acertar o caso comum
Curva de aprendizado íngreme não é funcionalidade
- Também existe a defesa de que a dificuldade de certas ferramentas é parte essencial delas
- A lógica é filtrar quem não tem comprometimento e recompensar para sempre quem supera a barreira
- A curva de aprendizado é um custo, não uma virtude
- Esse custo pode valer a pena, mas a recompensa precisa ser produtividade real
- A simples satisfação de ter pago esse custo não deve virar a recompensa
- A lógica de “aprendi por alguns meses, então isso precisa valer a pena e os outros também deveriam seguir o mesmo caminho” disfarça custo afundado como se fosse competência
- Nesse momento, o quebra-cabeça deixa de ser o trabalho feito com a ferramenta e passa a ser a própria ferramenta
A atitude é mais importante que a escolha da ferramenta
- Não se trata de um argumento contra uma ferramenta específica, mas de uma crítica ao modo de pensar sobre ferramentas
- Pode-se usar vim, emacs ou Sublime
- O critério é se a ferramenta desaparece no fundo e permite que a pessoa continue trabalhando
- Esse critério é pessoal
- O problema está nas narrativas que se acumulam em torno da escolha da ferramenta
- Reembalam limitações como se fossem funcionalidades
- Vendem o esforço de contornar defeitos como se fosse recompensa
- A ferramenta deixa de ser algo que se “usa” e é elevada a “parte de si”
- O sinal mais claro de que uma ferramenta está servindo corretamente é o estado em que o usuário deixa de percebê-la
- A melhor ferramenta não é a que tem a melhor história, mas a que faz o usuário esquecer que está usando uma ferramenta
1 comentários
Comentários do Hacker News
Depois de projetar muitas ferramentas internas para equipes de desenvolvimento, concordo muito com isso
Antes eu achava que, como os usuários eram desenvolvedores, era melhor deixar a “estrutura interna” mais exposta, mas na prática isso só criava obstáculos para o trabalho principal da equipe
As pessoas usam a ferramenta que eu fiz para realizar o que a empresa precisa, não porque queiram ficar mexendo numa ferramenta pequena que nunca verão em outro lugar, nem porque tenham qualquer motivo para isso
Ainda deixo várias rotas de escape, mas tento projetar ferramentas internas para que o usuário caia naturalmente no poço do sucesso
E mensagens de erro, mensagens de erro, mensagens de erro, além de sugestões automáticas para erros comuns, são importantes
Também é frustrante ver tanta gente se prender apenas aos exemplos do texto e não ao ponto principal
Se ela ajuda diretamente o usuário a fazer algo que ele considera importante, a configurabilidade pode ser muito valiosa; mas, se a ferramenta só remove um problema que ele considera menos importante, isso pode acabar mais atrapalhando do que ajudando
Por exemplo, é excelente a forma como a Gusto cuida de folha de pagamento, impostos e envio de formulários. Quase não é preciso pensar nem mexer em nada
Mas, para quem trabalha justamente com folha, contabilidade ou tributos, ou está em departamentos de RH, jurídico ou finanças de grandes empresas, esse tipo de simplificação pode ser ruim. Porque a pessoa acaba tendo que brigar com a ferramenta ou, dito de forma menos gentil, porque ela simplifica demais o trabalho dela
Também pesa muito quem é a pessoa que realmente paga, se a ferramenta tem objetivos defensivos como auditabilidade, segurança e restrição de comportamentos indesejados, ou se tem um objetivo criativo. Funcionalidades criativas são mais atraentes, mas mais difíceis de quantificar, e o usuário final não tende a pagar tanto dinheiro por elas, por mais que ajudem no seu papel
A ideia é ter padrões sensatos e permitir personalização quando necessário. Deve começar pelo caso de 80% e deixar a pessoa mudar se quiser, como algo opcional
Especialmente em ferramentas para desenvolvedores, há uma tendência de hesitar em embutir opiniões fortes. Se não há certeza de que uma escolha é “sempre correta”, parece mais seguro perguntar ao usuário, até porque desenvolvedores costumam ser bem exigentes
Mas, quando se pensa “95% provavelmente vão querer assim, mas os 5% também têm um ponto válido, então vou equilibrar para todo mundo”, o resultado é uma ferramenta pior para a maioria dos usuários
Dar suporte à personalização é muito mais complexo do que parece. Não é só uma questão de bugs: cada opção adicional dificulta o refinamento da experiência do usuário. O escopo de testes aumenta, e abstrações mais flexíveis também são mais difíceis de projetar
Ainda assim, continua existindo um ponto de equilíbrio a buscar: forçar as pessoas a seguir a forma correta
Sempre há quem reclame por ficar travado ao fazer as coisas direito, e muitas vezes essas pessoas sentem que isso é perda de tempo
Do ponto de vista da organização, o objetivo é criar a maior curva de desempenho enquanto o funcionário está lá; do ponto de vista do funcionário, é construir a curva de desempenho da carreira inteira
Muita coisa depende da relação entre as pessoas envolvidas. Se um carregador de mudança treinou no dia anterior e está dolorido, para mim o resultado é mais lento e pior, mas para a empresa de mudanças isso pode ser bom no longo prazo, porque ele ficará mais forte e conseguirá fazer mais trabalho. Só que, se ele pedir demissão ou for demitido naquele dia, aí volta a ser um resultado ruim
A verdadeira avaliação não é se macros ou editar no Sublime é melhor, e sim se o processo mental de criar macros ajuda em outras tarefas, e também o que a pessoa estava fazendo antes disso
Pela minha experiência, quase ninguém que gasta tempo usando macros ou aprendendo Vim usaria esse tempo em trabalho realmente significativo. Em geral, a pessoa está entediada ou esgotada e quer pensar em outra coisa que pareça divertida naquele momento
O problema não é que os funcionários usem scripts aleatórios, e sim que falta senso de urgência ou interesse no trabalho atual
O efeito de uma interface se tornar “invisível” é, na prática, uma função do tempo passado dentro dela
O que o autor parece estar criticando é algo mais próximo de atrito discricionário, isto é, quando designers ou gerentes de produto adicionam funcionalidades ou complexidade
Mas, para realizar certas tarefas, esse atrito pode ser necessário. Basta pensar em resolver conflitos de merge. E, com tempo suficiente de uso, até essas etapas “incômodas” desaparecem para o fundo
Especificamente, a cabine de um 737 é extremamente densa em controles. O próprio avião tem vários modos, e há bastante atrito intencional
Mas, se você perguntar a um piloto que trabalha com o 737 há mais de 10 anos, ele dirá que a interface se tornou invisível
O mesmo vale para o Bloomberg Terminal, que costuma ser visto como “ruim”. Na área médica também, para alguém que passa mais de 8 horas por dia usando software de ressonância magnética e quer acesso imediato a todos os controles, uma interface cheia de botões pode ser exatamente a solução certa
Programadores tendem a generalizar rápido demais a partir da própria experiência e preferência, aplicando isso aos outros
Fonte: projetei software para consumidores e para profissionais na IDEO por 10 anos
O texto trata disso do lado do usuário e considera que existe um tipo de usuário que gosta de aprender funcionalidades “extras”, cujo valor final é menor que o das funções centrais
A parte essencial é: “Se as pessoas usam vim, emacs etc. porque realmente os acham bons e produtivos, eu não vou criticá-las. As pessoas se sentem mais confortáveis com aquilo a que estão acostumadas. Mas as pessoas de quem estou falando são aquelas que, por causa dessa familiaridade, deixam de enxergar os defeitos da ferramenta e passam a exaltar esses defeitos e elogiá-los como se fosse um jogo”
Como alguém que usa terminal há muito tempo, não me surpreende muito que as pessoas não entendam. A conversa geralmente segue assim
“No terminal você pode fazer isso e aquilo com um comando simples”
“No meu FrobnicatorStudio existe um atalho Ctrl+Alt+So para isso”
E vai seguindo sem fim desse jeito, descambando para comparações quase sem sentido como “No Vim você pode apagar 24 linhas apertando quatro vezes” e “O Sublime tem múltiplos cursores”
O ponto de fato provavelmente é que o terminal cobre uma quantidade infinita de casos de uso graças à forma como combina pequenos utilitários de linha de comando em pipelines, mas tem uma curva de aprendizado que leva mais ou menos um ano até ficar confortável
Quando você chega nesse ponto, pode ser muito mais produtivo do que um usuário médio de GUI, mas chegar lá exige dedicação e sofrimento, e muita gente faz isso não por escolha, mas porque é obrigada
No meu caso, meu primeiro emprego exigia administrar servidores de clientes via ssh, e esses servidores tinham só o mínimo instalado. Muitas vezes nem havia vim, só vi, e não havia outra opção além de descobrir como trabalhar de forma eficaz naquele ambiente
Se eu não tivesse passado por essa experiência, não tenho certeza de que teria aceitado a dor de começar a trabalhar no terminal
Mas em algum momento senti que estava desperdiçando tempo demais ali. Voltei para a linha de comando com tshark e jq, velho bash/awk/grep e gnuplot, e depois passei a usar Python, mas ainda usando a saída do tshark
No fim, acabei criando parsers de pcap e pcapng, tratamento de ethernet-ip-udp/tcp e até uma IDE Java completa, e nunca mais voltei
Segui esse mesmo caminho tortuoso com todas as ferramentas de captura e exploração de dados que precisei usar repetidamente
Imagino que eu não seja a única pessoa a passar por esses estágios iterativos de melhoria de ferramentas, e seria bom se existisse uma escala com um nome bem escolhido para descrever isso
O terminal oferece infinitamente mais capacidade, mas é bem provável que, na prática, você faça regularmente só umas 20 coisas. Se essas 20 coisas forem tudo, fica difícil convencer por causa da curva de aprendizado
Por exemplo, se você está no terminal e quer encontrar um script de build, pode fazer algo como
cat packages.json | jq .scriptsDentro do terminal isso é útil, mas se você já está no VSCode, acaba em
ctrl-p -> packages.json -> ctrl-f -> scr, e na prática isso envolve até menos teclasO fluxo de trabalho das pessoas é realmente muito pessoal, então eu não diria para ninguém mudar, mas no meu caso a IDE combina mais comigo porque prefiro ferramentas que entendem a estrutura do projeto a ferramentas que tratam o projeto apenas como texto
Apps de linha de comando são ferramentas com as quais você interage digitando comandos no shell, como grep, sort, cp, git, ls e tar. Se você conhece o modo normal de uso, também pode usá-las em scripts e, portanto, combiná-las em pipelines
Apps com interface textual são apps interativos que tomam conta do terminal enquanto você os usa, como Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander e Claude Code
Esses não são combinados em pipelines. Mais exatamente, não do jeito como normalmente são usados. Se isso for possível, provavelmente é porque o app oferece uma interface de linha de comando separada da TUI
Leva tempo até você conseguir usar a mesma caixa de ferramentas para resolver todo tipo de problema, mas no fim isso é mais eficiente
Só que é difícil convencer as pessoas disso. Até resolver um problema que seria difícil de solucionar sem ferramentas de linha de comando, não é fácil entender essa simplicidade
Mesmo assim, continuo usando bastante a linha de comando em tudo. Normalmente deixo uma janela do konsole aberta e, quando preciso compilar ou testar, dou alt+tab para ela em vez de usar o suporte a “build system” do Sublime
Só uso Vim quando preciso de ssh ou quando uso o Termux no celular
Ferramentas de GUI extensíveis como Sublime, VSCode e outras também cobrem uma quantidade infinita de casos de uso, e ainda por cima oferecem um ambiente de execução mais estável e reproduzível
Acho que esse debate nunca acaba porque as pessoas tendem a ter uma mentalidade fechada. É difícil se colocar no lugar dos outros, e mais difícil ainda levar a sério a possibilidade de estar errado
No fim, essa questão só importa para iniciantes. Quando você já está suficientemente acostumado, qualquer que seja a ferramenta, o gargalo de produtividade deixa de ser a ferramenta. Claro, talvez haja uma exceção para o ed
Sobre a afirmação de que “não sabem que a navegação por teclado é muito mais produtiva do que ficar pegando o mouse o tempo todo”, uma parte considerável das pessoas que dizem ser mais produtivas na verdade nunca mediu isso de fato
Houve muita competição entre navegação por teclado versus mouse ao longo dos anos e, dependendo dos detalhes do desenho do teste, ora um lado ganhava, ora o outro, e em muitos casos a diferença era bem grande
Antes de ver os resultados reais, não era raro que o método que os usuários diziam ser mais produtivo acabasse perdendo
O objetivo não é perseguir uma métrica absoluta de produtividade, e sim ter um ambiente que não quebre o fluxo
Para muita gente, pegar o mouse quebra o fluxo e parece algo estranho, e isso muitas vezes é pior do que perder 1 segundo, porque tira você do contexto mental em que estava
No meu caso, usar o mouse enquanto trabalho é natural, então mudar meu fluxo para fazer toda a navegação pelo teclado significaria um esforço adicional enorme só pela possibilidade de economizar um pouquinho de tempo em algumas situações
Em ferramentas como processadores de texto, IDEs e gerenciadores de arquivos, nas quais o foco está em ler, digitar, ler e processar o que foi digitado, dá para demonstrar que a navegação por teclado é mais rápida e natural quando o usuário aprendeu os atalhos
Por outro lado, em ferramentas centradas em informação visual não textual, o debate teclado versus mouse pende muito mais para o lado do mouse
Ainda assim, há momentos em que atalhos eficazes são muito mais úteis do que menus e ícones. Basta olhar para softwares de CAD ou modelagem 3D: 90% do trabalho do usuário envolve lidar com dados espaciais exibidos visualmente, mas conhecer atalhos para trocar de ferramenta ou ajustar configurações de ferramentas deixa tudo muito mais rápido e reduz a necessidade de ficar cavando menus aninhados o tempo todo
Fico preocupado que o autor esteja confundindo familiaridade com a própria ferramenta com evidência de que ela é melhor.
Na prática, toda ferramenta tem trade-offs, e se um usuário prefere a ferramenta X à ferramenta Y, provavelmente não é por ser burro, mas porque consegue aproveitar melhor as affordances daquela ferramenta, que muitas vezes só usuários experientes entendem.
Se você fizer um desenvolvedor usar vim, emacs e Sublime Text por 10 anos cada, eu não teria certeza de qual é melhor. Ele pode ter uma preferência pessoal, mas também conseguiria explicar por que outras pessoas preferem ferramentas diferentes.
Isso parece uma discussão de quem nunca deu uma chance real a um software com o qual não estava familiarizado.
Acho que a marca de um veterano calejado é uma desconfiança difusa em relação a todo software e às promessas de melhorá-lo. No longo prazo, todo software converge para a mediocridade.
Só disse que não concordo com a ideia de tratar o atrito da ferramenta como uma funcionalidade.
Dá até para pegar o argumento dele e usá-lo para mostrar que o Vim é o editor perfeito para mim. Quando uso Vim, ele desaparece para mim, e em certa medida isso acontece porque eu o transformei na ferramenta que eu queria.
Ele transformou o Sublime na ferramenta que queria. Ainda assim, o ponto central continua. Se você está criando algo para outra pessoa usar, fazer essa ferramenta ficar invisível para o usuário é uma propriedade poderosa.
Ser medíocre significa ter “qualidade comum ou normal”.
Ao criar o próximo app CRUD, talvez você não precise da tecnologia extraordinária mais nova e melhor.
Se eu citar o que escrevi, foi isto: “O que me deixa perplexo é que muita gente trata esse atrito — o esforço para contornar as limitações da ferramenta — como a parte ‘divertida’, e o promove como se fosse prova de que a ferramenta é excelente.”
Isso não tem a ver com por que eu ou outra pessoa escolhe determinada ferramenta, e sim com a atitude de tratar defeitos como algo a ser contornado como se fosse um puzzle game.
Mantenedores de boas ferramentas muitas vezes recebem a experiência dos usuários de forma muito mais negativa do que os usuários realmente a vivenciam.
É difícil distinguir entre “hoje 10 pessoas reclamaram de bugs ou funcionalidades ausentes, e 9.990 usaram sem problemas” e “hoje 10 pessoas reclamaram, e só 90 usaram sem problemas”. Mas o esforço necessário para sair de 90% para 99,9% de satisfação do usuário é enormemente diferente.
Suspeito fortemente que isso seja um grande fator no burnout de mantenedores de open source.
Usuários insatisfeitos se destacam muito mais do que os satisfeitos, e, em relação ao ritmo de crescimento de novos usuários, a proporção de usuários insatisfeitos que gera a mesma quantidade de relatórios de bugs e pedidos de funcionalidades vai diminuindo.
No fim, isso cria para o mantenedor a ilusão de que, por mais que ele melhore as coisas, a percepção geral de qualidade não muda, e a motivação para continuar se desgasta.
Não sei qual seria uma boa solução para isso. A resposta óbvia seria elogiar com mais frequência quando algo funciona bem, mas na prática isso parece mais um problema de ação coletiva, algo que simplesmente não acontece muito.
Pessoalmente, quando algo funciona bem, tento de propósito dar feedback positivo com frequência e entusiasmo, mas é difícil fazer grande diferença a menos que todo mundo faça o mesmo.
Essa citação me veio à mente.
“Sempre notamos a pessoa curvada, agitada e servil, e provavelmente diremos: ‘Como ela é humilde!’ Mas a pessoa verdadeiramente humilde passa despercebida. O mundo não a conhece.”
~ Tito Colliander
A parte “o sinal mais claro de que uma ferramenta o serve bem é que você deixa de percebê-la, ou seja, ela se torna invisível. Você não transforma seus defeitos em hobby, então não os celebra; apenas os contorna com um pouco de irritação” parece depender mais do usuário do que da ferramenta.
Claro, ferramentas diferentes vão atrair usuários diferentes, e talvez até fosse possível medir uma correlação forte.
Além disso, essa posição carece de equilíbrio. Ferramentas nunca são perfeitas, e às vezes você percebe que poderiam melhorar; então é preciso ponderar entre implementar essa mudança e o impacto que ela terá sobre os hábitos.
Quanto mais tempo você usa uma ferramenta, menores tendem a ser essas mudanças, mas a forma de usá-la evolui ao longo da vida, e é natural que a ferramenta também mude assim.
É uma interpretação bem peculiar
É estranho que o autor pareça obcecado com a ideia de que o Vim é “visível”, enquanto insinua que o multi-cursor e os recursos do Sublime não são. O fato de alguém ter treinado a cabeça para não precisar mais pensar nisso não torna a ferramenta menos visível
Multi-cursor não é um recurso básico em muitas ferramentas e, se incluir usá-lo de forma eficaz, também é algo que precisa ser aprendido. Assim como os atalhos de teclado do Vim
Além disso, o Vim é mais do que uma opção de TUI para usuários exclusivos de terminal. Ele também é um conjunto de atalhos de teclado usado por pessoas que aprenderam o teclado como uma extensão natural do próprio corpo e não querem ficar indo e voltando para o mouse. Do mesmo jeito que o multi-cursor pode representar isso para alguém que usa o Sublime há 15 anos
“Vi gente falando de como é ‘divertido’ criar uma macro para resolver um problema pontual de refatoração de texto. Mas, quando vi o que estavam fazendo e quanto tempo levava, minha reação sincera foi esta: eu teria feito em 1 minuto com multi-cursor no Sublime, ou simplesmente escrito um script curto.”
E também: “O que me desconcerta é que muita gente trate esse atrito — esse esforço para contornar as limitações da ferramenta — como a parte ‘divertida’, e promova isso como se fosse prova de que a ferramenta é excelente.”
Se você consegue usar macros do Vim com eficiência, ótimo. Mas, se mesmo depois de décadas usando Vim você não consegue, então não deveria promover isso como a parte “divertida”
O sentimento mais comum é que existe uma curva de aprendizado, mas que no fim vale a pena
Não entendi o que isso quer dizer. Macros do Vim também dão feedback visual direto enquanto você as grava. Você edita normalmente durante a gravação e depois reproduz essas edições
Talvez seja tecnicamente possível usar macros sem ver o efeito em tempo real no texto enquanto as cria, mas eu nunca fiz isso
Fiquei curioso e fui pesquisar multi-cursor, e a vantagem parece ser uma interface única e fácil de explicar. Na prática, eu usaria vários comandos do Vim para substituir isso
Concordo que, para a maior parte das tarefas em que vale a pena usar multi-cursor, ele pode ser melhor do que macros. Mas normalmente eu não usaria macros para esse tipo de tarefa
A maior parte do que faço com macros não parece poder ser feita com multi-cursor
Se houver um exemplo de “nesta situação o multi-cursor é excelente e o Vim não tem uma boa alternativa”, eu gostaria de ser convencido do contrário
Isso não significa que multi-cursor não tenha curva de aprendizado. Você ainda precisa pensar em como posicionar os cursores nos lugares certos
Já usei essa expressão, “não aparece”, antes ao descrever o emacs magit
É uma camada fina em cima da saída do git: aparece, infere os parâmetros a partir do estado da UI, chama o comando git de sempre e depois desaparece
Leve e rápido. Parece que não funciona assim em projetos grandes, mas enfim