Minha pequena teoria é que o conceito de “impressão” em psicologia pode ser facilmente aplicado à programação: tal como um bebé ganso decide que a primeira forma de vida em movimento que encontra é o seu progenitor, os programadores embrionários formam ligações inerradicáveis aos padrões e peculiaridades da sua primeira linguagem formativa.
Para muitas pessoas, essa linguagem é Ruby. Muitas vezes é creditado por fazer a programação “clicar”; os impressos falam disso com certo endividamento e carinho. Eu entendo isso. Escrevi meu primeiro “Olá, mundo” em uma coisa horrível chamada Java, mas a programação só começou a parecer intuitiva quando aprendi JavaScript (eu sei, eu sei) e OCaml – ambos moldaram fundamentalmente meus gostos.
Cheguei um pouco atrasado a Ruby. Foi só no meu quarto emprego que me encontrei em uma equipe que usava principalmente isso. A essa altura, eu já tinha ouvido elogios suficientes à sua elegância e estava cheio de expectativa, pronto para ser encantado, para experimentar o tipo de satori profissional que seus adeptos descreviam. Minha antipatia por isso foi imediata.
Chegar tarde a uma linguagem é vê-la sem a névoa indulgente de sentimentalismo que acompanha a impressão – a boa vontade de ignorar uma falha como uma peculiaridade. O que vi não foi uma ferramenta enfeitada com joias, mas uma coisinha que ainda não havia recebido a notícia de que o mundo da programação havia mudado.
Rubi foi criado em 1995 pelo programador japonês Yukihiro Matsumoto, carinhosamente chamado de “Matz”. Além de criar a única grande linguagem de programação originada fora do Ocidente, este mórmon praticante nascido em Osaka também é conhecido por ser excepcionalmente gentil, tanto que a comunidade Ruby adotou o lema MINASWAN, para “Matz Is Nice And So We Are Nice”.
Combinando com isso, além de seu nome bonito, Ruby é agradável aos olhos. Sua sintaxe é simples, sem ponto e vírgula ou colchetes. Mais ainda do que Python – uma linguagem conhecida por sua legibilidade – Ruby lê quase como inglês simples.
As linguagens de programação são geralmente divididas em dois campos: digitadas estaticamente e digitadas dinamicamente. Um sistema do tipo estático se assemelha a um conjunto de Legos em que as peças se interligam apenas com outras de formato e tamanho corretos, tornando certos erros fisicamente impossíveis. Com a digitação dinâmica, você pode juntar as peças como quiser. Embora isso seja teoricamente mais flexível em pequena escala, o tiro sai pela culatra quando você está construindo grandes estruturas – certos tipos de erros são detectados apenas quando o programa está em execução. Em outras palavras, no momento em que você coloca peso na passarela de Lego, ela desaba numa pilha inútil.
Ruby, você deve ter adivinhado, é digitado dinamicamente. Python e JavaScript também o são, mas ao longo dos anos, essas comunidades desenvolveram ferramentas sofisticadas para fazer com que se comportem de forma mais responsável. Nenhuma das soluções atuais do Ruby está no mesmo nível dessas. É muito propício ao que os programadores chamam de “armas de pé”, recursos que tornam muito fácil atirar no próprio pé.
