Na década de 90, quando tínhamos um problema com um software, tínhamos que entrar em contato com a empresa que havia entregado aquele binário. Fazíamos isso ou por um help-desk, e-mail (quando era chique!) ou indo até a loja que nos havia vendido uma caixinha com um CD e mostrávamos nossa nota fiscal e pedíamos um reembolso.

Daí veio o Cadê (alguém lembra?), Google e cia e ao vermos um código de erro (seja do Windows, do Linux ou de um aplicativo mesmo) usamos nosso “search-fu” e buscamos formas alternativas de contornar os problemas.

Mais um tempo depois e o open source ficou menos “underground”. Veio o git, hg e cia e muitos projetos hoje estão literalmente com o capô aberto. Erros, sugestões e até mesmo discussões sobre o futuro das funcionalidades são discutidos abertamente (veja um artigo sobre o assunto na Wired de Março de 2013 – em inglês).

Com tanta coisa aparecendo em tecnologia, muitas linguagens novas estão aparecendo. Client side? Rust, Dart, CoffeeScript, TypeScript, AtScript… Server side? Node.js, Erlang,Python, Ruby, Julia, Clojure, Scala etc.

Essa geração Github tem um bom desafio pela frente. Ao mesmo tempo que quase tudo é possível, muito provavelmente a solução passará por diversas linguagens e contextos para ser viabilizada. Quer abrir uma startup de algum serviço digital? Provavelmente terá que entender um pouco de bash, client e server side. Saber Linux sempre é bom e se conseguir customizá-lo é ótimo.

A questão é: editar programas, utilitários ou customizar o sistema operacional, tudo é feito por meio de texto. Seja no shell ou em um editor. Hoje em dia temos que ser poliglotas. Daí vamos estudar Java e precisamos lutar muito para dominar o Eclipse, IntelliJ ou NetBeans (ou JEdit, por que não?!). Essa batalha é árdua, mas digamos que saímos vitoriosos. Daí vamos editar um script de inicialização de Shell Script e o queremos fazer de dentro desses ambientes de edição. Só que ele não tem todas as ferramentas de suporte como tem para Java! Até aí tudo bem… Vou procurar um plugin que me ajude a validar sintaxe.

Para Shell devemos encontrar facilmente. Mas e se não encontrar? Tudo é texto e evolui rapidamente. Qual é o esforço para escrever um plugin para esses ambientes? Aí é uma batalha muito maior…

Por isso que Emacs e VIM (ou vi puro), as lendas dos editores de texto, estão fortes até hoje. Acredito que seja importante para um desenvolvedor conhecer pelo menos um destes editores pelo poder que eles dão nessa geração do capô aberto. Não é nenhuma via de regra. Existem novos editores aparecendo como o SublimeText, TextMate, Brackets, Atom etc. O importante é se sentir suficientemente seguro e independente de IDEs muito complexas e de difícil customização.