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.
1. Linguagens de programação são diferentes
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.
2. Estruturas estão melhorando
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.
3. Nulo é aceitável
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.
4. Computadores podem entender escolhas humanas
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.
5. Unicode significa comunicação universal
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.
