Filosofia de engenharia: Yukihiro Matsumoto (Matz)

Principais conclusões

• Projete para os humanos, não para as máquinas. Matz transformou a alegria do programador na função objetivo e deixou o silício pagar a conta. Cada decisão sintática responde à pergunta “como uma pessoa vai se sentir ao ler isto?” antes de “com que velocidade os bytes vão se mover?”.
• A menor surpresa significa a minha menor surpresa. O princípio não é uma enquete sobre as expectativas dos iniciantes; é um autor fluente minimizando a própria frustração, medida depois de você aprender bem o Ruby.
• MINASWAN: a cultura é um resultado de projeto. “Matz é gentil, então nós somos gentis” mostra que a comunidade de uma linguagem é uma superfície que você pode projetar, e não um mero acaso derivado de sua gramática.
• Ruby é um único gosto aplicado sem descanso. Sua coerência vem da síntese: Perl, Smalltalk, Lisp, Ada e Eiffel harmonizados em uma só voz, em vez da média de um comitê.

O princípio

“Para mim, o propósito da vida é, em parte, ter alegria. Os programadores muitas vezes sentem alegria quando podem se concentrar no lado criativo da programação, então o Ruby foi projetado para deixar os programadores felizes.” – Yukihiro Matsumoto¹

A maior parte do projeto de linguagens otimiza para a máquina. Velocidade de compilação, organização da memória, número de instruções, tudo aquilo com que o silício se importa. Matz inverteu a prioridade. Ele decidiu que o humano diante do teclado era o público que importava, e que o trabalho da máquina era servi-lo. “As máquinas deveriam servir aos seres humanos”, disse ele. “Muitas vezes os programadores servem às máquinas de forma inconsciente. Deixe as máquinas servirem você.”²

A alegria, aqui, é uma restrição de projeto rígida, não um sentimento brando disfarçado de engenharia. Se a alegria do humano é a função objetivo, então cada decisão sintática, cada nome de método e cada valor padrão se torna uma pergunta sobre como uma pessoa vai se sentir ao ler e escrever o código, em vez de o quão rápido os bytes vão se mover. Matz tornou o trade-off explícito e honesto: o Ruby gastaria os ciclos da máquina para comprar o conforto do programador. A mesma convicção faz do gosto um sistema estrutural em vez de uma decoração – a experiência da pessoa que faz o trabalho se torna a preocupação que sustenta tudo, em vez de uma reflexão tardia aplicada no final.

Uma única decisão governa tudo o que se segue: projete para os humanos, não para as máquinas. A sintaxe, a cultura e o lema da comunidade derivam dela. O restante deste texto traça como a busca de uma única pessoa pela própria felicidade se endureceu em uma posição de engenharia defensável – e por que “servir o humano” se revela tão rigoroso quanto “servir a máquina”, e não um recuo diante dela.

Contexto

Yukihiro Matsumoto nasceu na província de Osaka, no Japão, em 14 de abril de 1965, e foi criado em Tottori a partir dos quatro anos de idade.³ Ele se descreve como um apaixonado por linguagens – não um linguista, mas um apaixonado por linguagens de programação. Foi um programador autodidata até o fim do ensino médio e formou-se em ciência da informação pela Universidade de Tsukuba, onde trabalhou em um laboratório de pesquisa voltado a linguagens de programação e compiladores.³ O fascínio veio primeiro; o Ruby foi seu resultado final.

Ele batizou o Ruby em fevereiro de 1993 – o nome surgiu em um bate-papo on-line com seu colega Keiju Ishitsuka, antes que qualquer linha de código tivesse sido escrita – e o desenvolveu ao longo dos anos seguintes.¹³ A motivação foi a insatisfação. “Eu realmente queria uma linguagem de script genuinamente orientada a objetos e fácil de usar”, explicou ele. “Procurei uma, mas não consegui encontrar.”⁴ Perl era poderoso, mas, para o seu gosto, não era verdadeiramente orientado a objetos. Python era orientado a objetos, mas, para o seu gosto, não era agradável o suficiente. Então ele construiu a linguagem que ele mesmo queria usar. Lançou a primeira versão pública em 21 de dezembro de 1995.³

O nome foi uma pequena brincadeira. Os dois optaram por Ruby como uma pedra preciosa, um aceno a Perl, a linguagem à qual o Ruby respondia em parte. Uma pérola e depois um rubi: um sucessor nomeado como uma atualização incremental.⁴ Por anos o Ruby foi um fenômeno principalmente japonês, com suas listas de discussão e documentação em japonês. A explosão global veio mais tarde e de fora: David Heinemeier Hansson construiu o Ruby on Rails sobre ele, e o Rails levou o Ruby ao resto do mundo em meados dos anos 2000.⁴ A linguagem que uma única pessoa construiu para a própria felicidade se tornou o substrato das aplicações web de toda uma geração.

O trabalho

O projeto do Ruby: a alegria e o princípio da menor surpresa

A ideia mais citada sobre o Ruby é o “princípio da menor surpresa” – a linguagem deve se comportar da forma como você esperaria, para que você dedique sua atenção ao problema e não à ferramenta. Matz apoia o princípio, mas corrige uma leitura equivocada comum. “O princípio da menor surpresa significa o princípio da minha menor surpresa”, disse ele. “E significa o princípio da menor surpresa depois que você aprende muito bem o Ruby.”⁵

Essa correção resume toda a filosofia em uma única frase. Ele não fez uma enquete com programadores para tirar a média de suas expectativas. Ele projetou a linguagem para minimizar a sua frustração, apostando que uma linguagem que encantasse o próprio autor – um usuário fluente e exigente – encantaria os outros assim que eles atingissem a fluência. “Eu queria minimizar minha frustração durante a programação, então quero minimizar meu esforço ao programar”, disse ele. “Eu mesmo quero me divertir programando.”⁵ O Ruby é uma linguagem pessoal que ganhou escala. Sua consistência não é a consistência de um comitê; é a consistência de um único gosto aplicado sem descanso.

Projetar para os humanos, não para as máquinas

Matz trata o software como um meio para as pessoas, não como um conjunto de instruções para o hardware. “Não subestime o fator humano”, disse ele. “Mesmo que estejamos diante dos computadores, eles são meios. Trabalhamos para o humano, com o humano. A maioria das nossas tarefas, afinal, está relacionada a pessoas.”⁵ Ele leva a ideia além do slogan: a interface, para Matz, é o produto inteiro. “Se o seu sistema tem uma interface ruim, ninguém vai usá-lo. Por isso a interface, ou superfície, do sistema, seja para os usuários, seja para outras máquinas, é muito importante.”²

O corolário é uma recusa em se subordinar às preferências da máquina. Perguntado sobre a relação entre humano e computador, Matz foi direto: “Nós somos os senhores. Elas são as escravas.”⁶ A máquina existe para servir à intenção do programador, e uma linguagem que força o humano a pensar como uma CPU tem a relação invertida. Os blocos do Ruby, seu modelo em que tudo é um objeto, seus nomes de método legíveis – Array#each, Integer#times, String#upcase – todos gastam complexidade de implementação para que a superfície se leia como intenção.

MINASWAN: a cultura como resultado de projeto

O artefato mais incomum do Ruby não é um recurso; é uma norma da comunidade. Matz tem um temperamento famoso pela gentileza e pela paciência, e essa disposição se propagou em um lema: MINASWAN – “Matz é gentil, então nós somos gentis”.⁷ Nos primeiros dias do Ruby, quando as discussões esquentavam nas listas de discussão, membros da comunidade reagiam invocando-o para estabelecer um tom mais caloroso. Espalhou-se até se tornar identidade.⁸

A lição que a maioria dos projetistas de linguagens não percebe é que a cultura também é uma superfície de projeto. Uma linguagem é mais do que sua gramática; é a experiência de fazer uma pergunta e receber uma resposta generosa, de ler uma biblioteca cujo autor se importou que você a entendesse. Matz projetou a sintaxe e, pelo exemplo, também projetou a postura social ao redor dela. Uma linguagem construída para deixar os programadores felizes fez crescer uma comunidade comprometida com a gentileza porque o mesmo valor impulsionava as duas coisas – a comunidade é o princípio da menor surpresa aplicado às pessoas.

mruby: a filosofia em um espaço restrito

Em abril de 2012, Matz tornou o mruby código aberto – uma implementação leve e embutível do Ruby, criada para rodar em lugares onde o Ruby completo é pesado demais: microcontroladores, sistemas embarcados, dispositivos de consumo.⁹ Ela atende a um subconjunto da especificação Ruby ISO/IEC 30170 e é distribuída como um pequeno interpretador com um compilador de bytecode e uma máquina virtual, embutível em C ou C++ da mesma forma que o Lua.¹⁰

O mruby é interessante justamente porque coloca a filosofia à prova sob pressão. Quando você tem kilobytes de RAM e nenhum luxo em matéria de ciclos, “projetar para os humanos” sobrevive? A resposta de Matz foi manter a expressividade do Ruby ao mesmo tempo em que descartava o peso do ambiente de execução – levar a alegria de escrever em Ruby até a camada do firmware, em vez de forçar os desenvolvedores de sistemas embarcados a descer para o C. A aposta centrada no humano se sustentou até no lugar mais hostil a ela.

O método

O método de Matz é a empatia formalizada em uma disciplina de projeto. O movimento recorrente é perguntar não “o que é correto para a máquina?”, mas “o que a pessoa vai sentir?” – e então pagar qualquer custo de implementação que essa resposta exija.

O segundo movimento é a síntese. O Ruby é abertamente derivativo: a pragmática e as expressões regulares do Perl, o modelo de objeto puro e a passagem de mensagens do Smalltalk, a flexibilidade do Lisp, pedaços de Ada e Eiffel.⁴ Matz não inventou um novo paradigma. Ele tomou as melhores ideias das linguagens que admirava e as harmonizou em uma só voz coerente. Poucos projetistas exercem esse gosto: a disciplina de tomar em vez de inventar e a disciplina mais difícil de fazer com que as partes emprestadas se encaixem em vez de colidir. O princípio da menor surpresa é, em parte, uma consistência interna – depois que você aprende um canto do Ruby, o próximo se comporta da maneira que o primeiro ensinou você a esperar.

O terceiro movimento é a honestidade sobre o trade-off. Matz nunca fingiu que o Ruby era a escolha rápida, e disse isso claramente, em vez de proclamar calor enquanto otimizava silenciosamente para os testes de desempenho. O custo é real e concreto: como tudo no Ruby é um objeto, até um inteiro é um objeto de primeira classe, e a aritmética acontece enviando a ele a mensagem +, em vez de executar uma instrução de máquina bruta.¹⁴ A conveniência de 5.times ou (1..n).map – tratar números como objetos com os quais você pode conversar – é paga com uma sobrecarga de despacho e alocação na qual um int do C nunca incorre. Matz escolheu a superfície legível e deixou o ambiente de execução absorver a conta, que é exatamente a aposta enunciada com clareza.

Cadeia de influência

Quem o moldou

Larry Wall e Perl. O Ruby herdou a sensibilidade pragmática e voltada a resolver problemas do Perl, além de seu DNA de expressões regulares. O próprio Matz apresentou o Ruby como uma resposta ao Perl – preservando o que era prático e corrigindo o que ele via como sua falta de verdadeira orientação a objetos. (Influência direta)⁴

Smalltalk. A convicção de que tudo é um objeto – inteiros, classes, nil – e de que a computação acontece pelo envio de mensagens veio do Smalltalk. É a herança estrutural mais profunda no modelo de objetos do Ruby. (Influência direta)⁴

Lisp, Ada e Eiffel. O Lisp contribuiu com flexibilidade e com a noção de que a linguagem deveria se curvar ao programador; Ada e Eiffel contribuíram com outros pedaços concretos de sintaxe e de projeto. O Ruby é a síntese. (Influências formativas)⁴

Quem ele moldou

A web da era Rails. O Ruby on Rails fez do Ruby a linguagem padrão de uma geração de startups e deu à “felicidade do desenvolvedor” um argumento comercial: programadores mais felizes entregavam mais rápido, de modo que a linguagem centrada no humano vencia projetos pela economia, e não apenas pela sensação.

A expectativa básica de uma geração. Depois do Ruby, os programadores passaram a esperar que as linguagens fossem agradáveis – que se lessem como prosa, que perdoassem, que encantassem. Essa expectativa redefiniu o nível que as linguagens mais novas tinham de superar para serem levadas a sério.

Crystal e Elixir. O Crystal toma emprestada a sintaxe do Ruby quase por inteiro, ao mesmo tempo em que compila para código nativo por meio de um backend LLVM.¹¹ O Elixir, a linguagem funcional de José Valim para a BEAM, leva a sensibilidade ergonômica do Ruby ao mundo concorrente; Valim cita sua “experiência anterior em Ruby” para muitas de suas construções emprestadas.¹² A estética do Ruby sobreviveu ao seu ambiente de execução. (Linhagem estilística)

O fio condutor

Eis a tensão produtiva. Matz otimiza para a felicidade humana e é honesto ao admitir que gasta os ciclos da máquina para isso. O outro polo da engenharia otimiza para a máquina – John Carmack contando ciclos até o quadro caber no orçamento, Linus Torvalds defendendo o “bom gosto” como a estrutura de dados que faz o caso especial desaparecer. Carmack e Torvalds perguntam o que o hardware merece; Matz pergunta o que o humano merece. Nenhum dos polos está errado. Os melhores sistemas vivem na discussão entre eles – expressivos o bastante para que uma pessoa goste de escrevê-los, disciplinados o bastante para que a máquina não seja insultada. Matz é a prova de que “projetar para o humano” é uma posição de engenharia legítima e rigorosa, e não um mero conforto. (Ponte da série)

O que eu tiro disso

Eu construo ferramentas para desenvolvedores e infraestruturas de orquestração para agentes de IA, e a aposta de Matz é a que eu continuo fazendo: o humano no laço é o público que importa. Um agente de programação, assim como uma linguagem de programação, é uma interface entre a intenção de uma pessoa e a execução de uma máquina. Se ele te surpreende, briga com você ou te força a pensar como a máquina em vez de pensar no problema, ele fracassou – por mais engenhosas que sejam suas entranhas internas. Todo o sentido dessas entranhas internas é tornar a experiência legível para a pessoa. É também por isso que mantenho a superfície honesta e a pilha enxuta – o manifesto sem build é o princípio da menor surpresa aplicado a uma cadeia de ferramentas. E assim como Matz se recusava a fingir que o Ruby era rápido, eu prefiro ser honesto sobre o trade-off a escondê-lo: a qualidade é a única variável, e a felicidade do programador faz parte da qualidade, não se opõe a ela.

Perguntas frequentes

Qual é a filosofia de engenharia de Yukihiro Matsumoto?

Matz projeta linguagens de programação para a felicidade e a produtividade do humano em vez da eficiência da máquina. Seu propósito declarado: “O Ruby foi projetado para deixar os programadores felizes.”¹ Ele trata a experiência do programador – legibilidade, alegria, menor surpresa – como a restrição de projeto primordial e aceita um ambiente de execução mais lento como o preço honesto de servi-la. “As máquinas deveriam servir aos seres humanos”, disse ele. “Deixe as máquinas servirem você.”²

O que é o princípio da menor surpresa no Ruby?

É a ideia de que a linguagem deve se comportar da forma como um usuário experiente espera, minimizando o atrito. Matz esclarece que isso significa “o princípio da minha menor surpresa” – ele projetou o Ruby para minimizar a própria frustração como usuário fluente, e “o princípio da menor surpresa depois que você aprende muito bem o Ruby”, e não a surpresa de um iniciante no primeiro dia.⁵

O que significa MINASWAN?

MINASWAN significa “Matz é gentil, então nós somos gentis” – um lema da comunidade Ruby que nasceu do temperamento gentil e paciente de Matsumoto. Os primeiros rubyistas o invocavam para estabelecer um tom generoso nas listas de discussão, e ele se tornou parte da identidade cultural do Ruby.⁷⁸ Ele reflete a ideia de que a comunidade de uma linguagem é, ela própria, uma superfície de projeto.

Quais linguagens influenciaram o Ruby?

O Ruby é uma síntese deliberada. Ele extraiu a sensibilidade pragmática e as expressões regulares do Perl, o modelo de objeto puro e a passagem de mensagens do Smalltalk, a flexibilidade do Lisp e elementos de Ada e Eiffel. Matz combinou os recursos que admirava em uma única linguagem coerente, em vez de inventar um novo paradigma.⁴

Sources