Por que o kernel Linux usa C apenas e não C++?
Por vários motivos, mas tem um adicional do autor do kernel detestar C++:
“C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.”[1]
Fazer um sistema operacional te faz cair em situações onde você se sente programando a própria cadeira que irá sentar para continuar o desenvolvimento do treco. Então uma linguagem que simplifique ao invés de complicar com premissas de segurança e consistência em design-time bobas para desenvolvedores que dominam as bases do dialeto C é essencial. Dentro do dialeto C, não existe melhor e mais simples que C.
A sua simplicidade garante interoperabilidade com outros sistemas e subsistemas prévios. A linguagem C foi escrita pensando em facilitar as coisas em especial abstrair detalhes de arquitetura. Você hoje que usa um sizeof e o acha ordinário, não entende o mundo de coisas que se descortinaram a partir de uma primitiva tão simples. Elegância e concisão não é um paquiderme vestido em neon que você vai notar mesmo estando distraído em seus dilemas de programação diários, mas estão lá para os olhos certos.
Ao passo que a maioria das outras linguagens que chupam do dialeto C, partem de premissas bobas do tipo:
- Aritmética de ponteiro é ruim, vamos abolir ponteiro; [Se você definitivamente não entende isso e quer programar deve realmente assumir sua limitação e mudar de linguagem…]
- Funções da string.h são perigosas, vamos criar wrappers calóricos e abominar qualquer um que se garanta saudavelmente sem eles; [Pois é, hoje em dia, em terra de cego quem tem olho sofre bullying…]
- Funções soltas são ruins, vamos criar um açúcar sintático que ponha ponteiros para essas funções em structs e em adicional vamos pôr a peste da herança múltipla. Programa bom precisa, antes de ser montado como um executável ou lib, estar todo lotado de Classes, objetos, interfaces, fadas, duendes e doninhas; [“O fascinio é fascinante e deixar gente ignorante fascinada…” li num caminhão esses dias…]
- C não tem valor default para argumentos de função, logo vamos pôr isso de modo que faça todo programa C antes escrito ficar ineficiente ao ponto de todo programador C se render a tal recurso indispensável; [Sério?! Programadores C em geral não se ocupam pensando no script, eles se ocupam pensando no Assembly que um script gera para resolver o problema… Eles têm plena consciência que a cpu não entende linguagem de alto nível para funcionar…]
- C não tem o recurso de adicionar entropia às assinaturas de suas funções via recursos como sobrecarga, templates, etc; [Que bom!]
- Macro é ruim, vamos baní-las. Se a pessoa quiser garantir tempo de execução de macro usa um açúcar sintático para burocraticamente, humildemente pedir isso para o compilador e se ele quiser, ele põe o trecho com execução local; [“Fom, fom, fom, fom, fom, fom, fom, foooom” como diria a professora do Charlie Brown…]
- O programador não deve ter que pensar em assembly, linkedição, otimização. Ele não precisa ser versado nessas coisas para fazer sistemas de padaria; [Pois é… O problema aqui é assumir o mundo como uma grande padaria…]
- Castear “na mão” coisas é inseguro em sistemas onde ninguém entende o que está fazendo e acontecendo; [Leia-se: para eximir que cheguemos à conclusão que tudo deveria ser reescrito ou pelo menos estudado por quem se mete escrever, vamos dotar o compilador de verificar isso por nós]
- Vamos silenciosamente compilar código em C para quem precisar realmente dos recursos que nossa linguagem só complicaria com suas intermináveis burocracias; [Se eu posso falar com Deus porque vou rezar para o santo?]
Esse drama muita gente entende, mas poucos têm moral de assumir:
A linguagem C já tem um mercado absolutamente consolidado e não precisa ficar soltando novo standard atrás de novo standard para não ficar para trás em relação a essas linguagens finais modernas. Tipo um patético:
“- Oi! Eu estou aqui viu? Fashion, hipster e modernosa…”.
Se há uma coisa que detesto na comunidade C++ são essas polícias de sintaxe e padrões querendo te forçar usar coisas, nesse vídeo você tem um exemplo ótimo dessa horda chatonilda:
C é concisa. Essa concisão já parte de seu léxico. Mesmo concisa é poderosa o suficiente para fazer praticamente tudo. Quando digo tudo, não é ficar dando cambalhota sintática, é matar no peito e resolver. A medida de limitação costuma ser o piloto mesmo. Chegar à conclusão do assembly que um statement gera é bem mais simples em C.
Para mim um programa em C bem escrito tem ares de haicai, por sua depuração já intrínseca. Por isso que eu gosto de dizer que o Dennis Ritchie é o Bashô da computação.
Nisso, a resposta mais depurada para a pergunta implícita “por que não reescrever um kernel C em C++”, para uma pessoa que se vira bem em linguagem C seria:
“Para quê?”
Se retirando toda a complicação desnecessária adicionada pelo C++ ficaríamos com um conciso código C…
A ironia implícita em C++ é que no final das contas, depurando-se o nome ainda se trata de C, pois para já ser o que prega via como se chama, deveria mesmo ser ++C. Hahaha!!!
PERGUNTAS E RESPOSTAS:
Luan Sobreira em 2020:
C++ e Objective C aceitam todas as funcionalidade do C, além de implementarem a segurança da orientação a objetos, correto? Então eu não entendi o que seria perdido ao migrar para o C++.
Rafael Santiago (autor do post):
Você já tentou escrever um kernel em C++? Tenta começar, sem tutorial. Você não tem STL, beleza? Mas claro, não vale apenas usar a porção C do C++, você precisa orientar o treco à objetos. Vai só no conceito de OS e seu conhecimento na linguagem e manuais técnicos (inclusive da linguagem e do compilador). Tenta fazer a mesma coisa em C. Vai acabar percebendo que é mais fácil e no final das contas vai dar num assembly quase parecido. A diferença é que num deles você caminhou normalmente vestido casualmente, enquanto no outro foi inutilmente se movendo para frente via saltos carpados vestindo um fraque elegantíssimo mas um pouco desconfortável para a tarefa. A maioria desses conceitos de “segurança” preconizados em aulas de programação de sistemas usuários, se aplicam muito bem em coisas finais. O conceito de segurança de um sistema operacional vai muito além de não deixar em compile-time o programador fazer certas coisas, casting e outras coisas. Se mesmo assim você quiser isso, pode habilitar tratando warning como erro, o FreeBSD quebra a compilação até com uma variável não utilizada (caso queira mantê-la assim mesmo, precisa prefixá-la com “__unused”), então o pedantismo que muita gente gosta no C++ e até por isso o julga melhor e mais “seguro”, pode ser posto em prática em C também. Sobre encapsulamento, proteger dados contra escrita e tal, você faz mesmo sem classes, modificadores de acesso, etc. Mesmo assim é uma coisa boba, pois mesmo dados do OS em uma página em read-only em espaço kernel, podem ser alterados se a pessoa souber o que está fazendo. Programação de sistema é mais voltada para arquitetura, hardware e quando software, acaba se tratando de coisas bastante técnicas e essas pessoas não precisam das rodinhas que os apaixonados por OO adoram usar para vender o peixe do paradigma, você precisa considerar que gente que escreve sistema operacional sabe bem mais do que a média, nisso acabam conseguindo fazer mais com menos. Você pode dizer, olha o sistema operacional X+++, Y+++++ em C++ que estão fazendo ali na garagem Beta, Gama. Fazer você consegue, mas eles são meio desajeitados e toda aquela OO é prolixamente verborrágica quando comparada com um kernel em C, convenhamos. OpenBSD é considerado um dos kernels mais seguros pelos especialistas, é escrito num C bem direto. Certas ideias que aprendemos programando sistemas finais acabam caindo por terra quando você evolui para baixo – mesmo – da pilha. São mundos bem diferentes. Por isso que eu acho essa história de fullstack meio furada. Fullstack para mim é um profissional que sabe programar de kernels famosos ou um novo kernel até uma planilha de excel. Arriscaria dizer que existem programadores de sistema geniais que não devem saber nada de HTML, de novo, são mundos muito diferentes e com prioridades e interesses completamente diferentes, você não pode chegar com uma ideia totalmente comercial e final e querer resolver um problema que para os caras nem problema é, eles fazem assim porque gostam e podem fazer assim.
Apesar de Usar OO entendo a visão e achei super importante. De qualquer forma vale o compartilhamento. Links das fontes do texto:
https://pt.quora.com/Por-que-o-kernel-Linux-usa-C-apenas-e-n%C3%A3o-C