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


91

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?


18
videogames, sistemas embarcados, programação hardware (firmware), sistemas operacionais, etc.

25
Observe que você só obtém o que mede - no caso do TIOBE, o número de ocorrências +"<language> programming"nos mecanismos de pesquisa populares. Uma postagem no blog "Por que ninguém mais faz programação C" conta para C neste índice. Heck, mesmo esta questão pode ser assim que o google pega.

40
A idade do POO? essa é uma afirmação bastante ousada.
Mahmoud Hossam

57
Você tem a ilusão de que OOP é uma bala de prata, você deve perder rapidamente, não há nada de especial ou "bom" em OOP, é apenas uma das muitas estratégias de organização de código.
Raynos

23
@DeadMG: Pot, conheça a chaleira. Os dados do TIOBE podem não ser confiáveis, mas sua afirmação de que "não é popular" não tem fonte ou citação. Se você desafiar a suposição por trás da pergunta, pelo menos forneça algumas evidências para apoiá-la.
22812 Daniel Pryden

Respostas:


142

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.

9
Eu acho que nem todos os seus argumentos estão corretos. 1) C é onipresente. C ++ é tão onipresente quanto C, já que existem compiladores de C ++ para C. 2) C é portátil. O mesmo com C ++. 3) C já existe há algum tempo. O mesmo com C ++. 4) C é versátil. O mesmo com C ++. 5) C é rápido. O mesmo com C ++. 6) C é 'grátis'. O mesmo com C ++. 7) C tem muito impulso. O mesmo com C ++ novamente. 8) C é maduro. O mesmo com C ++. Então você realmente não responde à pergunta.
Konstantin Solomatov

19
C11 é o padrão mais recente, não C99. Não que isso realmente importe, pois todo mundo usa '89.
Pubby

53
@ KonstantinSolomatov: Se você estiver escrevendo uma biblioteca que será consumida por outras pessoas, faça um favor ao mundo e escreva em C em vez de C ++. Se você não pode fazer isso, pelo menos escreva uma API C. Tudo no universo pode ser vinculado ao código C de uma maneira ou de outra, geralmente com o mínimo esforço. Por outro lado, você frequentemente terá grandes problemas de ABI ao tentar chamar o código C ++ de outro código C ++ , e muito menos de outras linguagens.
Daniel Pryden

37
@ KonstantinSolomatov - o fato de haver a necessidade de um compilador de C ++ para C prova que C é o que é onipresente.
detly

11
@ KonstantinSolomatov: Por favor, pare de pensar que C é C ++. C não tem fechamentos. Algumas extensões do C funcionam (como as implementadas pela família de compiladores gcc), mas o próprio C não (ou seja, não está na especificação K&R original nem em nenhum dos padrões C finalizados).
Donal Fellows

88

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!


18
Tenho certeza de que muitas pessoas desistiram da seção "Leia mais apenas se estiver interessado em uma exploração no nível da física". Estou feliz por não ter. Esse é o tipo de pensamento que abala os fundamentos de nosso entendimento e, provavelmente, a única maneira de obtermos um progresso notável. Obrigado pela ótima leitura.
Matt Esch

@ Raynos, $ MattEsch, obrigado a vocês por suas amáveis ​​palavras, e estou feliz que você tenha achado interessante!
Terry Bollinger

1
Inscreva-se no site apenas para poder votar - essa resposta magnífica e profunda. =)
sgorozco

2
De acordo com seus pensamentos, tenho programado por um bom tempo e me tornei um fanático por OOP, desde que realmente vi minhas habilidades de codificação melhorarem drasticamente quando o adotei. No entanto, a experiência me mostrou que forçar tudo a se tornar um objeto pode ser realmente prejudicial. Agora, rejeito as ferramentas de mapeamento objeto a relacional (que bagunça) ou esquemas completos de serialização de gráfico de objeto que consomem 1000% de largura de banda em comparação com um protocolo binário simples que apenas envia por fio a quantidade certa de dados binários necessários em o momento. Obrigado pela ótima leitura.
Sgorozco

2
Esta resposta também é a resposta para por que ainda precisamos do SQL!
HLGEM

25

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.


11
A programação funcional é ótima, não há objeção a isso. Mas C é uma linguagem bastante ruim para programação funcional. Fechamentos / bloqueios são hacks não portáteis e vêm com uma sintaxe feia (assim como dicas, aposto). Mesmo ignorando tudo isso, você ainda precisa se preocupar com o gerenciamento de memória. C é uma linguagem útil, mas, como em qualquer linguagem, você está tornando sua vida mais difícil do que deveria ser se abusar dela para usar um paradigma para o qual não foi feita. Você também pode emular a programação funcional em Java (consulte Guava ), mas também não é bom.

7
É muito difícil programar em um estilo funcional sem um coletor de lixo.
Konstantin Solomatov

@ KonstantinSolomatov: Primeiramente, isso é muito subjetivo. Em segundo lugar, você pode adicionar a coleta de lixo ao C, se necessário.
back2dos

Se você deseja um compromisso entre Java e C ++, tente Obj-C :) Definitivamente, algo que todo programador de C / C ++ deve tentar.
Sulthan

21

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.


2
Mmm .. um rolo de C, tomate e queijo!
23412 DeadMG

3
Bem, C ++ tem uma ABI. É que o C ABI é sólido como rocha, enquanto o C ++ muda com muita frequência. Além disso, muitos C ++ são modelos compilados no aplicativo em uso, portanto você não pode atualizá-lo. Quando toda a funcionalidade está oculta por trás das chamadas de função, é possível corrigir a biblioteca e manter o aplicativo funcionando.
Jan Hudec 13/08/2013

12

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.


2
Pena de tempo de execução é um absurdo. C-strings (terminação nula) são muito menos eficientes que as strings C ++. Além disso, uma classe string pode ser tão compacto quanto C, desde que você não arrastar o todo stdno.
Pubby

1
Uma cadeia de ferramentas que não remove as funções stringnão utilizadas e que não são usadas se você vincular estaticamente o CRT é uma cadeia de ferramentas que não vale a pena.
Billy ONeal

10
O mais bobo é que trabalho com uma biblioteca onde std::stringnão é sofisticada o suficiente . Se você realmente leva a sério as strings, tanto em termos de desempenho quanto de recursos, volta a usar o C e faz tudo sozinho novamente, embora não use char*s simples e antigos para ter certeza. (Strings são surpreendentemente complexa, mesmo se você estiver esperando-os a ser complicado.)
Donal Fellows

1
@DonalFellow Interesting. É exatamente por isso que o padrão C sempre renunciou a coisas como seqüências de caracteres e tabelas de hash, assim como sua ausência me incomoda às vezes.
Engenheiro de

@ArcaneEngineer: O tipo de dado ausente fundamental em C é um tipo de "fatia de T []" que combinaria um T * e um size_t, poderia ser indexado como uma matriz, poderia se decompor em um T * e poderia ser implicitamente convertido de qualquer tipo T [n] (com o tamanho sendo fornecido automaticamente pelo compilador). Esse tipo pode permitir a verificação automática de limites em muitos casos onde isso é impossível, enquanto torna muitos tipos de código muito mais limpos e legíveis.
Supercat

11

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.


2
Sim, C é executado em tudo. E é uma linguagem muito fácil de aprender (em comparação com c ++).
benjaminb

10

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.


6

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.


5
Melhor ainda, há uma boa chance de que o código compilado há 10 anos possa ser executado hoje.
Donal Fellows

@DonalFellows: E, para aplicativos que usam plug-ins, há uma chance razoável de que um aplicativo gravado, construído e lançado (em formato executável) hoje possa usar plug-ins compilados com ferramentas de construção que nem sequer foram projetado ainda.
Supercat

6

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.


4

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.


Coisas que eu coloquei na categoria 'pior, mas melhor': inglês, PHP, Windows. .. McDonald's talvez. Embora eu ainda inveje / prefira a culinária espanhola, Python, Linux e francesa artesanal; tanto quanto possível, se não for possível.
22415 ThorSummoner #

1

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.

Este link está quebrado.
Ar2015

0

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


10
O fato de que TIOBE é inútil não significa C não é popular
Raynos

Definitivamente, no entanto, derrota o argumento apresentado no OP - que C é popular e, portanto, deve ser útil.
23412 DeadMG

2
A melhor medida da popularidade do C é que quase todas as plataformas tem um compilador C
Raynos

@ Raynos: Isso não é uma medida. A única coisa que significa é que é fácil de implementar. Não diz nada sobre quantas pessoas o usam ou por quê.
23412 DeadMG

2
Não inteiramente, aceito alegremente pontos de vista opostos. Sua resposta de uma linha parece ter pouco pensamento aplicado, e você é argumentativo e não construtivo com suas respostas.
mattnz

0

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.


3
A segunda metade desta resposta precisa ser ofuscada.
Aramis

@aramis. A segunda parte significa: Muitos código parece ser donde diretamente em "C", mas, na verdade, em outro idioma, e traslated para "C"
umlcat

0

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.


3
Um problema com Pascal é que a versão "oficial" do idioma deixou de lado alguns recursos muito necessários. Por algum tempo, tanto o PC quanto o Macintosh tiveram compiladores Pascal que eram muito mais utilizáveis ​​do que os compiladores C existentes na época, mas esses compiladores adicionaram extensões de idioma que não eram suportadas por nenhum padrão "oficial". Penso que, se houvesse um esforço para criar um padrão oficial que codificasse essas extensões, Pascal poderia ter substituído o hack de um idioma conhecido como "C".
Supercat 23/08

0

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.


você comparou as perguntas de SO para C # ou Java?
Gnat #

@gnat foi um exemplo isolado de C v Python (que por sinal tem mais perguntas!). Eu não tenho nenhuma experiência com C # (você notou minha não pedir SO perguntas para C # ou jav?)
puk

Heh, acho que a comunidade #python no StackOverflow é quase sempre super rápida. Embora eu ficaria surpreso se a comunidade C superasse a comunidade javascript por velocidade de respostas. (Principalmente por causa do volume)
ThorSummoner
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.