Emacs e "desempenho auto-reforçador"

Em resumo, minha pergunta para vocês, usuários hardcore do Emacs, é a seguinte: você conseguiu esse "desempenho auto-reforçador" sobre o qual Steve Yegge fala ?

O Emacs é auto-hospedado: escrever coisas nele torna o ambiente em si mais poderoso. É um ciclo de feedback: um efeito multiplicativo recursivo, auto-reforçador que acontece porque você está aprimorando o ambiente que está usando para criar aprimoramentos.

Você realmente acha que melhorar o seu Emacs acabou por torná-lo 10 vezes mais produtivo , e sua produtividade continua aumentando exponencialmente, e assim por diante?
Você tem alguns exemplos / experiências para compartilhar?

Quanto a mim, eu estava usando o Emacs e o Vim para desenvolvimento (atualmente o Vim), meu .emacse.vimrc ambos estão bem configurados para atender às minhas necessidades e eu aprecio o poder de ambos os editores. Mas eu não experimentei esse "loop auto-reforçador" do Emacs, nem conheci alguém que experimentou (é claro, isso pode ser porque eu não sou um Emacser realmente incondicional e ainda não conheci tantos Emacsers).

Por exemplo, no Facebook, o cara ao meu lado estava usando o Vim, e o cara ao lado dele estava usando o Emacs. Ambos foram rápidos e produtivos como o inferno, e eu atribuo isso não ao editor que eles estavam usando, mas à sua própria inteligência e atitude.

Mas de qualquer maneira, eu ficaria feliz em ver exemplos surpreendentes dos defensores do Emacs que me levariam de volta à Igreja do Emacs.

10 vezes mais produtivo ? Não é provável. Costumo pensar que os fatores multiplicativos são mais parecidos com 1.1, o que aumenta depois de um tempo.

O que Steve Yegge está falando é realmente uma reflexão sobre ser um especialista no Emacs, e esses são muito raros. As pessoas que estão conseguindo esse efeito multiplicativo estão personalizando ativamente sua experiência no Emacs, escrevendo elisp para adaptá-lo às suas necessidades específicas. Por exemplo, Yegge escreveu ejacs . A interpretação da cotação do Yegge implica estritamente que você está personalizando o Emacs para facilitar a personalização / extensão do Emacs.

Aqui está como eu detalharia os vários níveis de conhecimento conforme eles se aplicam ao Emacs:

• Um iniciante sabe como executar o Emacs, mover o cursor, fazer algumas edições, sair do Emacs.
• Um iniciante avançado sabe como colocar algumas personalizações básicas .emacsou copiou completamente pedaços de outras pessoas .emacspara os deles. Eles sabem como fazer ligações de teclas globais, requirepacotes integrados, ativar modos menores.
• Usuários competentes do Emacs têm .emacsarquivos grandes , possivelmente divididos em vários arquivos. Eles baixam e usam pacotes não-padrão, sabem como encontrar documentação para comandos, modos, visualizam as combinações de teclas existentes, se sentem confortáveis ​​com as diferenças entre modos menores e modos principais. Usuários competentes geralmente mantêm uma única instância do Emacs em execução por dias / semanas, escrevendo, compilando, executando e depurando programas de seus Emacs.
• Usuários proficientes se sentem à vontade para escrever o emacs lisp, criando seus próprios comandos interativos e se sentem à vontade para escrever modos menores. Usuários proficientes olham para o código emacs lisp para entender melhor os modos que estão usando, usam o depurador elisp e geralmente usam processos inferiores (shells, processos lisp, ...).
• Usuários experientes do Emacs escrevem novos modos principais do zero, olham e modificam o código C do Emacs, sabem o que é edição recursiva e a utilizam, usam a comunicação entre processos para integrar o Emacs a ferramentas externas. Eles também leem a lista de discussão do emacs-devel .

E como você está solicitando experiência pessoal, eis alguns exemplos do que eu pessoalmente fiz e que me parecem mais produtivo. Nota: Eu trabalho em uma empresa onde não estamos nem perto do que há de mais avançado em ambientes de desenvolvimento, por exemplo, ainda usamos o CVS.

• Integrei o Emacs com a ferramenta de rastreamento de bugs: quando faço confirmações, ele registra o nome do arquivo e a versão nos campos do bug, e no Emacs posso ver meus bugs, atribuí-los, resolvê-los etc.
• Eu escrevi uma ponte conectando meu produto (trabalho diurno) e o Emacs, efetivamente tornando meu produto um processo inferior - permitindo que eu faça alterações no código-fonte em tempo real.
• Estendi o manuseio de TAGS com o find-file-in-tags, que fornece vários atalhos adequados ao meu ambiente de desenvolvimento.
• Eu escrevi um modo que obtém resultados de regressão e me permite pular para falhas, examinar arquivos de log, executar novamente um ou mais testes ou inserir uma execução de depuração, com o mínimo de pressionamentos de tecla.
• Meu relatório semanal de status (sim, eu uso o Emacs para email) é gerado automaticamente usando os commits que fiz ao longo da semana.

Essas foram as alterações que fiz para adaptar o Emacs especificamente ao meu ambiente e meu fluxo de trabalho.

Sou 10 vezes mais produtivo do que outros ao meu redor? Não.

No entanto, para o meu trabalho diário, há muitas tarefas que posso executar com algumas teclas que outras pessoas passam muito mais tempo em seu ambiente não personalizado e que geralmente exige que elas alternem entre o editor e um navegador da Web ou um shell .

Eles são exemplos surpreendentes? Não. Tenho certeza de que muito do que fiz já está disponível no Visual Studio . Meu artigo o levará de volta à Igreja de Emacs? Provavelmente não.

No entanto, se você vê um padrão de comportamento em seu ambiente de desenvolvimento e tem essa coceira que está lhe dizendo: "Eu realmente não deveria ter que repetir X / Y / Z repetidamente, se eu pudesse ..." Eu recomendo tentar usar o Emacs para coçar essa coceira. Esse arranhão pode ser o primeiro passo nesse caminho "auto-reforçador" de que Steve Yegge está falando.

Nota secundária: eu não sei se muitos usuários do Emacs realmente especialistas estão usando ativamente os sites de estouro de pilha ou, pelo menos, não estão respondendo a perguntas relacionadas ao Emacs. Eu digo isso com base nos principais usuários das tags emacs e elisp no estouro da pilha.

Essa evidência é anedótica, é claro, mas sua pergunta exige explicitamente evidência anedótica.

Eu sou um estudante fazendo pesquisas em um laboratório acadêmico que envolve dezenas de computação científica e de escrita. Em um ambiente como esse (pense em python, SQL, utilitários acadêmicos de linha de comando para fins especiais, arquivos de texto, LaTeX / BibTeX), o emacs de aprendizado fez aproximadamente a diferença entre uma espátula manual e uma retroescavadeira. Após um ano de emacs (no qual eu me classificaria como um Competente sólido com um dedo mergulhando em Proficiente), Estou ansioso para lidar com problemas que meus colegas de laboratório temem. Não porque são preguiçosos e eu sou diligente, mas porque é divertido derrubar montanhas com uma retroescavadeira e oneroso arranhar uma montanha com uma espátula. Em pelo menos duas ocasiões, minha equipe começou a discutir sobre fazer algumas alterações complicadas no formato do relatório, apenas para descobrir que a tarefa já havia sido concluída antes que eles terminassem de discutir sobre quem precisava fazer isso. Regexp substituir + elisp incorporado.

Então, no sentido de primeira ordem, sim, o emacs me tornou muito mais produtivo.

Parece que você está perguntando sobre ganhos de produtividade no sentido de segunda ordem: meus retornos do emacs aumentam? Embora eu não me classificasse totalmente Proficiente , muito menos Yegge , acho que estou começando a ver o pé da curva exponencial, e que meu uso do emacs torna o emacs ainda mais produtivo. Algumas estatísticas breves e anedóticas do repositório para quantificar isso:

• Em uma equipe de 7, fui responsável por mais da metade dos commits. Ajustando para a antiguidade, ainda comprometo quase o dobro. Não porque eu seja quase duas vezes mais incrível, mas porque o emacs praticamente lida com o controle de versão para mim. Como posso confirmar, atualizar e mesclar sem problemas, faço check-in com pequenos blocos discretos, como todos devemos fazer. Mas isso significa que me sinto mais livre para assumir "riscos maiores" (devo mencionar que estamos escrevendo código experimental para pesquisa científica, não para produção), o que significa que eu aprendo mais sobre programação e meu assunto.

• No último relatório que escrevemos, svn blame me diz que fui responsável por mais linhas do que três vezes os outros dois autores juntos . (Isso não é apenas porque eu fiz o último commit. Fiquei curioso sobre isso por um tempo, então comecei a acompanhá-lo e os resultados eram bastante estáveis ​​ao longo do histórico da versão.) Porque eu sou seis vezes mais escritor? Não: porque o emacs é uma serra elétrica para texto. Isso significa que eu posso fazer os tipos de cirurgia LaTeX que eu nunca teria me incomodado em tentar antes. O que significa que acabo entendendo mais sobre o LaTeX, o que me torna ainda mais produtivo no futuro.

• 100% da documentação (tanto para o código quanto para notas de pesquisa interna) é minha. Porque meus colegas de laboratório não se importam com a documentação? Bem, eu realmente não me importei com isso antes de encontrar o modo organizacional. Enquanto eu normalmente sou do tipo B do tipo super-uber sobre essas coisas, o modo org transformou-se em um vício leve. A exportação instantânea do Org-mode para html e LaTeX de aparência agradável removeu todas as barreiras à documentação responsável e a transformou em uma espécie de jogo. Então agora eu faço. Se não acontecesse, eu não faria isso, ou pelo menos teria medo, adiaria e deixaria drenar a energia mental.

Outros comentaristas sugerem que a conexão causal pode ser precisamente ao contrário: talvez o emacs recompense o altamente produtivo, o que roubaria a confiança da hipótese de que o usuário mediano provavelmente desfrutará de ganhos. Eu também poderia sugerir uma espécie de efeito placebo auto-realizável: se o emacs me deixou mais produtivo (e é claro que nunca saberemos, já que não tenho um gêmeo idêntico que não aprendeu o emacs), eu tenho certamente experimentou uma epifania no meu relacionamento com o texto estruturado. Estou animado para usar o emacs, o que significa que eu o uso mais, o que significa que aprendo mais sobre ele, fico mais animado etc. Quando descobri o modo BibTeX, lembro-me de sentir como se tivesse acabado de convidar uma garota para o meu primeiro encontro.

Caso você tenha perdido isso: o emacs me deixou tonta ao pensar em editar bancos de dados bibliográficos. No meu trabalho, vale alguma coisa, eu acho.

Por exemplo, no Facebook, o cara ao meu lado estava usando o Vim, e o cara ao lado dele estava usando o Emacs. Ambos foram rápidos e produtivos como o inferno, e eu atribuo isso não ao editor que estavam usando, mas à sua própria inteligência e atitude.

Essa observação soa muito verdadeira e é um pouco aplicável a todos os tipos de dicas de produtividade.

As pessoas interessadas em aumentar / otimizar sua produtividade tendem a ser mais produtivas por causa de seu foco ou comportamento na vida, independentemente da eficiência da própria dica de produtividade.

Pode ser resumido como: "Você não é um desenvolvedor melhor porque está usando o Emacs ou o Vim, mas o tipo de pessoa que é dedicado o suficiente para dominar essas ferramentas tende a ser um bom desenvolvedor" [1].

1. Essa é uma generalização horrível, portanto, não é uma verdade absoluta e não significa muito de qualquer maneira (o que é um desenvolvedor bom / ruim? Etc)

Sou usuário do Emacs há cerca de 20 anos e tenho que dizer que não, não cheguei a esse ponto.

Para chegar ao "emacsvana" de que ele está falando, você realmente precisa se tornar um especialista em elisp . Eu fiz um pouco, mas realmente minhas habilidades terminam no nível de poder configurar um novo modo que outra pessoa escreveu. Tentar depurar (ou Deus proibir a correção) o elisp de outra pessoa está um pouco além de mim, e escrever o meu próprio a partir do zero, nem mesmo um pensamento.

Isto é de alguém que realmente usou o lisp antes e tem mais de 20 anos de experiência profissional em desenvolvimento de software.

Talvez eu esteja apenas sendo um wuus ou algo assim, mas suspeito que muito poucos usuários do Emacs chegam ao ponto de que ele está falando.

Não há nada errado com isso realmente. Eu sei como fazer macros, o que por si só me torna mais produtivo com o Emacs do que com qualquer outro editor de texto. Na ocasião, muito mais do que 10x é produtivo. No entanto, isso não me torna melhor do que alguém que conhece o vi igualmente bem (já que também pode fazer macros).

Não, não ouvi e nunca ouvi falar de alguém que tenha. Eu não acho que isso aconteça. Eu acho que Steve Yegge está fazendo o que os blogueiros populares fazem: ele está fazendo uma declaração controversa e exagerada para mostrar seu ponto de vista e ser mais visível. Eu não acho que ele quis dizer isso como tal. O que ele provavelmente pretende se comunicar é o seguinte: "O Emacs é realmente eficiente para começar, e se você o personaliza muito, aprende a ser ainda mais eficiente com ele, o que é ótimo, mmm-kay?"

Se ele tivesse acabado de dizer isso, você não ficaria confuso, e ele não teria metade do número de leitores.

Veja da seguinte maneira: o Emacs e o Vim se destacam na cirurgia de texto e na automatização de pressionamentos de tecla repetitivos, sem mencionar a navegação de grandes partes do texto. É disso que Yegge está falando, embora de um modo mais pragmático.

Se você tiver um arquivo de 10000 linhas em que deverá adicionar um número de linha ao início de cada linha, também poderá passar meio dia fazendo isso manualmente no Bloco de Notas.

Ou, inicie uma macro ou use uma função Emacs integrada para esse tipo de coisa. Você economiza meio dia de trabalho e é mais do que 10x produtivo.

É sobre detectar repetições e eliminá-las. Isso requer inteligência, experiência, prática e habilidade; portanto, nem todo mundo que usa o Emacs verá benefícios de produtividade.

Eu não sei sobre "N vezes mais rápido", mas uma adição cuidadosa de funções utilitárias pode tornar o Emacs muito bom no preenchimento de modelos. Combine isso com um pouco de conhecimento do idioma de destino e você pode fazer coisas como "diga ao emacs que você deseja que uma função seja criada, informe os argumentos de entrada (tipos, se o idioma exigir informações de tipo) e valor de retorno, faça com que o emacs crie um esqueleto para mais informações" preenchendo".