O que torna o C tão popular na era da OOP? [fechadas]

Eu codifico muito em C e C ++, mas não esperava que C fosse a segunda linguagem mais popular, um pouco atrás do Java.

Índice da Comunidade de Programação TIOBE

Estou curioso para saber por que, nesta era da OOP, C ainda é tão popular? Observe que 4 das 5 principais linguagens de programação populares são linguagens "modernas" e capazes de orientar a objetos.

Agora, concordo que você pode usar OOP em C até certo ponto, mas é meio doloroso e deselegante (pelo menos em comparação com C ++, eu acho). Então, o que torna C tão popular? É eficiência; ser de baixo nível; a grande maioria das bibliotecas que já existem ou algo mais?

Alguns fatores que contribuem:

• C é onipresente. Qualquer que seja a plataforma, C provavelmente está disponível.
• C é portátil. Escreva um C limpo e compile com modificações mínimas em outras plataformas - às vezes até funciona de imediato.
• C já existe há algum tempo. Nos dias em que o UNIX conquistou o mundo, o C (a linguagem de programação escolhida pelo UNIX) compartilhou seu domínio no mundo e se tornou a língua franca do mundo da programação. Qualquer programador sério pode ser esperado para pelo menos fazer alguns sentido de um pedaço de C; o mesmo não pode ser dito sobre a maioria dos outros idiomas.
• C ainda é o idioma padrão para sistemas com UNIX e UNIX. Se você deseja que uma biblioteca seja bem-sucedida em terrenos de código aberto, precisará de razoáveis ​​razões para não para usar C. Isso é parcialmente devido à tradição, mas mais porque C é o único idioma que você pode assumir com segurança como suportado em qualquer UNIX-like sistema. Escrever sua biblioteca em C significa que você pode minimizar as dependências.
• C é simples. Falta a expressividade de OOP sofisticado ou linguagens funcionais, mas sua simplicidade significa que pode ser captado rapidamente.
• C é versátil. É adequado para sistemas embarcados, drivers de dispositivo, kernels de SO, pequenos utilitários de linha de comando, grandes aplicativos de desktop, DBMSs, implementando outras linguagens de programação e praticamente qualquer outra coisa que você possa imaginar.
• C é rápido. A maioria das implementações de C são compiladas diretamente no código da máquina, e o programador tem total poder sobre o que acontece no nível da máquina. Não há intérprete, compilador JIT, VM ou tempo de execução - apenas o código, um compilador, um vinculador e o bare metal.
• C é 'grátis' (no sentido da cerveja e da fala). Não existe uma empresa que possua e controle o padrão, há várias implementações para escolher, não há questões de direitos autorais, patentes ou marcas registradas para o uso de C, e algumas das melhores implementações são de código aberto.
• C tem muito impulso. O idioma é popular há décadas, portanto, há uma enorme quantidade de aplicativos, bibliotecas, ferramentas e, principalmente, comunidades, para oferecer suporte ao idioma.
• C é maduro. O último padrão que introduziu grandes mudanças é o C99, e é principalmente compatível com versões anteriores dos padrões anteriores. Diferentemente das linguagens mais recentes (por exemplo, Python), você não precisa se preocupar em fazer alterações tão cedo.
• C é compatível. A maioria dos idiomas possui ligações para conversar com C. Isso significa que é possível desenvolver uma biblioteca em C usando convenções de chamada padrão e sentir-se confiante de que quase qualquer outro idioma pode ser vinculado a essa biblioteca. Para citar algumas linguagens populares em uso generalizado: C #, Java, Perl, Python, PHP podem ser vinculados a bibliotecas C sem muitos problemas.
• C é poderoso: se a linguagem não pode fazer algo, todos os compiladores populares permitem incorporar código assembler que pode fazer qualquer coisa que o hardware possa fazer. Combinado de forma transitória com o ponto acima sobre compatibilidade, isso significa que C pode atuar como uma ligação entre idiomas de nível superior e o "metal puro" do assembly.

Sempre tendi a culpar a popularidade do C pela necessidade de uma linguagem assembly universal. Sua combinação de especificidade no nível da máquina, padronização e extrema portabilidade permite que o C funcione como essa linguagem assembly universal de fato e, por esse motivo, desconfio que seu papel continuará indefinidamente.

Devo mencionar que sempre fico surpreso quando o OOP é apresentado nos cursos de programação como uma espécie de "modelo final" que é o único ponto final possível para uma boa programação. Como muitos outros aspectos da programação, o valor da OOP é um compromisso entre muitos fatores concorrentes, incluindo como os cérebros humanos organizam as informações, como os grupos sociais apóiam o software a longo prazo e, no caso da programação orientada a objetos, alguns aspectos bastante profundos de como o próprio universo funciona.

E esse último ponto vale a pena martelar um pouco. Leia mais se você estiver interessado em uma exploração no nível da física de por que certos estilos de programação existem, como eles funcionam juntos e para onde o mundo está indo no futuro, à medida que expandimos ainda mais esses conceitos ...

Um objeto na física é qualquer coisa que mantenha coerência reconhecível ao longo do tempo. Isso, por sua vez, permite que criaturas simples como nós passemos a representar o objeto usando apenas um pequeno número de bits, sem comprometer muito nossa sobrevivência. Mas em termos de física em geral, o número de coisas que você precisa acertar para tornar esse tipo de simplificação fácil e comum é notavelmente grande. Como seres humanos, não pensamos em tudo isso porque, francamente, não estaríamos aqui se não fosse verdade.

Parece muito abstrato? Realmente não é. Imagine, por exemplo, tentar navegar pela estrada para a casa de seu amigo se, em vez de carros, você encontrar campos de plasma que oscilam rapidamente e condensações momentâneas de matéria se movendo com uma enorme variedade de velocidades. Esse cenário pode se aprofundar bastante nas oportunidades de socialização, certo? Precisamos de objetos, que são objetos, e a existência de objetos nos proporciona um nível enorme e extremamente importante de simplificação do ambiente que nos rodeia.

Então, vamos colocar tudo isso de volta no software. O que objetos no mundo real têm a dizer sobre objetos em termos de programação?

Bem, por um lado, significa que o que define um objeto "bom" no software deve ser realmente se o tipo de dados que você está manipulando prontamente suporta a idéia de persistência reconhecível ao longo do tempo .

Com a definição, as formas mais fáceis de POO são fáceis de serem reconhecidas. Eles são os únicos que conseguem entender um pouco, usando apenas dados que já estão "anexados" ou definidos por algum objeto verdadeiramente físico do mundo real, como uma pessoa, casa ou carro. Ainda hoje, essa ainda é a única definição de objetos que as pessoas obtêm nos cursos de software. Isso é muito ruim, porque mesmo programas triviais de orientação a objetos precisam de uma definição mais ampla do que isso.

A segunda e muito mais interessante categoria de objetos consiste no que chamarei de eventos imortalizados do mundo real . Por "imortalizado", quero dizer coisas que pelo menos brevemente existem como uma entidade ou coleções bem definidas no mundo real, mas que depois se dispersam e deixam de existir como coleções fisicamente significativas. Um simpósio é um ótimo exemplo: o simpósio existe por um curto período como uma coleção decentemente bem definida de lugares e pessoas. Mas, infelizmente, mesmo as melhores conferências devem terminar, e as partes individuais que as criaram passam para outras atividades.

Mas, usando computadores e redes, podemos fazer com que um simpósio transitório pareça um objeto de longo prazo, capturando e mantendo uma memória dele como um objeto de software. Muitas das coisas que fazemos com computadores e bancos de dados equivalem a esse tipo de imortalização de eventos transitórios, nos quais tentamos, de fato, tornar nosso universo real mais rico, capturando e estendendo-o de maneiras que não podem existir fisicamente. Por exemplo, você viu um Pandora real ultimamente? Tais capturas e extensões de peças do mundo real ajudam a enriquecer e prolongar nossas próprias vidas, economias e escolhas de maneiras notáveis. Isso para mim é o coração da programação orientada a objetos, o lugar onde ela teve e continua a ter os impactos mais notáveis.

Uma categoria final de OOP consiste em objetos que não têm conexão estreita com eventos externos, mas são a infraestruturanecessário para apoiar nossa extensão contínua da realidade usando objetos imortalizados do mundo real. É aqui que você pode descer até o (semi) metal do computador, criando pedaços de realidade persistente que, como os elementos químicos do mundo real, podem ser combinados rapidamente e de maneiras interessantes para construir novos mundos internos. A computação móvel ajudou a promover o crescimento desse tipo de abordagem altamente recombinatorial, que novamente imita de várias maneiras os recursos recombinatórios do mundo físico. Também é difícil: o que pode parecer uma boa escolha ao longo do tempo pode ter sido inesperadamente ruim, geralmente porque acaba bloqueando a diversidade e a expansão, em vez de apoiá-la.

Essa última categoria também aponta os riscos de usar apenas um modelo para programação, pois, assim como o mundo real, os mundos programados também precisam de processos que nãocorrespondem bem a objetos relativamente imutáveis. A Terra está cheia de objetos, mas o sol está cheio de fluxos de energia altamente dinâmicos que são necessários para "dirigir" os objetos e atividades na Terra de menor energia. Da mesma forma, na criação de mundos da computação, há casos em que você deve lidar com fluxos e transformações e contextos em rápida mudança que, embora não sejam muito parecidos com objetos, são absolutamente críticos para permitir que objetos mais simples e amigáveis ​​ao ser humano sejam usados ​​em níveis mais altos . Não é por acaso que grande parte da programação feita no nível do kernel não é visivelmente semelhante a um objeto ou tende a depender fortemente de linguagens como C, mais orientadas ao processamento. Esses são os domínios mais profundos que complementam a diversidade fascinante que vemos mais no mundo gerado por computador.

A outra área em que o OOP pode dar errado está se concentrando demais nos conceitos de objetos antigos .

Objetos no mundo real, e especialmente objetos vivos , têm um nível absolutamente surpreendente de capacidade de interagir com seus ambientes de maneiras complexas e sutis. Os widgets compostas que se examinam, fazem algumas verificações de compatibilidade e sanidade e talvez até descobram novas maneiras de interagir se aproximam muito do conceito biológico de objetos do mundo real do que as estruturas simples e os esquemas simples de herança que tendemos focar (geralmente por necessidade!) no nível do código. Essa é uma das áreas de crescimento de objetos no mundo cibernético, quanto mais abordagens "semelhantes a agentes", onde a reatividade ao meio ambiente é a norma, mesmo na própria programação.

E muito pela minha "crítica" ao POO! Ainda assim, espero ter apontado por que criar um mundo cibernético mais rico significa abranger a diversidade de estilos de programação, em vez de assumir que "apenas um" é tudo o que é necessário. Meu sentimento é que as coisas realmente interessantes ainda estão por vir, não importa quão mundano seja o que fazemos agora!

Em primeiro lugar, você não precisa de OOP para tudo, apesar de quaisquer dogmas sobre isso terem sido popularizados. Ao contrário do Java, o C permite ponteiros de função e até fechamentos, o que abre a porta para a programação funcional e resolve grande parte do espaço problemático que o OOP manipula, porque fornece os meios de injeção de dependência. Além disso, o uso cauteloso de macros pode realmente criar coisas muito boas, como prova o sglib .

De uma maneira estranha, pode-se ver o C como um bom compromisso entre Java e C ++. Por favor, note que não estou dizendo que C seja de alguma forma uma mistura de ambos. Mas, ao contrário do Java, é uma linguagem bastante poderosa, enquanto, ao contrário do C ++, possui complexidade gerenciável.

É um idioma antigo, que se tornou confiável e consistente, embora não se torne realmente mais complicado. E tudo isso de lado, ele tem um ecossistema gigante e simplesmente roda por toda parte.

C tem um ABI (Application Binary Interface) C ++ não. Isso torna o C mais útil que o C ++ em certos casos. Se eu vou escrever uma biblioteca e poder enviar binários para uso de outras pessoas, o C ++ é a ferramenta errada para o trabalho. Se eu vou escrever bibliotecas que serão usadas por algum outro idioma novamente, C é a ferramenta certa para o trabalho. Eu nunca ouvi falar de uma linguagem que não suporta FFI (Foreign Function Interface) para C, por outro lado, o C ++ não funciona com bibliotecas escritas em C ++ se diferentes compiladores forem usados.

Basicamente, tudo se resume a C preenchendo uma função para a qual o C ++ não é adequado.

Uma vantagem do uso de C sobre linguagens como C ++ ou Java é que não há muita mágica acontecendo sob o capô. Nenhum construtor é executado quando os itens são alocados, e nenhum destruidor é executado quando os objetos ficam fora do escopo. Não há nomes desconcertantes e nenhuma tabela. O desempenho é mais fácil de prever; você não precisa se preocupar com um coletor de lixo interrompendo uma rotina e diminuindo o tempo.

Construtores, destruidores, nomes diferentes, vtables, coletores de lixo etc. podem facilitar um pouco a complexidade do código que você cria, mas essa complexidade se torna parte da própria linguagem, na qual você tem pouco ou nenhum controle sobre ela . Você pode acabar com tempos de construção mais longos (irritante, mas tolerável), maior espaço de memória de tempo de execução (pode ou não ser tolerável) ou desempenho mais lento. Com o C, você pode reduzir um pouco dessa complexidade até ficar com a funcionalidade necessária .

Por exemplo, o stringtipo de dados C ++ é mais fácil de trabalhar em anos-luz do que as seqüências de caracteres no estilo C, mas é um pedaço de código bastante pesado e adiciona algum peso ao tamanho da imagem. Eu raramente vi alguém fazer pleno uso dos stringrecursos de qualquer programa. Seqüências de caracteres no estilo C, embora mais difíceis de trabalhar, impõem menos penalidade em termos de tempo de execução e tamanho da imagem, e para um problema específico pode ser mais atraente por esse motivo.

Sistemas e drivers incorporados geralmente são programados em C. Além disso, existem muitos sistemas C legados por aí que ainda são mantidos e estendidos.

A mesma coisa que populariza um martelo manual em uma época de martelos pneumáticos (martelos pneumáticos): C ainda é a ferramenta certa para certos trabalhos.

Simplicidade, consistência e precisão.

É simples - você não precisa de um ambiente de desenvolvimento complexo, bibliotecas extensas ou máquina virtual.

É consistente - a maioria dos C escritos há 10 anos atrás poderiam compilar hoje.

Precisão - permite chegar ao nível da máquina, conhecendo os locais de memória conforme necessário. Isso é ótimo para desempenho e hardware incorporado.

Não é para tudo, mas ainda é uma ferramenta útil.

Cito dois pontos de outra resposta, porque eles capturam exatamente as razões pelas quais eu ainda uso o C de tempos em tempos (embora não seja o meu principal idioma de escolha):

• C é simples. Falta a expressividade de OOP sofisticado ou linguagens funcionais, mas sua simplicidade significa que pode ser captado rapidamente.
• C é maduro. O último padrão que introduziu grandes mudanças é o C99, e é principalmente compatível com versões anteriores dos padrões anteriores. Diferentemente das linguagens mais recentes (por exemplo, Python), você não precisa se preocupar em interromper as mudanças tão cedo.

Eu acho que isso é verdade. Eu aprendi C durante as primeiras noites: era simples, poucas palavras-chave e construções, a maior parte do trabalho realizado pelas bibliotecas. Então eu não usei C por alguns anos. Por volta de 2002, eu precisava de uma implementação rápida de um algoritmo, instalei um compilador C e o implementei. Conheço o idioma, sei para que serve e para que não serve (eu nunca implementaria um aplicativo Web em C!), E ele está lá quando eu precisar. Sem surpresas.

Com C ++, tive uma experiência diferente. Aprendi em 1995 e significou uma grande mudança de paradigma do imperativo para o OOP. Ótimo! Usei-o para vários projetos até 1999. Por alguns anos não usei C ++ e, quando o recuperei novamente (2008), encontrei muitos novos recursos já na linguagem e ainda mais planejados (enquanto isso era introduzido no C ++ 11) Tenho a sensação de que tenho que aprender o idioma novamente.

Como desenvolvedor, prefiro idiomas maduros e estáveis. Gosto de aprender um idioma uma vez, entender seus princípios de design, para que serve e usá-lo quando achar que é a ferramenta certa para o trabalho. Também gosto de aprender linguagens diferentes e escolher a linguagem que atenda às minhas necessidades (C, C ++, Java, Scala, Haskell e assim por diante). O que eu não gosto é ter que aprender o mesmo idioma repetidamente, porque ele se desenvolve cada vez mais e nunca atinge a maturidade.

IMHO, uma linguagem de programação deve ter um design claro, coerente e estável. Gosto da abordagem de designers como Niklaus Wirth: toda vez que sentia necessidade de um idioma diferente, ele criava um novo (Pascal, Modula-2, Modula-3, Oberon). Não gosto de idiomas que sofrem mudanças importantes a cada 5 a 10 anos: são como alvos móveis e nunca acho que vale a pena investir meu tempo para aprendê-los em profundidade, porque a versão que estou aprendendo agora provavelmente ficará obsoleta em alguns anos de qualquer maneira.

Nesse sentido, C é vencedor da OMI: é bom para certas aplicações e menos apropriado para outras, mas tem a vantagem de ser simples e relativamente estável.

Estou surpreso que ninguém tenha mencionado ainda pior . Já tem mais de 20 anos, mas ainda vale a pena ler eminentemente. Embora às vezes seja um pouco irônico, ele faz um excelente trabalho em descrever como e por que o expediente geralmente vence o ideal, usando C (oposto ao LISP) como um de seus exemplos centrais.

Você provavelmente queria perguntar por que as pessoas usam C em vez de C ++, apesar de, quando você tem um compilador C, também costuma ter um compilador C ++.

• A linguagem C é muito mais simples que o C ++. Não conheço nenhuma empresa que use o padrão C ++ completo em sua convenção de codificação. Dê uma olhada no estilo de código C ++ do Google como exemplo: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
• C é muito mais rápido para compilar. Graças à falta de construções difíceis de compilar.

Nada. TIOBE é um índice inútil. Se você realmente observar as medidas deles, é um palpite absoluto.

Muito software herdado

Muitas empresas não podem mudar, instantaneamente, todo o seu código para C ++ ou similar.

Muitas empresas não podem mudar seu código.

Muitas empresas podem mudar seu código, mas não se importam ou são "baratas".

Muitas empresas estão em processo de migração, mas ainda não estão concluídas.

Orientação a objetos ocultos

Código-fonte C (não orientado a objetos), projetado como código-fonte C orientado a objetos, aplicativos modelados com Orientação a objetos e codificados com "C puro" ou ferramentas que traduzem de "C ++" ou outro programa OO. lang em C.

Ouvi dizer que alguns videogames são feitos dessa maneira. Algumas ferramentas de plataforma cruzada também e a biblioteca de interface visual GTK (GObject, GLibrary) para as distribuições do sistema operacional GNome Linux.

Vejo alguns dos respondentes explicando por que C é o mais popular, já existe há muito tempo, está disponível na maioria das plataformas, gratuitamente, etc.

Mas o mesmo pode ser dito sobre outros idiomas, como o Pascal gratuito, por exemplo - é gratuito e é compatível com praticamente todas as plataformas.

Pascal foi inventado por volta de 1970, C foi inventado por volta de 1972, então eu acho que Pascal existe há tanto tempo quanto C.

Pessoalmente, acho que C é o idioma mais popular, porque há apenas mais código-fonte aberto disponível para ser reutilizado por qualquer pessoa. E sim, é um nível inferior ao Pascal, por isso está chegando perto da montagem, mas é muito mais legível que a montagem.

Eu acho que existem muitas linguagens de programação por aí. Como programadores, precisamos conhecer a maioria dos importantes, mas no final não deve haver necessidade disso. Uma linguagem de programação pode ser implementada para fazer tudo, desde a criação de sites até jogos de computador para iOS.

C parece ser essa linguagem global, mas eu gostaria que fosse algo como Object Pascal. Por que o Object Pascal, é uma linguagem de programação mais legível, o código OOP tende a ser mais reutilizável e menos propenso a erros (na minha opinião) do que C.

Aplicativos muito grandes são mais fáceis de gerenciar com o Object Pascal do que o C / C ++.

Quanto a ter uma linguagem de programação que existe desde os anos 70, e não gostar de linguagens que mudam a cada 5 ou 10 anos. Com o passar do tempo, a tecnologia avança e os métodos de programação são aprimorados. Se um idioma muda drasticamente a cada poucos anos, provavelmente não foi bem pensado por seu designer. Mas 1970 a 2012 são quase meio século, não há problema em fazer alterações em um idioma nesse momento para incorporar os avanços usados ​​no desenvolvimento de software.

O próprio C foi revisado várias vezes. Portanto, não é melhor do que outras línguas desse ponto de vista.

Porque C tem uma enorme base de usuários. Sim, é um pouco complicado, mas quando faço uma pergunta sobre C no StackOverflow, recebo a resposta quase que instantaneamente. A mesma pergunta sobre Python pode levar horas para ser respondida.

Com relação ao C ++, é IMO mais complicado de aprender. Além disso, depois de tentar OOP por 10 anos, acho que nem sempre é útil e, muitas vezes, é mais fácil usar a programação procedural.