Problemas e soluções

Na última sexta-feira, 30/06/2017, eu vi… Eu vi uma luz no fim do túnel. Chamava-se TCC.

Mas não o TCC famoso, o famigerado Trabalho de Conclusão de Curso; foi o Tiny C Compiler. Pela primeira vez na vida, eu vi um compilador para a linguagem C pequeno, rápido e leve. Ele ainda tem a funcionalidade de executar código-fonte diretamente, como um interpretador de scripts, algo bem interessante.

Outro ponto extremamente positivo é que ele funciona no Windows. Aliás, ele simplesmente funciona: basta baixar o zip, extrair, rodar tcc.exe e pronto. Nada de MinGW, MSYS, cygwin e outras tranqueiras complicadas de instalar e configurar. O Windows é um SO explicitamente negligenciado por boa parte da comunidade de desenvolvimento de software. Dizem que a solução é criar máquina virtual – e eu sugiro VirtualBox com Linux Mint XFCE. É, após baixar alguns gigabytes e instalar tudo, realmente funciona bem.

Já o TCC tem apenas 389KB zipado e 1,53MB extraído. Como eu disse, nunca tinha visto um compilador tão pequeno. Ele também é quase 9 vezes mais rápido do que o GCC e produz código de saída super pequeno, também. Um ola-mundo.exe gerado pelo Visual Studio tem 8,5KB. Já o mesmo programa compilado com o TCC tem 1,5KB – mesmo tamanho da versão em Assembly (testei usando o MASM32 SDK).

Também experimentei fazer um Olá, Mundo em Go e deu 1,6MB. Em Rust, 3,6MB. Em JavaScript, usando NodeJS e a plataforma de distribuição Electron para gerar um executável distribuível: 127MB.

Pois é… Estamos vivendo a era do hardware barato. E de seu desperdício.

• Para que usar apenas 1,5KB se a gente pode fazer em 1,6MB, 3,6MB ou 127MB e o hardware aguenta?
• Por que uma tarefa rápida como compilar um programa trivial deveria rodar em 5 milissegundos se a gente pode fazê-lo precisar de 90?
• Para que armazenar pequenos arquivos localmente se a gente pode criar bancos de dados NoSQL em nuvem a torto e a direito e gastar alguns Mbps de conexão de internet com isso?

Fera mesmo eram os programadores de jogos dos consoles antigos… Aqueles, sim, tiravam leite de pedra. Não havia outra opção: hardware extremamente limitado, programação só em Assembly. Ou fazia assim, ou não fazia.

O Atari, por exemplo, tinha 128 bytes de memória. Não são megabytes nem kilobytes, são BYTES! E dava certo. Não sei como, mas dava! Provavelmente, cada bit era muito bem aproveitado.

Já a gente aqui, em 2017, vai seguindo a vida, gastando mais de 1MB e mais de 270 milhões de ciclos de CPU apenas para dizer oi para o mundo… E achando isso normal.

Isso NÃO é normal. Isso está muito errado. As pessoas estão muito longe de conhecer o verdadeiro poder de suas máquinas. Estamos apenas comendo migalhas perto do que realmente poderíamos fazer.

Ao questionar esse assunto, às vezes a explicação que vem como resposta é que precisamos resolver os problemas grandes. E, que, para esses problemas, as ferramentas que temos funcionam bem. Ou seja, o importante é que o GCC compile código gigante em um tempo longo (em vez de muito longo); o importante é que um programa gigante em Go ou Rust fique com centenas de megabytes (em vez de vários gigabytes). Em outras palavras: “temos que sacrificar as pequenas aplicações em prol das grandes aplicações, que são as que realmente importam”. Engraçado… Onde é que já ouvimos esse discurso antes?

Eu tenho uma visão diferente. Eu acredito que todos podem ser bem atendidos. Não existe essa tal “decisão difícil” entre os grandes e os pequenos problemas. O que existe é para onde queremos direcionar nossos esforços. Os grandes problemas já estão sendo resolvidos por gente capacitada. E os pequenos? Também estão? Bom, o TCC está aí para nos ajudar a mudar esse cenário.

Vejo um futuro em que, tanto quanto já temos acesso a programas grandes e pesados para resolver problemas grandes e pesados, teremos acesso a programas pequenos e rápidos para resolver problemas pequenos e rápidos. E, assim, todos serão mais bem atendidos nesse mundão de Deus, cada um dentro da sua necessidade.