Orientação a objeto, e daí?

Não é tão incomum sugerir algo novo para um programador “orientado a objetos” e escutar alguma variante da velha frase “mas isso não vai de encontro a todas as noções conhecidas de orientação a objetos?”. Pode acontecer ao mostrar linguagens dinâmicas que permitem redefinição de métodos em tempo de execução, ao demonstrar as vantagens das closures ou até ao introduzir interfaces fluentes. Você escolhe.

Não precisamos nem discutir o que diabos é orientação a objetos para notar que o termo está perdendo o sentido mais rápido do que um raio. Nenhum dos exemplos citados parecem ofender o meu conceito de orientação a objeto e também não vejo porque feririam o de ninguém. Para ser sincero, desde quando os objetos tornaram-se tão sagrados que não possam ser subvertidos um pouco de vez em quando? Apesar disso já vi este argumento ser usado em todos os três casos.

O ponto aqui não é que orientação a objetos não sirva para nada. Nem que o purismo deva ser evitado. Na verdade, o purismo pode ser bastante útil como ferramenta intelectual. Duvido, por exemplo, que muitos dos recursos interessantes introduzidos em Haskell surgissem se não houvesse um compromisso com a pureza da linguagem em termos de transparência referencial. O grande problema com a orientação a objeto não é o purismo.

É o sucesso.

Com a popularização na última década da orientação a objeto o termo se disseminou. Isso fez mal para ele porque quanto mais gente conhece um termo fracamente definido, maiores as chances de ser desvirtuado ou simplesmente usado sem sentido nenhum. Parece que orientação a objeto acabou virando argumento contra qualquer coisa e, como geralmente ninguém sabe a que definição o falante está se referindo, não sobram muitos contra-argumentos. Nas poucas vezes que uma discussão mais ou menos civilizada é possível, o resistente acaba não se convencendo de verdade. Seria melhor que as pessoas dissessem que não gostaram da idéia, mas “estou sendo apresentado a esta técnica agora, parece diferente de tudo que já vi, estou com medo e não quero avaliar melhor as alternativas” não parece tão profissional. Sobra para a velha e leal orientação a objetos.

Resenha: Por que as pessoas de negócios falam como idiotas?

Num mundo onde o jargão e o palavreado vazio são a regra, expressar-se claramente e com objetividade pode ser um tremendo diferencial. Quando todos se esforçam para parecer iguais, ser a exceção garante um lugar de destaque e “Por que as pessoas de negócios…” é um livro que convence a aproveitar-se dessa situação.

O livro é estruturado em quatro partes, cada uma dedicada a uma das armadilhas: obscuridade, anonimato, venda agressiva e tédio. Na maioria das vezes as pessoas querem ser claras, mas o ambiente corporativo que as cerca não é exatamente um meio que as incentiva para isso. Na verdade, o caminho mais natural neste mundinho parece ser exatamente o contrário. Por isso o texto fala de armadilhas, são coisas que nos capturam sem que notemos e das quais ninguém se aproxima de propósito.

Acontece com todo mundo. Tem o gerente que quer parecer mais inteligente que os outros usando algumas palavras difíceis, como “aculturamento”, “objetivar” e “endereçamento”, mas que no fim das contas só deixa de ser compreendido. Qual o problema com “endereço”, afinal?

Tem também o programador sempre ligado na evolução da computação mundo afora que de tanto ler em inglês começa a escrever como se seus textos em português tivessem passado por um tradutor automático dos mais fraquinhos. Parece que o português está ficando obsoleto (ou seria “depreciado”?). O negócio agora é dificultar a compreensão falando portuglês através de expressões como “sistema irresponsivo” ao invés de “sem resposta” ou “comer a própria comida de cachorro” ao invés de “provar do próprio remédio”. Ou até perpetuar traduções tortas como “aplicativo de missão crítica”, que já vem da expressão completamente desprovida de significado “mission critical application” e deveria ser “aplicativo crítico para a missão”.

Muita gente deixa a personalidade em casa quando sai na segunda-feira de manhã e veste um manto de obscuridade disfarçado de profissionalismo junto com a roupa do trabalho. Por causa do ambiente esterilizado da vida corporativa, pensam que precisam deixar aquela pessoa engraçada bem longe e tornarem-se uma versão pausterizada de si mesmos oito horas por dia, cinco dias por semana.

O livro tenta mostrar sempre com muito bom humor quais são as armadilhas mais comuns do discurso corporativo e insiste no argumento de que são exatamente isso: armadilhas. As pessoas não se esforçam para parecer evasivas e vazias de propósito. É bem verdade que às vezes elas querem realmente sair de alguma saia justa, mas isso não acontece todo dia. Portanto, da próxima vez que vir alguém se perdendo com termos esquisitos como “governança” e “missão crítica”, controle a raiva e não ataque ninguém. Ao invés disso, alerte a pessoa para o fato de que talvez os outros não a estejam entendendo muito bem e que talvez seja interessante mudar um pouco o estilo de comunicação.

Por falar nisso, se isso acontecer aqui neste blog, por favor não hesite em avisar. Eu não vou achar que você está sendo implicante nem chato. Prometo.

Pó de estrelas

Parece que Thomas Thurman, um programador envolvido no projeto Metacity, andou falando (ou pelo menos sugerindo) que os astros e estrelas da programação não estão interessados em fazer pequenos consertos. Houve uma discussão interessante sobre esse tema em um dos últimos episódios do LugRadio e os caras citam o Metacity como exemplo de aplicação que não deve parecer muito atrativo para os astros. Para quem não sabe, Metacity é um gerenciador de janelas, um programa responsável, entre outras coisas, por organizar as janelas na tela, decidir onde uma janela vai ser aberta e lidar com redimensionamento e movimentação; ou seja, um programa que quanto mais invisível melhor. Este projeto em particular é tão invisível que nem um website tem. Se você tomar o cuidado de verificar o link que coloquei acima, vai ver que fui obrigado a referenciar um site ftp que contém o código fonte, já que é a referência usada por todo mundo. O raciocínio é que programas de infra-estrutura invisíveis como este não são muito bons para massagear a fama, afinal é difícil ser visto dentro de algo invisível.

Porém programadores não costumam ficar famosos por programar. Então não faz muita diferença se alguém está programando um novo jogo revolucionário ou se dedica seu tempo a escovar bits em um driver para um dispositivo usado por um total de duas pessoas no mundo todo. Eu sei que dizer isso deve ser algum tipo de clichê, mas não posso evitar: programadores famosos não ficaram assim por se preocupar com código, mas por se preocupar com as pessoas.

Isso obviamente não significa que programadores famosos não cuidam do seu código. A maioria deles se preocupa bastante, mas esta não é a razão que os torna admirados por seus pares. Eles conseguem chegar aos pedestais porque tomam o cuidado de compartilhar idéias com os colegas e tornar a indústria toda um lugar melhor para se trabalhar.

Tomemos o Linus Torvalds como exemplo. O cara dispensa qualquer tipo de apresentação, ninguém consegue esquecer o que ele inventou. O que ele escreveu é um núcleo de sistema operacional, algo que, simplificando grosseiramente, só faz se comunicar com o hardware e distribuir tempo de processador e memória para os vários programas que as pessoas querem realmente usar. Ninguém usa o kernel em si, este é só um mal necessário para quem quer rodar programas úteis e é provavelmente o mais longe do usuário final e perto da máquina que se pode chegar. Ninguém nota o kernel trabalhando, assim como ninguém nota o Metacity. As pessoas só notam esses programas quando eles dão pau, se um driver não funciona direito ou se as janelas não querem sair do lugar, por exemplo. O programa do Linus é talvez ainda mais invisível do que o Metacity e mesmo assim ele é um dos programadores mais conhecidos atualmente.

Ele não chegou a este ponto simplesmente por ter escrito um kernel fantástico, mas porque tomou o cuidado de envolver as outras pessoas nisso. Pediu e ofereceu ajuda em listas de discussão, publicou seu código para ser estudado e criticado pelos outros, fez palestras sobre seu modelo de desenvolvimento e até escreveu um livro para contar a história. Ele divulgou uma mensagem e isso fez muita gente crescer junto com ele.

Para alguns exemplos aqui da terrinha vamos considerar primeiro alguns caras que publicam código, como Vitor Pamplona ou o Marcos Tapajós. Da última vez que olhei, o Vitor tinha quatrocentos e vinte e cinco mil, duzentos e noventa e dois projetos publicados como software livre (e o número já deve ter aumentado enquanto eu digitava esta frase). Mas ninguém ia saber quem ele é se não tivesse feito coisas como montar um fórum para reunir a comunidade Java, organizar um blog para escrever textos que ajudassem os outros a se desenvolver e publicar o código dos seus programas para os outros verem. Do mesmo modo, o Tapajós ainda estaria escondido em um buraco em algum lugar se não contribuísse com os outros através de comentários construtivos e se não compartilhasse sua experiência. Eles poderiam gabar-se de como seus programas são maravilhosos em quantas listas de discussão quisessem, se não fizessem nada pelos outros, ninguém iria dar muita atenção.

Não é necessário ter programas famosos para um programador ser respeitado. Um bom exemplo, também brasileiro, é o Vinicius Teles. Ele até andou divulgando um sistema de busca de imóveis misterioso no blog dele, mas acho que ninguém viu ainda o tal sistema até hoje. Também não sei se ele tem algum projeto com o código publicado em algum lugar da Internet. A questão é que eu nem preciso saber. Ele tem o meu respeito — e o de vários outros programadores — porque ajuda seus colegas de alguns outros zilhões de maneiras diferentes como ao publicar entrevistas e até pequenos desabafos em formato de podcast, ao participar em listas de discussão sempre com mensagens detalhadas e esclarecedoras ou até ao organizar conferências das quais não vou poder participar.

Para conseguir reconhecimento e respeito, um programador não precisa só programar muito bem: precisa divulgar seu trabalho. O segredo é que não adianta simplesmente bater no peito e gritar seus feitos aos quatro ventos. Se quiser que alguém o respeite, é preciso ajudar os demais. Ninguém gosta de um sabe-tudo. O crédito que um programador tem dentro de sua comunidade é muito mais uma função do tempo que ele dedica a seus colegas do que do tempo que investe em escrever código.