Mergulhando no Caos

Este é o primeiro artigo de uma série com minha avaliação do Debian Etch e Ubuntu Feisty Fawn, lançados em abril de 2007. Os demais artigos serão publicados em breve, conforme sejam finalizados.

---

Abril foi um mês bastante movimentado no mundo Linux. Duas das maiores distribuições publicaram novas versões estáveis: o Debian 4.0 (Etch) saiu dia oito, quase dois anos depois do Sarge, e o Ubuntu 7.04 (Feisty Fawn) saiu duas semanas depois (quinta-feira, dia 19). Eu uso as duas no meu desktop principal e como iria fazer a atualização de qualquer modo, resolvi aproveitar para dedicar algum tempo a uma resenha simultânea.

Meu intuito não é criar mais uma polêmica com um artigo do tipo “Ubuntu matando Debian”: eu sinceramente não acho que o Ubuntu tenha esse tipo de tendência suicida. Esta breve resenha é somente para oferecer minha visão de usuário e entusiasta das duas distribuições. Eu sou programador (e, se é que isso faz alguma diferença, atualmente estou usando principalmente Ruby, Java e Haskell), portanto esta resenha deve ser mais útil para quem tem um perfil parecido. Mas, se este não é seu caso, não precisa abandonar a leitura ainda. O velho ditado já dizia que ninguém é de ferro e quem sou eu para contrariar velhos ditados? Eu também escuto música, assisto vídeos e uso alguns aparelhos externos como câmeras digitais e tocadores de música, coisas que todo mundo exige de um computador hoje em dia — e que em muitos casos são tudo que se exige. Só não espere encontrar algo sobre aplicativos de escritório por aqui.

O sistema

A máquina que estou usando para estes testes é meu sistema de casa. Na época em que a montei (há uns bons dois anos e meio) ela era razoavelmente possante, mas acho que hoje em dia equivale a um PC médio desses que já vêm encaixotado e que os vendedores de supermercado empurram para quem está “procurando um computador”. É um Athlon XP (32 bits) 2000+ com 512MB de memória RAM, 160GB de disco rídigo e placa de vídeo com chipset NVidia FX 5200 e 128MB de memória.

Na minha classificação esta máquina com certeza não está acima de “razoável”. Apesar disso, tanto com o Debian como com o Ubuntu, ela consegue se sair bem para o que preciso atualmente e não demonstra sinais de cansaço mesmo quando estou usando um ambiente de desenvolvimento muitas vezes considerado pesado (e, para quem conhece, este seria o Eclipse com alguns plugins personalizados), navegando com algumas abas abertas e com os efeitos de desktop 3D ativados.

Portanto, ponto para as duas distribuições no quesito performance.

Instalação

O processo de instalação para cada umas das duas distribuições demorou pouco mais de uma hora. Boa parte deste tempo foi usado na comunicação com os servidores. Eu fiz a instalação logo após os lançamentos oficiais e é de se esperar que o tempo seja um menor agora que o servidores estão um pouco menos sobrecarregados. Obviamente, tudo isso depende também da qualidade da sua conexão com a Internet.

Esperar uma hora pela instalação do sistema operacional não é uma das coisas mais divertidas que se pode fazer com um computador. No entanto, a instalação do Ubuntu brilha nesta área. O processo todo é feito a partir de um CD Live e o sistema pode ser usado normalmente durante a instalação. Isso significa que enquanto tudo é instalado você pode ler seus e-mails e notícias ou então começar a preparar algum artigo para o seu blog. A instalação do Debian, por outro lado, roda em modo texto. Você ainda pode navegar na Internet usando o lynx ou algum outro navegador em modo texto, mas a experiência com certeza não é a mesma. De qualquer modo, o processo não é tão traumático porque não é todo dia que você vai reinstalar um sistema Debian do zero. O meu poderia ter sido atualizado normalmente a partir da versão Sarge, só fiz uma instalação limpa para poder relatar minhas experiências aqui para meus 80 milhões de leitores.

Outro recurso da instalação do Ubuntu que me agradou bastante foi a habilidade de importar dados pessoais de outros sistemas operacionais. Isto permite, por exemplo, que você importe do seu Windows coisas como mensagens de e-mail salvas localmente, endereço de acesso ao Messenger e endereços gravados no seu navegador. Eu não precisava disso dessa vez, mas teria sido bem útil há um ano e meio quando instalei meu primeiro Ubuntu (que também foi meu primeiro Linux). Parabéns para a equipe do Ubuntu por facilitar a migração.

Colírio para seus olhos

Um dos recursos mais polêmicos desta versão do Ubuntu foi a inclusão de efeitos 3D para a área de trabalho. Durante o desenvolvimento do Feisty os boatos se espalhavam rapidamente. Era comum escutar numa semana que os efeitos estariam dentro e ver a notícia ser desmentida na semana seguinte.

Falar em efeitos visuais para desktop Linux ultimamente é falar de XGL, Compiz e Beryl. Porém, o pivô de toda a polêmica não foi nenhum dos três. Por trás de tudo estavam os drivers binários.

Os drivers de código-aberto para placas 3D sob Linux ainda não têm todos os recursos necessários para proporcionar o tipo de experiência que o Ubuntu queria. Como a filosofia do projeto é não incluir código proprietário na instalação padrão, eles precisaram chegar a algum meio termo razoável. E finalmente conseguiram: disponibilizaram os drivers proprietários de forma fácil após a instalação. Desse modo, quem quer ativar os recursos avançados pode fazê-lo facilmente ao mesmo tempo que aqueles que não fazem questão não precisam executar código proprietário.

A instalação dos drivers 3D está a dois cliques da instalação padrão. Depois que a instalação estiver concluída, é só parar de ler seus e-mails, reiniciar a máquina e seguir para Sistema > Administração > Gerenciador de Drivers Restritos. Isto vai fazer com que o driver seja automaticamente baixado e instalado. Para ativar os efeitos é só marcar um campo em Sistema > Preferências > Efeitos da Área de Trabalho. Fácil assim.

Resumo

Instalar e rodar as duas distribuições está bem fácil. A configuração padrão vem com os programas mais comuns e depois só é preciso adicionar aqueles outros mais específicos. Não é preciso saber exatamente que programas você precisa para fazer uma instalação, mas é possível escolher um por um se você souber o que quer.

O Ubuntu sai na frente para quem quer admirar alguns efeitos visuais interessantes no desktop por permitir a instalação fácil dos drivers binários e a ativação simples dos recursos visuais. Nada é impossível com o Debian, mas talvez você tenha que pesquisar e perguntar para mais pessoas e acabe levando um pouco mais de tempo.

Este artigo é apenas a primeira parte da resenha. A próxima parte, que será publicada em breve, irá se concentrar nos recursos multimídia, incluindo integração com dispositivos externos.

O mundo todo é formado a partir de coisas pequenas. Não importa quão grande seja a casa daquele novo figurão, ela precisa ser construída tijolo a tijolo. Enxames são feitos de pequenas abelhas, países são feitos de cidadãos e mercados são feitos de negociantes. No entanto, o resultado final do conjunto em todos os casos é um conglomerado grandioso e costuma ser considerado uma entidade única por vários motivos, que vão do retórico ao pedagógico. Fica difícil ver a floresta inteira quando se está no meio das árvores. Para entender o todo, precisamos ignorar por um momento as partes e analisar o conjunto como uma entidade única.

Isso é importante em muitas situações e não há como negar que o homem só chegou onde está por ter desenvolvido essa capacidade. Mas estamos acostumados a partir das partes para o todo. Estamos acostumados a sintetizar. O perigo mora no caminho inverso: tratar o todo como um entidade indivisível e esquecer que para mudá-lo é preciso dispensar muita atenção para as partes.

Quando uma empresa precisa melhorar sua capacidade de produção ou velocidade de resposta, uma das piores coisas que se pode fazer é tentar projetar e aplicar uma metodologia qualquer que trate a organização inteira como uma grande equipe. Tudo que uma grande organização menos precisa é de uma metodologia para uma equipe de centenas de pessoas. O que ela precisa na verdade é de centenas de equipes de poucas pessoas. Não é preciso achar uma metodologia gorda e formar uma equipe gigante, mas formar equipes pequenas e arrumar metodologias enxutas.

Necessariamente nesta ordem.

Todo mundo já ouviu falar que formas ágeis de trabalho funcionam melhor para equipes pequenas e há quem prefira abordagens mais peso-pesado justamente por este motivo. O interessante é que isto não é uma fraqueza. Qualquer abordagem para coordenação de pessoas funciona melhor com equipes pequenas. Portanto, ter equipes grandes não é motivo para evitar uma abordagem ágil. Os grupos de trabalho simplesmente deveriam ser menores. Grupos pequenos conseguem se organizar e comunicar-se mais facilmente do que grupos grandes simplesmente porque há menos gente para coordenar. Se você tentar reunir mais de duas pessoas para escolher um único prato em um restaurante novo, vai saber do que estou falando.

Equipes pequenas costumam vencer as grandes no quesito adaptabilidade. O pequeno e simples é mais rápido para se adaptar. Bactérias, por exemplo, são extremamente adaptáveis justamente por serem criaturas bem simples. São capazes de se reproduzir e evoluir tão rapidamente que os médicos precisam evitar prescrever os mesmos antibióticos por períodos prolongados para uma mesma população a fim de evitar que elas se acostumem à droga e evoluam para algum tipo de super-bactéria resistente à medicação. A capacidade de adaptação delas é tamanha que “períodos prolongados” aqui são medidos no máximo em algumas dezenas de anos, ao contrário dos vários milhares de anos necessários para a evolução de organismos mais complexos como o homem. O mesmo ocorre com equipes pequenas. Na presença de uma adversidade ou mudança de ambiente, elas podem mudar de rumo muito mais rápido que uma equipe com algumas dezenas de pessoas.

Tem um tipo de blog pelo qual tenho uma ojeriza tremenda: o blog-diário. Acho que eles já pararam de fazer isso (porque migraram para os sites de relacionamento), mas sabe aqueles blogs de adolescentes cujos artigos costumam ser sobre a festinha de ontem ou a bronca que o professor passou na turma hoje mais cedo? Sabe aqueles blogs cujos artigos mais elaborados são aqueles que têm uma letra de música qualquer que o autor e seus amiguinhos estavam escutando no dia (e mais nada)?

Este tipo de coisa não acontece somente com garotos e garotas de 14 anos, alguns blogueiros na área de tecnologia também estão infectados com a mesma doença. Neste caso os assuntos mudam um pouco. Passam a ser sobre o último release dos seus projetos, as conferências mais badaladas e os encontros de grupos de usuários locais. Eles podem não notar, mas estão agindo do mesmo modo que os adolescentes. Estão somente publicando um diário de bordo.

Acho que blogs deveriam ser um meio para publicar opiniões e vê-las serem destrinchadas, atacadas e testadas. Se estivéssemos em uma revista semanal, os blogs deveriam ser mais como uma coluna ou um editorial do que como o resumo da semana. Os leitores não querem saber o quanto o autor é inteligente, produtivo ou como tem sucesso em tudo que resolve fazer. Ao invés disso, um blog deve ser um espaço para o autor ajudar os leitores a se tornarem mais inteligentes, produtivos e a terem mais sucesso em tudo que resolverem fazer.

Apesar disso tudo, acabei caindo nesta armadilha em conseqüência da correria nossa de cada dia. Se você consultar os históricos aqui do blog, vai ver que os dois últimos artigos anteriores a este se encaixam perfeitamente no que eu descrevi como artigos de blog-diário. O último é só um anúncio de reunião de grupo de usuários e o penúltimo uma bela de uma babada em meu próprio trabalho juntamente com o anúncio da publicação do Motiro (não consegui resistir a mais um link). Mas o sinal mais alarmante de que eu estou usando meu blog como um diário é que este mesmo artigo que você está lendo agora também é só mais uma anotação de diário.

Sim, eu publiquei toda esta introspecção e fiz você ler até aqui somente para anunciar que participei da entrevista que o Eduardo Fiorezi fez com o Vitor Pamplona. Foi bastante gratificante receber um segundo convite para o programa do Eduardo, principalmente por ter sido surpreendido com uma posição de entrevistador ao invés de entrevistado e pela estrela do programa ser uma figura tão relevante.

Espero que com estes três últimos artigos eu não tenha perdido metade da minha audiência, mas prometo que vou fazer de tudo para que o próximo revele algum pensamento interessante sobre tecnologia.

Por enquanto, um anúncio de entrevista disfarçado de reflexão é tudo que tenho a oferecer.

Estávamos pensando em organizar um encontro de usuários Ruby em Recife e depois do ótimo artigo da Kathy Sierra ressaltando a importância do contato cara-a-cara não podemos mais deixar para depois. A idéia é que depois dessa pequena reunião inicial possamos começar a formar um grupo de usuários local para estudarmos juntos, organizar palestras e fazer começar aquele negócio que falam tanto por aí chamado de comunidade. Com um encontro presencial nos fortalecemos e juntos podemos ajudar melhor quem está querendo aprender.

O encontro será na próxima quarta-feira (dia 21) à noite no bar Recanto Paraibano no Parnamirim. Precisamos saber mais ou menos quantas pessoas vão aparecer para dimensionarmos o local. Quem for de Recife e estiver interessado em participar, pode me responder em particular (meu e-mail fica no GMail: thiago ponto arrais) para nos organizarmos. Dependendo da participação, talvez precisemos alugar o Chevrolet Hall ou coisa do tipo.

Acabei de publicar a versão 0.6.3 do Motiro, uma ferramenta de acompanhamento de projetos na qual venho trabalhando há algum tempo. A maior modificação desta versão foi a publicação do pacote como Ruby Gem. Isso deve permitir que qualquer um com o sistema devidamente configurado (basicamente Ruby com Gems instalado) possa instalar o Motiro com dois comandos simples:

$ gem install motiro --include-dependencies
$ motiro install <um local no sistema de arquivos>

Há algumas formas de instalação alternativas para quem estiver interessado. Além disso, às vezes as coisas não correm tão bem quanto gostaríamos. Para todos os casos há mais detalhes na página de instalação do Motiro.

Quando se está projetando uma linguagem de programação nova, é preciso ter um objetivo principal, um tema, em mente. Você pode querer que sua linguagem proporcione diversão, leve uniformidade e simplicidade extremamente a sério ou que sirva de base para o que houver de mais moderno em termos de pesquisa em linguagens de programação. O número de escolhas possíveis é estonteantemente grande, mas uma coisa é certa: não se pode ter tudo ao mesmo tempo. Não dá para incluir todos os recursos que puder imaginar na sua linguagem nova porque ela seria muito difícil de aprender.

Então nos fim das contas, é preciso escolher o que entra e o que fica de fora. Algumas coisas que ficaram de fora podem ser incluídas em bibliotecas e outras publicadas em artigos e livros e chamadas de padrões de projeto. Os padrões precisam existir porque nenhuma linguagem é a melhor alternativa para todos os trabalhos. Por causa disso as pessoas acabam inventando pequenas gambiarras para resolver alguns problemas comuns que a linguagem não resolveu. A cultura da linguagem influencia as pessoas quando estão bolando essas gambiarras e assim os padrões surgem em várias equipes independentemente.

Um padrão não é nada mais que uma gambiarra para contornar fraquezas de algumas linguagens. Estas fraquezas são completamente naturais. Não se espera que toda linguagem consiga dar suporte a todo tipo de construção, mas que seja boa naquilo a que se propõe. Já que não há como ter suporte direto a tudo que se possa pensar, as pessoas começam a criar construções padronizadas para cada tipo de trabalho. Estas construções são os padrões.

Antes da orientação a objeto tornar-se a panacéia que é atualmente e ser requisito primordial para toda e qualquer linguagem de largo uso, ela já era utilizada na forma de padrões em linguagens como C. Uma das formas de se fazer isso era ter uma estrutura de dados para armazenar os valores dos atributos e os endereços para o código executável das funções que operavam sobre os atributos (os famigerados métodos). Deste modo os dados e as operações sobre eles ficam agrupados, exatamente como nos nossos objetos de hoje. Quando alguém queria executar uma operação sobre um objeto bastava usar o endereço de memória indicado nele próprio. Com esta organização ainda é possível ter coisas como herança e classes abstratas. Este padrão é bem interessante se você quiser desvendar como seu código orientado a objeto é executado pela máquina, mas o objetivo deste artigo não é ensinar como fazer objetos em C e quem estiver interessado em mais detalhes pode dar uma olhada no artigo do Mark Dominus.

Se o termo fosse tão popular na época quanto é hoje, essa construção poderia muito bem ter sido classificada como padrão de projeto. Ela não teve esta honra, mas foi tão aceita e utilizada que acabou sendo incorporada em linguagens posteriores, como C++ e Java. Com estas novas linguagens não era preciso lembrar de construir a estrutura de dados ou evitar utilizar os membros tidos como privativos, tudo isto podia ser controlado automaticamente pelos compiladores e interpretadores. Quando uma linguagem incorpora alguma construção, as pessoas começam a pensar de forma mais abstrata e acabam surgindo novos padrões sobre os antigos. De fato, seria difícil imaginar que teríamos padrões como o Visitor ou o Iterator hoje se ainda precisássemos nos preocupar em controlar ponteiros de funções dentro de estruturas de objetos.

No entanto, os padrões são aplicáveis a linguagens específicas. O caso dos Iteradores¹ é bem interessante. Eles são uma solução para o problema de executar um determinado trecho de código (uma função) sobre todos os elementos de algum tipo de recipiente. Em linguagens funcionais, como Haskell, este problema não é nem um problema porque um de seus principais propósitos é permitir tratar funções como cidadãos de primeira classe e possibilitar passá-las de um lado para o outro como qualquer outro valor. Iteradores também desaparecem na maior parte das linguagens que suportam blocos anônimos, como Ruby. Se alguém quiser muito, pode até usar um Iterador em Ruby, mas não há nenhum motivo para fazer isso quando pode-se usar blocos anônimos. Estas linguagens eliminam a necessidade deste padrão porque ele pode ser incorporado à linguagem na forma de bibliotecas.

Algumas linguagens possuem mesmo esta capacidade de permitir que os padrões sejam escritos apenas uma vez e reutilizados muitas outras. Deve ser por isso que Paul Graham parece não gostar de padrões. Ele é um programador Lisp e o modo de se fazer um programa Lisp é inventar um dialeto (essencialmente uma linguagem nova) e utilizá-lo (junto com um monte de parênteses) para resolver o problema. Os padrões acabam sendo incorporados ao novo dialeto durante seu desenvolvimento e não faz muito sentido catalogar esses padrões se eles já estão codificados. Inventar uma linguagem nova para cada problema pode parecer exagero e realmente é, se a linguagem base não tiver sido projetada para isso. Mas Lisp foi e não há nada mais natural para um programador Lisp do que fazer um pequeno dialeto.

Enquanto existirem computadores para serem programados, isso vai continuar a acontecer. As melhores gambiarras vão ser chamadas de padrões e os melhores padrões serão incorporados a novas linguagens, tornando-se invisíveis ou desnecessários. Foi assim que aconteceu com chamadas de subrotinas, classes, objetos e outras várias construções que hoje achamos extremamente naturais. O melhor de tudo é que esta evolução toda nos permite pensar cada vez mais longe da máquina e de forma mais natural. Assim podemos manter o ciclo inventando novas gambiarras que podem se tornar novos padrões que por sua vez podem ser incorporados a novas linguagens.

Padrões são gambiarras, mas não são como qualquer gambiarra. O que realmente diferencia um padrão de projeto das demais gambiarras é o fato de ter um nome. Os nomes dos padrões permitem que os programadores se comuniquem mais eficientemente. Eles podem se referir às gambiarras pelo nome, ao invés de dizer “acho que aqui podemos usar uma gambiarra que eu vi em outro sistema” e depois precisar de um bom tempo para explicar.

A maior força dos padrões é também sua maior fraqueza. Um vocabulário rico ajuda muito os experientes, mas pode atrapalhar os novatos. Para começar a programar sério em uma linguagem onde toda solução precisa a ser repleta de convenções e padrões, não basta aprender somente a linguagem base: é preciso aprender também todo um vocabulário de padrões. Mais ou menos como aprender um segundo idioma não é só estudar a gramática para formar frases estruturalmente corretas, mas também manter-se em contato com o idioma a fim de incrementar o vocabulário e aprender como os nativos falam para evitar soar como um tradutor automático.

1. Iterador é o nome que uso em português para Iterator, caso você esteja caindo do septuagésimo-terceiro andar da Torre de Babel e ainda não tenha ligado o nome à pessoa

Programar um novo sistema é como projetar seu próprio mundo. É preciso descrever como as coisas vão interagir e como as mudanças vão se propagar no ambiente. Os programadores podem começar com nada mais que uma idéia, materializá-la em código e produzir algo vivo. Como bônus extra, suas criações podem ainda ajudar a resolver algum problema do mundo real. Ao projetar seus sistemas eles têm a oportunidade de experimentar a alegria da criação, a surpresa da descoberta, o prazer da invenção e tudo que houver no meio.

Ter seu próprio mundo de faz-de-conta e ainda usá-lo para resolver problemas do mundo real parece tão divertido que deve ser praticamente impossível de se tornar um trabalho chato.

Mas a verdade é que muitas vezes se torna. Afinal de contas a vida não é um conto de fadas. Mais cedo ou mais tarde, vem aquela vontade de repetir estruturas de código familiares, aplicar soluções não muito apropriadas e — pasmem! — copiar e colar código. O pior problema das soluções sujas é a capacidade de atrair mais janelas quebradas. Para se afundar na lama do código ruim, basta cometer a primeira transgressão. As demais virão naturalmente simplesmente porque o código já está sujo e as pessoas vão começar a pensar que uma gambiarra a mais ou a menos não vai fazer mal a ninguém.

A boa notícia é que existe um detector natural para quando se está fazendo besteira. Algo como um canário em uma mina de carvão. Este algo é o tédio. Escrever código repetido é chato. Tentar adaptar uma solução onde ela não se encaixa muito bem é chato. Copiar código de um lugar para outro é chato. Tédio é um subproduto natural do trabalho impensado, então basta eliminar suas causas para evitar boa parte dos danos ao código.

Programar pode ser um dos exercícios intelectuais mais desafiadores. Quando o desafio e a diversão são substituídos pelo tédio, alguma coisa está errada. A solução para boa parte dos casos é procurar uma forma de eliminar a repetição e — adivinhe só — computadores foram feitos justamente para isso. Se trabalhamos para evitar que os outros façam trabalho repetido, por que iríamos nós mesmos nos repetir? Por que se entediar quando a máquina pode executar a mesma tarefa indefinidamente sem cansar nem reclamar?

Eliminar repetição não é fácil e justamente por isso é divertido. Da próxima vez que estiver programando, imagine que você não pode repetir a mesma idéia duas vezes. Veja repetição onde ninguém está prestando atenção. Observe o que é chato de ser feito. Procure resolver estes problemas sem criar outros. A sua solução pode vir em vários sabores: talvez haja uma nova abstração pronta para ser codificada, uma biblioteca querendo nascer ou uma nova linguagem escondida em algum lugar. Tente descobrir o que se aplica ao seu caso. Enquanto estiver fazendo isso, tenha em mente que você não deve se entediar em nenhum momento.

Mantenha o ânimo em alta para manter a sujeira em baixa.

Na última quinta-feira (dia 25) foi divulgada a versão final do artigo A History of Haskell: being lazy with class de Simon Peyton Jones, Paul Hudak, John Hughes e Philip Wadler. O artigo vai ser publicado na terceira Conferência de História das Linguagens de Programação (History of Programming Languages Conference – HOPL-III), a ser realizada em Junho de 2007. Os autores estão mais do que habilitados para contar a história da linguagem. Todos eles tiveram papéis importantes em vários eventos. Hudak, por exemplo, ficou responsável por pedir permissão à viúva do matemático Haskell B. Curry para que o nome dele fosse usado para batizar a linguagem.

Há mais curiosidades como esta no artigo. Ele está muito bem escrito (como era de se esperar destes gigantes) e é uma ótima leitura, apesar do tamanho (55 páginas). Altamente indicado para quem quer conhecer a linguagem e sua história. Não é todo dia que podemos ouvir história diretamente de quem fez história. Recomendo atenção especial para a seção de ferramentas. Eles foram suficientemente gentis para lembrar do EclipseFP.

Eduardo Fiorezi publicou ontem o primeiro episódio do que espero que seja uma longa série de podcasts sobre desenvolvimento de software e eu tive a honra de ser o primeiro entrevistado do programa. Ele está bastante interessado em abordagens ágeis, tecnologias para aumentar a produtividadefelicidade do programador e novidades na área de desenvolvimento de software. Portanto, o conteúdo deve interessar a eventuais leitores deste blog.

Só que o podcast tem a vantagem de não exigir atenção exclusiva dos seus olhos. Dá para escutar a caminho do trabalho, ao fazer seu exercício diário e até enquanto programa alguma parte chata do seu sistema. Se bem que se há algo de chato no seu sistema, há algo de errado.

Devido à recente explosão de popularidade das linguagens dinâmicas, você provavelmente já deve ter ouvido falar de duck typing. É a noção que o tipo de um objeto é determinado exclusivamente pelas mensagens às quais ele pode responder. Se dois objetos quaisquer respondem a um mesmo conjunto de mensagens, eles podem ser considerados do mesmo tipo. É uma versão programática do já clássico dito “se algo grasna como um pato e nada como um pato, deve ser um pato.”

Para quem está acostumado com definição estática de tipos, talvez faça sentido pensar que é como se houvesse interfaces definidas dinamicamente de acordo com as necessidades do código em execução. Algoritmos de ordenação, por exemplo, conseguem trabalhar com qualquer conjunto de objetos comparáveis. Ou seja, que forneçam métodos de comparação como maior, menor e igual. Com duck typing, estes objetos não precisam indicar que satisfazem a interface Comparable, precisam apenas responder às mensagens esperadas e o algoritmo de comparação pode tratar todos como comparáveis. Afinal eles respondem se são maiores ou menores que os outros, portanto devem ser comparáveis.

O tempo passa, as linguagens evoluem, surgem novos conceitos e os animais vão ficando maiores. Steve de Korte, criador da linguagem Io, em uma entrevista de julho do ano passado (ouça a primeira parte também) introduziu um conceito que dá para chamar de elephant typing. Ele usa elefantes como analogia para explicar programação com protótipos.

O modo mais comum de criar um objeto em uma linguagem baseada em protótipos é clonar um objeto pré-existente e especializar o clone do modo que for necessário. O clone inicialmente possui as mesmas propriedades que o objeto original e pode ser descrito a partir daí evitando repetição. Para descrever o Dumbo por exemplo, você poderia dizer:

“Dumbo é um elefante como aquele que você viu no zoológico. Só que é um filhote e por isso é um pouco menor. As orelhas dele são bem maiores e ele pode voar. Além disso, ele carrega uma pena na tromba a maior parte do tempo por acreditar que é ela que o faz voar.”

Há objetos, mas não há classes. O programador especifica somente as diferenças do clone para o protótipo. Se mais tarde algo for descoberto sobre o protótipo, também vai valer para o clone. Por exemplo, se depois você descobre que o elefante do zoológico tem medo de ratos, pode presumir que Dumbo também tem. Trocando em miúdos, em Io, se você alterar um objeto adicionando um método novo ou modificando o valor de um atributo, a alteração é propagada para todos os descendentes. Entretanto, este não necessariamente é o comportamento dos protótipos das demais linguagens.