Metapost #2: Editores de Texto

TL;DR Evolução de ‘editores’ de texto no meu contexto e uma pequena reflexão sobre o futuro disso.

Esse post é destinado a quem quiser ler a história de um programador desajeitado e sua (possível) evolução (dependendo do seu ponto de vista); alternativamente, acho que ele é recomendado para quem está iniciando nesse mundo da computação. Bom, eu gosto de ler esse tipo de história, mas hoje eu estou escrevendo =P

Post claramente motivado pelo lançamento do Atom, pelo Github. Perfeitos, como (quase) sempre, open source — o modelo de negócios do Github é um dos mais elegantes que eu já vi, mas deixa isso para outra hora.

Parte 1 – Eu

  • 2007 – Microsoft Word 2003 no Windows XP. Meu “editor” de texto favorito (quem disse que conhecemos alternativas? Linux? Oi? O que é isso? Open Office? Que droga é essa? — na época ainda nem era Libre Office. Liberdade é uma coisa muito positiva. Seja liberdade de software, de operadora de telefonia (lembra da época escura quando você só podia ficar em uma única operadora? Chips bloqueados, e tudo o mais), liberdade de sistema operacional, liberdade de sistema operacional móvel, liberdade de consoles, liberdade para poder fazer manifestações, LIBERDADE!!!)
  • 2008 – Quando tive contato com HTML pela primeira vez, o notepad do Windows foi meu primeiro amiguinho (ser autodidata = navegar no escuro. Quem sabe eu não teria bem mais experiência com isso hoje se alguém tivesse me orientado ou recomendado alguma coisa. Por sinal, o modo como eu resolvi “vou aprender HTML” foi suuuuuuuuuper por acaso, foi uma pessoa que me recomendou fazer isso, num MMORPG! Viu, dizem que esses joguinhos são inúteis, mas foi graças a isso que eu fui mais direcionado ainda para esse mundo da tecnologia / de software)
  • 2008.2/2009.1 – Tendo um contato ligeiro com CSS e mais ligeiro ainda com XML, e ainda não tendo decidido seguir carreira em nada de computação, conheci o Macromedia (na época, ele ainda não tinha sido incorporado à Adobe) Dreamweaver 8 (essa edição foi a última antes das CSx – ‘creative suite’). Na época, criei um site para a minha turma do ensino médio, com o objetivo de centralizar todos os materiais (= slides, apostilas, listas de exercício, textos, etc) lá. Ah, foi uma experiência muito positiva, e não conheci mais ninguém que tentou fazer isso naquela época. Depois, ele ficou outdated, principalmente por causa das comunidades do orkut, e também pelo fato de que criamos um e-mail para a turma. Mas, foi a minha primeira experiência com isso.
  • 2009.2 – Provavelmente aqui eu tive o meu primeiro contato com o Notepad++. Para aprender…C! Tudo por conta própria também, claro. Eu fazia curso técnico de eletrônica, e não de informática (why God, why?), então tive que me virar. Essa foi uma época legal, tentando obter suporte por apostilas e por comunidades do Orkut, definitivamente foi algo bem único. Ah, é claro que eu programava no Windows naquela época. Isso dificultou algumas coisas…erro clássico: mandar executar o programa, e ele fechar automaticamente, sem você poder visualizar o resultado por lá. Só dava certo se você colocasse system("PAUSE") ou getch(); (ah, nada disso padrão…shame on lack of ANSI). Claro, a outra opção seria executá-lo pelo CMD, mas você sabe o que é apresentar uma tela preta para um usuário acostumado com GUIs?
  • 2009.2/2010.1 – Falei que tive contato com o Notepad++, mas isso não significa que eu programei lá. Você acha mesmo que um newbie iria programar num editor de texto puro, compilando com gcc? Foi por aí que conheci o Dev-C++ (versão 4.9.9.2, inesquecível, descontinuada…ah, sabe o que é pior? As pessoas insistiam em usá-la. Em todos os computadores da Eletrônica. Até mesmo nos da Informática. Colabora, né, coordenação.). Utilizei ele durante 1 ano, pelo menos.
  • 2011 – Aqui, em algum momento, tive contato com o Code::Blocks. Ah, perfeito! Uma das melhores IDEs para newbies que já conheci. Claro, para C/C++.
  • 2011.1 – Aqui, em algum momento, fiz a prova da OBI, pela primeira vez. Fiz super por acaso, decidi isso no dia, e fui avisado pelo Rodrigo (obrigado, cara! :D). Nunca treinei uma única gota de água para isso. Foi uma experiência legal no sentido de aprender a ter mais contato com os tipos de problema da OBI, e também para me familiarizar mais com C e com o Code::Blocks. Esse era o meu terceiro ano do ensino médio. Infelizmente, comecei bastante tarde na OBI. Acho que eu tinha potencial de ganhar alguma medalha se eu começasse desde cedo. Novamente, é uma pena não ter tido esse incentivo na Eletrônica no CEFET, e nem ninguém (essencialmente) ao meu redor se interessar por essas coisas. As pessoas no ensino médio são, em geral, bastante esquisitas. Hoje eu vejo algumas pessoas começarem desde cedo, e elas se sentem super super (ah, ya know) por isso. A busca pela atenção e pela fama de algumas delas é algo realmente lamentável (com um tom de patético, também). Bragging, sabe? Ah, esse é um assunto super recorrente em ambientes competitivos. Deixa esse assunto para outra hora.
  • 2011 – again – Fiz um trabalho de português todo no Notepad++ (leia: em .txt). Hippie Hippie yuppi. OBS.: a professora disse que gostou, que se lembrou dos tempos de infância dela (máquinas de escrever…Liana, estou falando de você!)(Estava bem formatado, na verdade essa foi uma das graças do trabalho: formatá-lo!). Foi engraçado, todo mundo fazendo no Word e afins, isso mostra que desde cedo eu sempre procurei fazer as coisas “thinking outside the box”, diferentemente das outras pessoas. Fui aprender depois que essa é uma ótima virtude para alguém da computação (novamente, depende do seu ponto de vista).
  • 2012 – Here the action begins! [vou ser breve a partir daqui, senão o post ficará enorme] –> meu primeiro contato com Linux (Ubuntu! Já escrevi um post sobre isso, com a Maratona de Programação, e com pessoas realmente boas e decentes (note: pessoas boas são fáceis de ser encontradas; pessoas decentes também; já uma combinação das duas é bastante difícil! — isso dependerá também da sua interpretação de ‘boa’ e de ‘decente’) — ou: obrigado à galera da Maratona de Programação da UFRJ de 2012! Sorry, tenho que fixar a data, não sei se aparecerão babacas no futuro.
  • 2012.1 – Kate @ KDE @ Gentoo Linux w/ gcc w/ bash. Meu primeiro ambiente de programação no Linux.
  • 2012.1 (later) – gedit com Ubuntu.
  • 2012.2 – indecisão entre Code::Blocks, gedit e Kate. Optei pelo Kate.
  • 2012.2 (quase no final) – notei que aprender ou vim ou emacs seria algo útil. Escolhi o emacs. Adivinha por que…a maioria das pessoas já usava vim, logo, preferi conhecer algo que menos pessoas conheciam. É claro que isso foi um risco, mas eu sabia que o emacs era (ainda) bastante utilizado, suportado, desenvolvido, etc. Portanto eu sei que encontraria bastantes livros, tutoriais, posts de blog, configurações, etc. Arrisquei. Não me arrependo de não ter escolhido o vim, nem um pouco. Graças ao Emacs, tive mais contato com linguagens funcionais, e essa é uma área maravilhosa da computação. Sem contar que ele é muito mais extensível e customizável do que o Vim — isso não significa que eu tentaria criar os meus próprios modos e customizações, mas que seria fácil encontrar vários deles. E é mesmo, inclusive o Emacs 24 tem um repositório e package manager justamente para baixar e gerenciar extensões. O vim tem isso? (…). Brincadeira. Cada editor tem as suas vantagens e desvantagens, eu não estou aqui para falar mal do que eu não uso, e sim para falar bem do que eu uso.
  • 2012.2/2013.{1,2} – a minha curva de aprendizado com o Emacs foi bastante grande. Isso porque eu não me dediquei completamente a isso (propositalmente), preferi aprendê-lo aos poucos. Tinham várias coisas para aprender: keybindings (teclas de atalho), terminologia, modos, configurações/tweaking, etc. Nesse meio tempo, tive contato com IDEs grandes. Eclipse para Java, Eclipse(-CDT) para C++, Netbeans para C++, Eclipse para Android. Fui percebendo o equilíbrio entre utilizar uma IDE e um editor de textos. Conclusão: muitos programadores ruins são, erroneamente, primeiramente apresentados para uma IDE. Isso é péssimo. Deveriam aprender primeiro os fundamentos, a editar texto e a compilar na mão, e só depois se moverem para uma IDE, onde ela se tornaria um ambiente para facilitar o desenvolvimento. O problema de utilizar a IDE de cara é que ela esconde diversas complexidades inerentes ao sistema (, à linguagem de programação) de você. Essa (= compreender como o sistema funciona por debaixo dos panos) é um tipo de habilidade que é, ao menos a meu ver, bastante importante e necessária, só que são pouquíssimas as pessoas que eu conheço que a possuem. Não deveríamos formar programadores incompletos. Estou falando de coisas como saber o que é uma parsing tree, como um linker e um assembler funcionam, como é a mágica do coletor de lixo: não é algo que muitas pessoas aprendem, a maioria delas só quer ver o resultado final (= o programa funcionar).
  • 2014 – opa, olá presente. O emacs é o meu editor de texto principal. Tanto para propósito geral, quanto para gerenciar um projeto inteiro de C/C++ (+ (C)Makefiles), Python, etc. Ainda não sei se usaria ele para desenvolver Java, algumas features do Eclipse são realmente muito boas. Mas dá, com alguns modos (modo no emacs = plug-in, add-on, só para ficar claro) adicionais, não é nada desconfortável. Eu estou investindo uma boa parte do meu tempo para me especializar mais nele. Mas não pretendo me especializar demais (o porquê você já já vai ler). Agora sim, chegamos à segunda parte do post. Vamos refletir sobre os editores de texto atuais.

Parte 2 – Reflexões

De um lado, customização e extensibilidade: vim e emacs. De outro, conveniência, GUI, facilidades: TextMate e SublimeText. De outro lado, integração de ferramentas e do ambiente de desenvolvimento: IDEs — Eclipse, NetBeans, Eric, (…)

Hoje, sinceramente, um programador que está começando agora tem que tomar uma decisão de por onde começar, e eu não sei qual delas é a melhor (lembrando que vivemos em um mundo onde o tempo é curto e custoso, investimentos a longo prazo podem deixar de valer a pena depois de somente alguns meses).

Enquanto isso, uma nova categoria surge: editores e ambientes de desenvolvimento em nuvem. O Atom do Github e o Koding são dois ótimos exemplos. Qual o futuro disso, onde isso vai dar? O que o coitado especializado em vim ou em emacs durante mais de 10 anos vai fazer?

Vejamos algumas teorias para essas perguntas.

A primeira: editores em nuvem vão reinar. Não sei daqui a quanto tempo, mas vão reinar. Eu aposto no sucesso do Atom, se eu fosse um investidor, eu investiria nesse maldito =P. Isso significa que coisas como o TextMate e o SublimeText provavelmente devem ficar outdated. Esses editores em nuvem vão incorporar tudo deles, e provavelmente vão ter algum modo off-line também. Daí, não há desculpa para não usá-los.

Quanto aos vovôs dos editores Unix: acho que eles ainda vão sobreviver por um bom tempo. Especialmente porque a comunidade {open source, software livre, Unix, Linux, BSD} é bem resistente a mudanças (veja o GTK3 / Gnome 3 / Unity / systemd — resistências soltas por listas de e-mail e por fóruns de discussão, e mimimis por canais de IRC, não faltam). Eles ainda poderão ser úteis para um dado conjunto de tarefas. Mas, no que diz respeito a programar coisas “grandes”, escaladas, integradas, distribuídas e tal, acho que eles serão cada vez menos aptos para esse tipo de tarefa. Veja bem: eles são (e serão) ótimos para programar uma coisa específica (digamos, editar um arquivo XML). Mas, no que diz respeito programar o sistema de maneira integrada, como um todo, acho que eles não vão ficar muito bons para isso.

Isso se deve tanto ao suporte — cada vez menos extensões para o Emacs serão desenvolvidas, e cada vez mais extensões para esses editores em nuvem serão mantidas e mais fáceis de desenvolver, quanto à natureza deles. São multiplataforma, mas não estão na web. O Richard Stallman bem que queria transformar o Emacs em um processador de textos (1 e 2 — unrelated). Mas, eu acho isso bobagem. Nós, usuários de Emacs, deveríamos nos preocupar em portá-lo para a {web, nuvem}, isso sim.

OK, mas o futuro só podemos esperar. E quanto ao presente? Existem muitas opiniões sobre o “melhor” ambiente para programar, eu não vou falar sobre isso aqui porque isso é uma árvore com muitos filhos; só estou tentando despertar uma reflexão / discussão sobre o assunto.

A questão é: não acho que valha a pena tentar se especializar demais no Emacs (ou no Vim), porque existe uma boa possibilidade de eles morrerem daqui a alguns anos (quem sabe, daqui a alguns meses…). Em vez disso, a comunidade deveria tentar se ajudar de grão em grão, cada um fazendo uma coisinha ali e aqui — e, é isso que vem acontecendo hoje! Por isso que eu uso esse editor de texto maldito. Esse é o tipo de exercício que você aprende para toda a vida. Quando eu tiver que programar numa (ou uma IDE…quem sabe) IDE, já terei toda uma mentalidade diferente, sei as features que são mais importantes, o que é firula, etc.

Não duvido de que daqui a um mês apareçam ainda mais editores de texto em nuvem (concorrentes). O futuro da tecnologia está mudando muito rápido, e todo dia. Vamos ver no que isso vai dar.

[Post escrito utilizando o Markdown-mode do Emacs 😉 — Por exemplo, hoje isso é mais prático para mim do que utilizar o editor nativo do WordPress. No futuro isso provavelmente irá mudar…].

Metapost #2: Editores de Texto

Journal #1: movendo (quase) todas as músicas para a nuvem

A partir de hoje vou começar uma série de posts intitulada “journal”, cujo objetivo é sugerido pelo próprio nome: seria como uma espécie de diário ou logging sobre uma — ou várias — atividades que eu {estou fazendo, resolvi ter feito}. É uma oportunidade para a) deixar tudo documentado e b) open-sourcear pequenos fragmentos de conhecimento, que — hopefully — poderão ajudar alguém algum dia.

O que eu imagino para isso é continuar escrevendo as coisas do meu jeito e, agora mais que nunca, escrever de maneira completamente não imparcial e sob (unicamente) meu ponto de vista. Acho que essa é a única maneira [efetiva] para que o contexto do que eu descrever seja preservado.

Como proposto pelo próprio nome da série, não espere ver muito rigor (técnico) ou mesmo muitas revisões nesses posts. Se eu for escrever algum post mais técnico, ele não estará nessa série journal. O leitor lerá (o que mais o leitor pode fazer além de ler?) uma linguagem mais informal, na medida do possível.

Estreando a série, resolvi mover todas (mentira: quase todas, exceto as OST = original soundtracks de games e de filmes) as minhas músicas para a nuvem. Isso é ridiculamente fácil de fazer. Algoritmo inline: escolha um serviço que tenha cliente de sync (Dropbox, Google Drive, Copy) e jogue todas as suas pastas de música para lá. Bom, isso é realmente fácil de fazer, nada que um Control-X Control-V ou um arrasta-mouse-aqui-e-ali não resolvam, certo? Eu só espero que você tenha uma banda de conexão boa, senão…

https://i0.wp.com/farm6.staticflickr.com/5054/5426125324_e64c93831a.jpg
Fonte: Flickr

Continue reading “Journal #1: movendo (quase) todas as músicas para a nuvem”

Journal #1: movendo (quase) todas as músicas para a nuvem