A linguagem de programação C (problemas da linguagem C)
(hut.mearie.org)-
Problemas de memória: não conta com a ajuda de ferramentas como GC, análise estática etc.
-
Comportamento indefinido: passou a ser usada principalmente em ambientes de baixo nível, com grande demanda por otimização, e para otimizar o comportamento indefinido aumentou. Não consegue conciliar desempenho de baixo nível e portabilidade.
-
Inadequada para programação em grande escala: ausência de módulos e de gerenciador de pacotes. Até recursos amplamente usados, como
#pragma once, não têm padronização.
7 comentários
Obrigado por compartilhar um bom texto. No entanto, deixo um comentário porque há um ponto pequeno que me causou estranheza.
Sou o autor do texto (haha...). Como o site ainda está em soft launch e estou publicando textos de forma experimental, peço a compreensão de que o conteúdo pode ser revisado continuamente. Também faço o acompanhamento diretamente, mas aceito opiniões enviadas por e-mail, então fique à vontade para considerar isso.
Como você mencionou, o vcpkg atualmente parece ser o gerenciador de pacotes mais promissor, e o Conan também é, na verdade, um projeto que existe há bastante tempo (não muito distante do momento em que o texto original foi escrito). Mas a principal característica desses projetos é que eles são meta-build systems que não possuem um build system próprio. (Considerando que o próprio CMake, que é o principal alvo de suporte, também é um meta-build system, talvez sejam até meta-meta-build systems...) Portanto, é difícil que eles resolvam especificamente os problemas que surgem no próprio build system. O vcpkg mostra sinais de ter pensado mais nisso; por exemplo, quando diferentes versões da mesma dependência são necessárias em um projeto (por meio de caminhos de dependência distintos), é possível dividir o enlistment, mas isso não passa de uma forma de contornar as limitações do próprio build system. Já no caso de Rust e Cargo, por exemplo, não há problema em compilar as duas versões e referenciá-las em um único crate.
Além disso, no momento o vcpkg parece não ter, no Visual Studio, nem mesmo um nível de integração de ferramentas comparável ao do NuGet (apenas integração com o MSBuild...), e também não parece haver muita integração com os gerenciadores de pacotes de distribuições Linux/BSD. Esse problema também é, hoje, o maior desafio enfrentado pelos gerenciadores de pacotes por linguagem; linguagens mais novas, como Rust, estão resolvendo isso caso a caso, mas um gerenciador de pacotes para C/C++ necessariamente deveria buscar integração com os sistemas já existentes, e isso ainda avança muito lentamente. Só depois que essa parte for resolvida será possível dizer que ferramentas do tipo vcpkg se tornaram de uso geral no desenvolvimento em C/C++. O fato de isso ainda não ter acontecido é a principal razão pela qual eu subestimei os sistemas de pacotes no texto. (A proliferação de single-file library mencionada no texto também é uma evidência indireta de que sistemas do tipo vcpkg ainda não conseguiram se tornar tão atraentes.)
Muito obrigado pela resposta detalhada. Realmente, como a base é o build = m=.., existe uma barreira que não dá para acompanhar, diferente do npm e de outros gerenciadores de pacotes. O vcpkg parece estar pensando bastante sobre versões ultimamente, mas não deve ser fácil superar isso.
Às vezes penso que o sistema de módulos do C++20 poderia ser a resposta para esse problema... mas aí o escopo já ultrapassa a linguagem C (...). Parece que para a linguagem C só resta mesmo um caminho espinhoso. Mesmo que o C20 seja padronizado agora, a taxa de adoção de versões provavelmente não seria tão alta quanto no C++..
Obrigado pela boa opinião.
Meu pensamento pessoal é o seguinte. É um bom sinal existirem alguns gerenciadores de pacotes para C, mas o problema parece ser que esses gerenciadores de pacotes não são muito usados. Mais precisamente, como o legado de C já é enorme, tenho a impressão de que talvez já tenhamos ido longe demais para resolver os problemas mencionados acima. Por isso, não seria por esse motivo que há tantas tentativas de migrar para linguagens novas, como Rust?
Ouvindo isso e pensando de novo, acho que o foco desses gerenciadores de pacotes acima não está tanto em prolongar a vida da linguagem C, mas sim em prolongar a vida dos programadores que são obrigados a usar C.
Agora que chegou a hora de se mudar para uma casa nova (C++, Rust...), quando você precisa de móveis da casa antiga, como OpenGL ou Lua, sem um gerenciador de pacotes tinha que carregar tudo na mão (fazer linking, rodar
make, perder cabelo porque a versão da DLL ou da lib não bate, querer se jogar da janela depois de encarar erro de LNK...). Mas agora, com gerenciador de pacotes, dá para levar tudo de forma limpa, como numa mudança com serviço de embalagem. Como já existe coisa demais pronta, vai ter hora em que também será preciso usar isso na casa nova...Agora, vendo que o mérito do acúmulo de experiência até aqui é maior do que as vantagens da linguagem em si, dá para sentir na pele que ela é mesmo uma linguagem que está morrendo(...)
De várias formas, parece que Rust é a linguagem que mais fortemente carrega a imagem de sucessora de C/C++. (Entre algumas linguagens tratadas como “next”, também existe a imagem de ser relativamente a mais complexa... rsrs)
Parece que não é só pela imagem; Rust também parece ser realmente difícil.