Rodrigo Kumpera Weblog

A parte que mais odeio no C é ser minha melhor opção. Sim, sério, para aquilo que faço hoje em dia, realmente não existe linguagem melhor. E isso de deixa maluco pois se trata de uma linguagem anacrônica, cheia de problemas enormes que aparentemente toda comunidade de PLR esqueceu de tentar resolver.

Para quem já programou em C, ou mesmo C++, e em uma linguagem de alto nível tais quais C#, Haskell ou LISP sabe o tamanho do sofrimento que é trabalhar com uma ferramenta tão primitiva. Aos incautos não estou me referindo nem me referindo as vantagens óbvias dessas linguagens como gerenciamento automático de lixo, um sistema de tipos rico ou tipagem ou dinâmica[1].

Quando se programa próximo do metal ter um controle e visão muito clara daquilo que é gerado é muito importante, então coisas como verificações inseridas pelo compilador, não ter controle fino sobre a representação dos dados ou simplesmente não podem burlar o sistema de tipos inviabilizam o uso de uma linguagem – por mais estranho que pareça.

Entretanto usar destes argumentos para defender as relíquias que são C e C++ é temerário. Ambas linguagens foram construídas sob as bases do que era avançado em termos de compiladores nos anos 70 e para a capacidade de processamos do começo dos anos 90. Muita coisa mudou de lá para cá, menos o fato de C++ demorar horrores para compilar.

A primeira grande falha do C, e uma que chama muito a atenção, é o sistema de módulos e compilação separada. Que realmente não existe. Em ambas as linguagens se usa inclusão textual de cabeçalhos com declarações supostamente exportadas por outros módulos do sistema e pronto. O problema disso é óbvio se já tiver trabalhado em projetos grandes. O tempo de compilação individual aumenta sem razão aparente, conflitos com o nome de símbolos ocorrem e, em geral, atrapalham a vida de todos.

Continuando com a questão de processamento de texto. Macros em C provavelmente são o recurso mais importante da linguagem, aquele que a tira da lista de inúteis. É bem freqüente encontrar uma infinidade de truques feitos usando macros para sanar a falta de expressividade da linguagem. Porém tão comum quanto é encontrar gente frustada com a dificuldade de depurar um sistema rico em macros. Ao mesmo tempo, programando um dia com LISP qualquer um enxerga que um grande sistema de macros faz qualquer linguagem medíocre ir muito longe.

Por fim, minha última reclamação é devido ao fato de estar em 2009 e ainda ser obrigado a usar uma linguagem sem inferência de tipos. O artigo do Robin Milner tem quase 31 anos e ainda assim sou obrigado a pagear o compilador com aquilo que ele consegue descobrir sozinho. Inferência de tipos é um recurso ainda mais importante quando falamos de sistemas de tipos mais ricos.

Ainda assim, por algum motivo que me escapa, não existe um substituto usável para C ou C++. Talvez seja pelo fato de tal linguagem não possuir muito acadêmico em termos de papers e PHDs, ou que a enorme parte da comunidade de programadores destas linguagens é cega por achar que são o último biscoito do pacote.

[1]Ou latente, caso tenha um fetiche pelo Fowler.