Os programadores têm orgulho de si mesmos por um bom motivo. Ninguém mais tem o poder de acessar um banco de dados e mudar a realidade. Quanto mais o mundo confia nos computadores para definir como o mundo funciona, mais poderosos os programadores se tornam.
Infelizmente, o orgulho termina com a queda. O poder que compartilhamos é real, mas está longe de ser absoluto, afinal, não existe um código perfeito. Às vezes cruzamos os dedos porque os computadores cometem erros. As máquinas também podem ser falíveis, o que todos sabemos por muita experiência em primeira mão.
Obviamente, muitos problemas decorrem de suposições que os programadores fazem e que simplesmente não estão corretas. Como Mark Twain disse: “Não é o que você não sabe que causa problemas. É o que você tem certeza de que não é verdade.”
Aqui estão algumas crenças falsas que nós, programadores, frequentemente fingimos ser verdadeiras.
Batemos nas mesas depois do trabalho. Escrevemos longos relatórios. Prometemos ao chefe que, desta vez, uma nova linguagem mudará tudo e um software maravilhoso fluirá dos teclados que todo o projeto será realizado um mês antes do prazo. No final, porém, colamos os dados nas variáveis e testamos alguma lógica.
Os programadores veem a estrutura em seu código e sonham em acabar com qualquer ineficiência dele. Então eles imaginam elaborados castelos chamados “estruturas”, “andaimes”, “plataformas” ou “arquiteturas” e mexem com eles até oferecerem o suporte correto ao problema atual, para que tudo possa ser escrito em poucas palavras
No final, tudo isso é artifício. Licor estrutural que entorpece a dor da codificação da vida até que ela desapareça. Os computadores são construídos a partir de transistores e nenhuma quantidade inteligente de teorias pode ocultar o fato de que todo o nosso código se resume a um pouco de silício, escolhendo ir para a esquerda ou para a direita.
Talvez você tenha criado seu último aplicativo Web no React porque estava descontente com as páginas construídas no Vue. Ou talvez você reescreva tudo em algo menor, mais novo ou mais legal, como Marko, Glimmer ou Ghost? O programador está sempre procurando a estrutura perfeita, mas essa estrutura, como o fim do arco-íris, nunca aparece.
Ralph Waldo Emerson antecipou a vida do programador quando escreveu “Autossuficiência”, em 1841. “A sociedade nunca avança”, observou ele falando, claro, do curso das estruturas de programação. “Ele recua tão rápido de um lado quanto ganha do outro. Seu progresso é aparente apenas como os trabalhadores de uma esteira … Pois tudo o que é dado é tomado.”
E assim vemos repetidamente os desenvolvedores criarem novas estruturas para corrigir os problemas das estruturas antigas, introduzindo novas dificuldades ao longo do caminho. Se uma estrutura adicionar renderização do lado do servidor, ela atolará o servidor. Mas se tudo é deixado para os clientes, eles começam a ficar mais lentos. Cada novo recurso é uma troca entre tempo, código e largura de banda.
Descobrir como lidar com ponteiros nulos é um grande problema para o design de linguagem moderna. Às vezes, acho que metade do código Java que escrevo está verificando se um ponteiro é nulo.
A maneira inteligente como algumas linguagens usam um ponto de interrogação para verificar a nulidade ajuda, mas não elimina o problema. Várias linguagens modernas tentaram ultrapassar essa barreira, eliminando completamente o nulo. Se toda variável precisar ser inicializada, nunca poderá haver um nulo. Não há mais testes nulos. Problema resolvido. Hora do almoço.
A alegria dessa descoberta desaparece em várias linhas de um novo código, porque as estruturas de dados geralmente apresentam falhas sem informações. As pessoas deixam linhas em um formulário em branco. Às vezes, os dados ainda não estão disponíveis.
Se o elemento for uma sequência, você pode testar se o comprimento é zero. Se você trabalha bastante com as definições de tipo, geralmente pode criar algo logicamente correto para determinado problema, pelo menos até que alguém altere as especificações. Depois de fazer isso algumas vezes, você começa a desejar uma palavra simples que significa uma variável vazia.
A codificação de gênero e a escolha de pronomes é um grande campo minado para os programadores. Os computadores negociam listas fixas e menus bem definidos, e os seres humanos continuam mudando as regras.
Os cientistas da computação nunca resolvem realmente os problemas, apenas adicionam outra camada de indireção, neste caso, um ponteiro para um campo vazio onde a pessoa pode preencher sua escolha. Em seguida, algum palhaço vem e escolhe “sua majestade” como um pronome, o que faz com que algumas crianças riam e outros se sintam ofendidos. Mas voltar para uma lista fixa significa excluir algumas opções.
Esse modo de falha de design aparece repetidamente. Se você forçar todos a terem um primeiro nome e um sobrenome, alguns terão apenas um nome. Ou então, alguém que não quer ser conhecido por uma sequência de caracteres Unicode. E se alguém escolhe um novo emoji para o seu nome e o emoji não faz parte da lista final? Não importa o quanto você tente ensinar ao computador como ser flexível e aceitar caprichos e loucuras humanas, os humanos surgem com novas bombas lógicas que detonam o código.
Há um comitê sério que se reúne com frequência tentando decidir quais emojis devem ser incluídos na lista definitiva de glifos que definem a comunicação humana. Eles também deixam de lado certos emoji, negando efetivamente os sentimentos de alguém.
A explosão de memes mostra quão fútil esse processo pode ser. Se o mundo considera os emoticons muito limitadores, incentivando-os a misturar texto com fotos de ícones culturais, como uma lista de emojis pode ser adequada?
Depois, há o problema das fontes emoji. O que parece fofo em uma fonte pode parecer covarde e suspeito em outra. Você pode escolher o emoji fofo, mas seu telefone enviará os bytes Unicode para seu amigo que tem um telefone de marca diferente e uma fonte que renderizará os bytes com a versão desagradável do emoji.
Uma das maneiras que os desenvolvedores criam é colocar um campo de texto e permitir que os humanos o preencham com o que quiserem. As seções de comentários em aberto são feitas para humanos e raramente são interpretadas por algoritmos, portanto não fazem parte do problema.
O problema real reside em campos estruturados com texto. Quando o meu GPS quer que eu escolha uma estrada que leva o nome de um santo, ele me diz para “virar para a Street Johns Road”. Os nomes das estradas com apóstrofos também fazem dar uma volta. É comum ver “St. John’s Road” soletrado como “Saint Johns”,“St. Johns”, “Saint John’s” e até da forma plural:“ Saint Johns”. Os Correios dos EUA têm uma lista de endereços sem caracteres extras e mantém um algoritmo elaborado para converter qualquer endereço aleatório na forma canônica.
Parece que lembrar os dados deve ser algo que um computador possa fazer. Devemos ser capazes de recuperar os bits, mesmo que sejam preenchidos com muitas inconsistências lógicas, estilísticas, ortográficas, numéricas ou outras. Infelizmente, não podemos nem fazer isso.
Sempre que peço ao meu Mac que verifique o sistema de arquivos e corrija os erros, ele invariavelmente me informa sobre uma longa lista de “erros de permissão” que ele repara para mim. Como o software obteve permissão para alterar as permissões de acesso aos meus arquivos se eu não dei permissão para fazê-lo? Não me pergunte.
Esses são apenas dois exemplos de como os sistemas de arquivos não respeitam o pacto entre o usuário (a pessoa que fornece a eletricidade) e a máquina (um carente desesperado por eletricidade). Qualquer programador lhe dirá que existem centenas de outros exemplos de situações em que os arquivos não contêm o que esperamos que eles contenham. As empresas de banco de dados recebem muito dinheiro para garantir que os dados possam ser gravados de maneira consistente. Mesmo assim, algo dá errado e os consultores recebem ainda mais dinheiro para consertar o problema.
Gostamos de acreditar que nossas instruções estão dizendo ao computador, mas somos presos impotentes pegando o que as máquinas nos dão. O sistema operacional está no comando e pode ou não permitir que nosso código faça o que nós desejamos.
OK, e se compilarmos o kernel Linux do zero e instalarmos apenas o código que examinamos? Certamente estaremos no controle então. Não. O BIOS possui o primeiro controle sobre o computador e pode fazer clandestinamente alterações sutis e não tão sutis no seu código. Se você estiver executando na nuvem, o hipervisor terá ainda mais poder.
OK, e se substituirmos o BIOS por nosso próprio gerenciador de inicialização personalizado? Você está chegando mais perto, mas ainda há muito firmware enterrado dentro da sua máquina. Sua unidade de disco, placa de rede e placa de vídeo podem pensar por si mesmas e ouvem primeiro o firmware.
Não apenas isso, mas sua CPU pode ter um “Modo Deus Escondido”, que permite que outra pessoa assuma o comando. E esses são apenas os problemas com os chips oficiais que deveriam estar na sua caixa. Alguém pode ter adicionado um chip extra com uma agenda oculta.
Até esse pequeno pen drive possui um processador embutido com seu próprio código, tomando suas próprias decisões. Todos esses processadores incorporados foram pegos abrigando malware. O fato triste é que nenhum dos transistores nessa caixa embaixo da sua mesa informa você sobre isso.
