Ensaio Sobre Tesouras de Plástico sem Ponta

Pode parecer estranho o título deste post, mas na verdade ele não é apenas sobre aquelas tesouras de criança, mas sobre segurança e como ela afeta nossa vida. Mas, para isto, é melhor começar com uma história simples de diferença de cultura:

Na pré-escola, professores e professoras sempre insistiam para usarmos “tesouras sem ponta”, que normalmente significava aquelas tesouras minúsculas com cabo de plástico e que não cortavam nem uma folha de papel direito. Quando você é criança, porém, tudo é divertido (até o fato da tesoura não cortar), e no fim você ou pede emprestada uma tesoura de outra criança, que ainda não perdeu o corte, ou acaba cortando na mão, quando o corte for reto.

Agora, vamos para outra cultura: Japão. Em animes, você normalmente vê crianças e adolescentes com aulas de culinária, prendas domésticas, ou semelhantes. Nestas aulas, os adultos supervisionam, mas são os alunos quem realmente acendem o fogo, usam facas pontudas, etc. A idéia, até onde eu sei, é ensinar desde pequeno como usar uma ferramenta que pode potencialmente ser perigosa, como ensinar a ter cautela.

Imagine, agora, você com trinta anos, um cabeleireiro, estilista, artista plástico, sendo obrigado a usar uma tesoura de plástico sem ponta? Um cozinheiro que precisa de “provadores”, “acendedores de fogão”, porque, ora, no primeiro caso ele pode queimar a língua, no segundo, ele pode explodir o fogão. Ou então, usando o fogão X, porque ele tem um acendedor automático de bocas, e assa um bolo em alguns dias, afinal, com um fogo BEEEM baixo, a chance de queimar o bolo é bem menor… certo? O que isso nos diz? Na minha opinião, tudo se resume a apenas uma palavra:

Confiança.

Quando você vai para um restaurante, você confia que o cozinheiro vai trazer um prato gostoso, que não te faça mal. Se você chegar num restaurante, e a comida te fizer mal, você vai provavelmente fazer uma denúncia no máximo, ou não almoçar mais lá, no mínimo. E, bom, mesmo que o cozinheiro seja só inexperiente, ele vai ter que aprender a cozinhar melhor, e o restaurante vai ter que aprender a contratar pessoas mais aptas. Isso é o que mantém o mercado rodando.

Já na informática…

O problema, ao meu ver, do desenvolvimento de sistemas, especificamente, é que a maioria das empresas simplesmente não confia no bom trabalho de seus funcionários. Se um framework tem bugs, a empresa precisa de alguém pra ligar e reclamar, exigir um patch, ao invés de simplesmente pedir para o programador: “contorne o bug do framework, por favor, ou resolva você mesmo?”. Numa linguagem dinâmica, especificamente, a empresa não confia que seus programadores converterão os tipos para os formatos válidos, que eles não vão levar em consideração as peculiaridades de cada linguagem. A empresa simplesmente necessita de uma “tesoura de plástico sem ponta”, porque tem medo de que seus programadores se cortem ou, pior, cortem erradamente o produto que eles querem produzir. Isso cai em duas frases interessantes:

• “Always use sharp and dangerous toys” (Dr. Nic)
• “If you design a system for idiots, only idiots will use it” (Linus Torvalds)

Logo, se a linguagem de programação é montada sobre a premissa de que os programadores escrevem códigos inseguros e passíveis de falha, obviamente a grande maioria dos programadores daquela linguagem se encaixarão naquele perfil. Para outros, a linguagem simplesmente é uma série de limitações que, na prática, mais atrapalham do que auxiliam.

Além disso… bons programadores tem que se atualizar sempre. Ótimos programadores, sempre estão querendo aprender outra linguagem. Quanto mais linguagens você conhece, mais você aprende conceitos, tem idéias, e aí, mais o seu mundo atual vai diminuindo: de repente, a linguagem que tenta impedir você de fazer uma besteira torna-se restritiva demais, como uma mãe autoritária demais. Todo adolescente quer que a mãe pare de irritá-lo com preocupações e o deixe ser livre, porque nós, programadores, não fazemos o mesmo?

O fato é que o mercado, no fim, estimula ruins programadores. As faculdades, então, formam para o mercado ruins programadores. Coding Dojo, métodos ágeis, Ruby e Python ainda são vistas como apenas “scripting languages”, não como verdadeiras linguagens de programação. Pensar em escrever, como trabalho acadêmico, um interpretador/compilador em Ruby provavelmente atrairá risos e escárnios, e ignora-se que o Rubinius faz exatamente isto. Repetimos os erros antigos, e mantemos linguagens ruins, cujas alterações na própria linguagem demoram anos para serem discutidas, aprovadas, que dirá implementadas, apenas porque “ela é mais segura”, ou “há uma empresa por trás dela”.

Basta dizer: toda linguagem possui uma filosofia por trás dela. É importante entender isso. Eu, particularmente, não gosto de pensar que eu e meus colegas programadores são incompetentes que precisam de mecanismos de segurança o tempo todo. Ao mesmo tempo, eu gosto de ter mais de uma maneira de resolver o mesmo problema, e não tentar encaixar todos os problemas em “sistemas que usam bancos de dados relacionais, nos quais todos os problemas devem se encaixar em um objeto”. Gosto de ver outras oportunidades, como abstrair um conceito em forma de Hash, serializar algo em um arquivo YML, ou gravar meus dados estão em uma base de dados orientada a documentos, ou até mesmo coisas que parecem absurdas, como montar uma lista de perguntas que virará uma página na internet usando a própria sintaxe da linguagem, usando uma Domain Specific Language.

Na programação, o céu é o limite. Não uma linguagem, não um framework-e esta é a parte importante. Uma linguagem de programação, um framework, não podem ter a responsabilidade de te determinar nada.

Eu sonho com o dia em que eu terei uma linguagem de programação altamente flexível, na qual até a sintaxe da linguagem poderia ser alterada em tempo de execução, tipagem estática ou dinâmica, em resumo, mudar praticamente qualquer aspecto da linguagem. Espero que Rubinius atenda, pelo menos, metade destes aspectos.