Qu'est-ce qui rend le C si populaire à l'ère de la POO?
Je code beaucoup en C et C++, mais je ne m'attendais pas à ce que C soit le deuxième langage le plus populaire, légèrement derrière Java.
Index de la communauté de programmation TIOBE
Je suis curieux de savoir pourquoi, à l'ère de la POO, C est toujours aussi populaire? Notez que 4 des 5 principaux langages de programmation populaires sont des langages "modernes", orientés objet.
Maintenant, je suis d'accord que vous pouvez utiliser OOP en C dans une certaine mesure, mais c'est en quelque sorte douloureux et inélégant (enfin au moins par rapport au C++, je suppose). Alors, qu'est-ce qui rend le C si populaire? Est-ce l'efficacité, le bas niveau, la grande majorité des bibliothèques qui existent déjà ou autre chose?
Quelques facteurs qui contribuent:
- C est omniprésent. Quelle que soit la plateforme, C est probablement disponible.
- C est portable. Écrivez un morceau de C propre, et il se compile avec des modifications minimes sur d'autres plates-formes - parfois, il fonctionne même prêt à l'emploi.
- C existe depuis un certain temps. À l'époque où UNIX a conquis le monde, C (le langage de programmation UNIX de choix) a partagé sa domination mondiale et est devenu la lingua franca du monde de la programmation. On peut s'attendre à ce que tout programmeur sérieux donne au moins certains sens à un morceau de C; on ne peut pas en dire autant de la plupart des autres langues.
- C est toujours le langage par défaut pour les systèmes UNIX et UNIX. Si vous voulez qu'une bibliothèque réussisse en open-source, vous avez besoin d'assez bonnes raisons pas pour utiliser C. Ceci est partiellement dû à la tradition, mais plus parce que C est le seul langage que vous pouvez supposer en toute sécurité être pris en charge sur tout système de type UNIX. Écrire votre bibliothèque en C signifie que vous pouvez minimiser les dépendances.
- C est simple. Il n'a pas l'expressivité des langages sophistiqués OOP ou fonctionnels, mais sa simplicité signifie qu'il peut être détecté rapidement.
- C est polyvalent. Il convient aux systèmes embarqués, aux pilotes de périphériques, aux noyaux de système d'exploitation, aux petits utilitaires de ligne de commande, aux grandes applications de bureau, aux SGBD, à l'implémentation d'autres langages de programmation et à pratiquement tout ce à quoi vous pouvez penser.
- C est rapide. La plupart des implémentations C se compilent directement en code machine, et le programmeur a le plein pouvoir sur ce qui se passe au niveau machine. Il n'y a pas d'interprète, pas de compilateur JIT, pas VM ou runtime - juste le code, un compilateur, un éditeur de liens et le métal nu.
- C est "libre" (dans le sens de la bière et de la parole). Il n'y a pas une seule entreprise qui possède et contrôle la norme, il y a plusieurs implémentations parmi lesquelles choisir, il n'y a pas de problèmes de copyright, de brevet ou de marque pour l'utilisation de C, et certaines des meilleures implémentations sont open-source.
- C a beaucoup d'élan. La langue est populaire depuis des décennies, il existe donc une énorme quantité d'applications, de bibliothèques, d'outils et, surtout, de communautés pour prendre en charge la langue.
- C est mature. La dernière norme qui a introduit de grands changements est C99, et elle est principalement rétrocompatible avec les normes précédentes. Contrairement aux langages plus récents (par exemple, Python), vous n'avez pas à vous soucier de casser les modifications de sitôt.
- C est compatible. La plupart des langages ont des liaisons pour parler à C. Cela signifie que l'on peut développer une bibliothèque en C en utilisant des conventions d'appel standard, et être sûr que presque n'importe quel autre langage peut se lier à cette bibliothèque. Pour nommer quelques langages populaires largement utilisés: C #, Java, Perl, Python, PHP peut tous se lier aux bibliothèques C sans trop de problèmes.
- C est puissant: si le langage ne peut pas faire quelque chose, tous les compilateurs populaires permettent d'incorporer du code assembleur qui peut faire tout ce que le matériel peut faire. Combiné transitoirement avec le point ci-dessus sur la compatibilité, cela signifie que C peut agir comme une liaison entre les langages de niveau supérieur et le "métal nu" de l'Assemblée.
J'ai toujours eu tendance à blâmer la popularité de C sur la nécessité d'un langage d'assemblage universel. Sa combinaison de spécificité au niveau de la machine, de normalisation et de portabilité extrême permet à C de fonctionner comme cela de facto langage d'assemblage universel, et pour cette raison je soupçonne que son rôle y continuera indéfiniment.
Je dois mentionner que je suis toujours un peu surpris quand OOP est présenté dans les cours de programmation comme une sorte de "modèle final" qui est le seul point final possible pour une bonne programmation. Comme beaucoup d'autres aspects de la programmation, la valeur de OOP est un compromis entre de nombreux facteurs concurrents, notamment la façon dont le cerveau humain organise l'information, la façon dont les groupes sociétaux prennent en charge les logiciels à long terme et, dans le cas de la programmation orientée objet, quelques aspects assez profonds du fonctionnement de l'univers lui-même.
Et ce dernier point mérite d'être martelé un peu. Lisez la suite si vous êtes intéressé par une exploration au niveau physique des raisons pour lesquelles certains styles de programmation existent, comment ils fonctionnent ensemble et où le monde pourrait se diriger à l'avenir alors que nous développons davantage ces concepts ...
Un objet en physique est tout ce qui maintient une cohérence reconnaissable dans le temps. Cela permet à son tour à de simples créatures comme nous de se passer de représenter l'objet en utilisant seulement un petit nombre de bits, sans trop mettre en danger notre survie. Mais en termes de physique dans son ensemble, le nombre de choses que vous devez obtenir exactement pour rendre ce type de simplification facile et commun est remarquablement important. En tant qu'êtres humains, nous ne pensons pas à tout cela parce que franchement, nous ne serions pas ici si ce n'était pas vrai.
Cela semble trop abstrait? Ce n'est vraiment pas le cas. Imaginez par exemple essayer de naviguer sur la route de la maison de votre ami si, au lieu de voitures, vous rencontriez des champs de plasma oscillant rapidement et des condensations momentanées de matière se déplaçant avec une énorme gamme de vitesses. Un tel scénario pourrait couper assez profondément dans les opportunités de socialisation, oui? Nous avons besoin d'objets, nous sommes objets, et l'existence d'objets nous fournit un niveau énorme et extrêmement important de simplification de l'environnement qui nous entoure.
Reprenons donc tout cela dans le logiciel. Qu'est-ce que les objets du monde réel ont à dire sur les objets en termes de programmation?
Eh bien, d'une part, cela signifie que ce qui définit un "bon" objet dans un logiciel devrait vraiment être de savoir si le type de données que vous manipulez supporte facilement l'idée de persistance reconnaissable dans le temps.
Avec la définition, les formes les plus simples de OOP sont faciles à reconnaître. Ce sont celles qui résistent un peu en utilisant uniquement des données déjà "attachées" ou définies par un monde réel, objet vraiment physique comme une personne, une maison ou une voiture. Aujourd'hui encore, c'est encore trop souvent la définition seulement d'objets que les gens obtiennent dans les cours de logiciel. C'est dommage, car même des programmes orientés objet triviaux besoin d'une définition plus large que cela.
La deuxième catégorie d'objets, bien plus intéressante, comprend ce que j'appellerai événements du monde réel immortalisés. Par "immortalisé", j'entends des choses qui au moins brièvement existent en tant qu'entités bien définies ou collections dans le monde réel, mais qui se dispersent ensuite et cessent d'exister en tant que collections physiquement significatives. Un symposium en est un excellent exemple: le colloque existe pendant une courte période en tant que collection décemment bien définie de lieux et de personnes. Mais hélas, même les meilleures conférences doivent se terminer et les différentes parties qui les ont constituées passent à d'autres activités.
Mais en utilisant des ordinateurs et des réseaux, nous pouvons faire un tel colloque transitoire sembler comme un objet à long terme en capturant et en maintenant une mémoire en tant qu'objet logiciel. Une grande partie des choses que nous faisons avec les ordinateurs et les bases de données équivaut à ce type d'immortalisation d'événements transitoires, dans laquelle nous essayons en fait d'enrichir notre univers réel en le capturant et en l'étendant d'une manière qui ne peut pas exister physiquement. Par exemple, avez-vous vu une vraie Pandora récemment? De telles captures et extensions de pièces du monde réel contribuent à enrichir et à prolonger nos propres vies, économies et choix de manière remarquable. C'est pour moi le cœur de la programmation orientée objet, l'endroit où elle a eu, et continue d'avoir, les impacts les plus remarquables.
Une dernière catégorie de OOP se compose d'objets qui n'ont pas de connexion étroite avec des événements externes, mais qui sont plutôt les infrastructure nécessaires pour soutenir notre extension continue de la réalité en utilisant des objets immortalisés de le monde réel. C'est là que vous pouvez descendre jusqu'au métal (semi) de l'ordinateur, créant des morceaux de réalité persistante qui, comme les éléments chimiques du monde réel, peuvent être combinés rapidement et de manière intéressante pour construire de nouveaux L’informatique mobile a contribué à promouvoir la croissance de ce type d’approche hautement recombinatoire, qui imite à bien des égards les caractéristiques de recombinaison du monde physique. C’est aussi difficile: ce qui peut sembler être un bon choix peut s’avérer été inopinément mauvaise, généralement parce qu'elle finit par bloquer la diversité et l'expansion au lieu de la soutenir.
Cette dernière catégorie souligne également les risques d'utiliser un seul modèle pour la programmation, car tout comme le monde réel, les mondes programmés ont également besoin de processus qui ne pas correspondent bien à des objets relativement immuables. La Terre est pleine d'objets, mais le Soleil est plein de flux d'énergie hautement dynamiques qui sont finalement nécessaires pour "conduire" les objets et les activités sur la Terre de faible énergie. De même, dans la création de mondes informatiques, il y a des cas où vous devez gérer des flux et des transformations et des contextes en évolution rapide qui, bien qu'ils ne soient pas très semblables à des objets en eux-mêmes, sont néanmoins absolument essentiels pour permettre l'utilisation d'objets plus simples et plus conviviaux utilisés à des niveaux supérieurs. . Ce n'est pas un hasard si une grande partie de la programmation effectuée au niveau du noyau n'est pas visiblement semblable à un objet, ou qu'elle a tendance à s'appuyer fortement sur des langages comme C qui sont plus orientés vers le traitement. Ce sont les domaines les plus profonds qui complètent la diversité fascinante que nous voyons plus haut dans les mondes générés par ordinateur. Essayer de les forcer à devenir des modèles d'objets purs peut être un peu comme dire au Soleil qu'il doit être réorganisé en quelques milliards d'objets de cheminée bien rangés afin que nous puissions comprendre et naviguer plus facilement du point de vue de l'homme d'abord.
L'autre domaine où OOP peut aller mal) se concentre trop sur les concepts d'objet old.
Les objets du monde réel, et en particulier les objets vivants, ont un niveau absolument incroyable de capacité à interagir avec leur environnement de manière complexe et subtile. Des widgets composables qui se regardent, effectuent des vérifications de compatibilité et d'intégrité, et peut-être même de trouver de nouvelles façons d'interagir se rapprochent beaucoup du concept biologique réel des objets que les cadres simples et les schémas d'héritage simples que nous avons tendance de se concentrer (généralement par nécessité!) au niveau du code. C'est l'un des domaines de croissance des objets dans le cyber-monde, les approches plus "agent-like" où la réactivité à l'environnement est la norme même au sein de la programmation elle-même.
Et tant pis pour ma "critique" de la POO! Néanmoins, j'espère avoir expliqué pourquoi la création d'un cyber-monde plus riche signifie englobant la diversité des styles de programmation, plutôt que de supposer que "un seul" est tout ce qui est nécessaire. Mon sentiment est que les trucs vraiment intéressants sont encore à venir, peu importe à quel point ce que nous faisons maintenant est banal!
Tout d'abord, vous n'avez pas besoin de OOP pour tout, malgré tous les dogmes concernant cela ont été popularisés. Contrairement à Java, C autorise les pointeurs de fonction et même les fermetures qui ouvre la porte à la programmation fonctionnelle et résout tout à fait une partie de l'espace du problème OOP gère, car il fournit les moyens d'injection de dépendance. Aussi prudent l'utilisation de macros peut en fait créer de très belles choses, comme le prouve sglib .
D'une manière étrange, on pourrait voir C comme un bon compromis entre Java et C++. Veuillez noter que je suis pas disant que C est en quelque sorte un mélange des deux. Mais contrairement à Java, c'est un langage plutôt puissant alors que contrairement à C++ il a une complexité gérable.
C'est une vieille langue, qui est devenue fiable et cohérente, sans devenir vraiment plus compliquée. Et tout cela mis à part, il a un écosystème géant et il fonctionne simplement partout.
C a une ABI (Application Binary Interface) C++ n'en a pas. Cela rend C plus utile que C++ dans certains cas. Si je vais écrire une bibliothèque et être en mesure d'expédier des fichiers binaires pour l'utilisation par d'autres personnes, C++ n'est pas le bon outil pour le travail. Si je vais écrire à nouveau des bibliothèques qui vont être utilisées par un autre langage, C est le bon outil pour le travail. Je n'ai jamais entendu parler d'un langage qui ne supporte pas FFI (Foreign Function interface) vers C, en revanche C++ ne fonctionnera pas avec des bibliothèques écrites en C++ si différents compilateurs sont utilisés.
Fondamentalement, cela se résume à C remplir un rôle pour lequel C++ ne convient pas.
Un avantage de l'utilisation de C sur des langages comme C++ ou Java est qu'il n'y a pas beaucoup de magie qui se passe sous le capot. Aucun constructeur n'est exécuté lorsque les éléments sont alloués et aucun destructeur n'est exécuté lorsque les objets sont hors de portée. Il n'y a pas de changement de nom et pas de vtables. Les performances sont plus faciles à prévoir; vous n'avez pas à vous soucier d'un ramasse-miettes interrompant une routine et annulant son timing.
Les constructeurs, les destructeurs, le changement de nom, les tables vtables, les garbage collectors, etc., peuvent alléger une partie de la complexité du code que vous créez, mais cette complexité fait alors partie du langage lui-même, où vous avez peu ou pas de contrôle sur it. Vous pouvez vous retrouver avec des temps de construction plus longs (ennuyeux, mais tolérables), une plus grande empreinte mémoire d'exécution (peut ou non être tolérable) ou des performances plus lentes. Avec C, vous pouvez réduire une partie de cette complexité jusqu'à ce que vous ayez les fonctionnalités dont vous besoin.
Par exemple, le type de données C++ string est années-lumière plus facile à utiliser que les chaînes de style C, mais c'est un morceau de code assez lourd et ajoute un peu de poids à votre image Taille. J'ai rarement vu quelqu'un utiliser pleinement les capacités de string dans un seul programme. Les chaînes de style C, bien que plus difficiles à utiliser, imposent moins de pénalités en termes de durée d'exécution et de taille d'image, et pour un problème particulier, elles peuvent être plus attrayantes pour cette raison.
Les systèmes et pilotes intégrés sont généralement programmés en C. En dehors de cela, il existe des tonnes de systèmes C existants qui sont toujours maintenus et étendus.
La même chose qui rend un marteau manuel populaire à l'ère des marteaux pneumatiques (marteaux pneumatiques): C est toujours le bon outil pour certains travaux.
Simplicité, cohérence et précision.
C'est simple: vous n'avez pas besoin d'un environnement de développement complexe, de bibliothèques étendues ou d'une machine virtuelle.
Il est cohérent - la plupart des C écrits il y a 10 ans pourraient être compilés aujourd'hui.
Précision - cela vous permet de descendre au niveau de la machine, en connaissant les emplacements de mémoire selon les besoins. C'est idéal pour les performances et le matériel embarqué.
Ce n'est pas pour tout, mais c'est quand même un outil utile.
Je cite deux points d'une autre réponse, car ils saisissent exactement les raisons pour lesquelles j'utilise toujours C de temps en temps (ce n'est cependant pas mon principal langage de choix):
- C est simple. Il n'a pas l'expressivité de OOP ou langages fonctionnels sophistiqués, mais sa simplicité signifie qu'il peut être ramassé rapidement.
- C est mature. La dernière norme qui a introduit de grands changements est C99, et elle est principalement rétrocompatible avec les normes précédentes. Contrairement aux langages plus récents (par exemple, Python), vous n'avez pas à vous soucier de casser les changements de si tôt.
Je pense que c'est vraiment vrai. J'ai appris le C pendant les premières nuits: c'était simple, peu de mots-clés et de constructions, la plupart du travail étant effectué par les bibliothèques. Ensuite, je n'ai pas utilisé C pendant quelques années. Vers 2002, j'avais besoin d'une implémentation rapide d'un algorithme, j'ai installé un compilateur C et l'ai implémenté. Je connais le langage, je sais à quoi il sert, à quoi il ne sert pas (je voudrais jamais implémenter une application web en C!), Et il est juste là quand j'en ai besoin. Pas de surprises.
Avec C++, j'ai eu une expérience différente. Je l'ai appris vers 1995 et cela signifiait un grand changement de paradigme de l'impératif à la POO. Génial! Je l'ai utilisé pour plusieurs projets jusqu'en 1999. Pendant quelques années, je n'ai pas utilisé C++ et quand je l'ai repris (2008), j'ai trouvé beaucoup de nouvelles fonctionnalités déjà dans le langage, et encore plus prévues (introduites entre-temps en C++ 11). J'ai le sentiment que je dois réapprendre la langue.
En tant que développeur, je préfère les langages matures et stables. J'aime apprendre une langue une fois, comprendre ses principes de conception, son utilité et l'utiliser quand je pense que c'est le bon outil pour le travail. J'aime aussi apprendre différentes langues et choisir la langue qui correspond à mes besoins (C, C++, Java, Scala, Haskell, etc.). Ce que je n'aime pas, c'est d'avoir à apprendre la même langue encore et encore car elle se développe de plus en plus et n'atteint jamais sa maturité.
À mon humble avis, un langage de programmation devrait avoir une conception claire, cohérente et stable. J'aime l'approche de designers comme Niklaus Wirth: à chaque fois qu'il ressentait le besoin d'une langue différente, il en concevait une nouvelle (Pascal, Modula-2, Modula-3, Oberon). Je n'aime pas les langues qui subissent des changements importants tous les 5 à 10 ans: elles sont comme des cibles mobiles et je ne pense jamais que cela vaille la peine d'investir mon temps pour les apprendre en profondeur, car la version que j'apprends maintenant sera probablement obsolète dans quelques-uns années de toute façon.
En ce sens, C est IMO gagnant: il est bon pour certaines applications et moins approprié pour d'autres, mais il a l'avantage d'être simple et relativement stable.
Je suis surpris que personne n'ait mentionné Pire est mieux pour l'instant. Il a plus de 20 ans à ce stade, mais mérite toujours d'être lu. Bien que parfois légèrement ironique, il décrit très bien comment et pourquoi l'expédient l'emporte souvent sur l'idéal, en utilisant C (opposé à LISP) comme l'un de ses exemples centraux.
Vous vouliez probablement vous demander pourquoi les gens utilisent C au lieu de C++ malgré le fait que lorsque vous avez un compilateur C, vous avez également généralement un compilateur C++.
- Le langage C est beaucoup plus simple que C++. Je ne connais aucune entreprise qui utilise la norme C++ complète dans sa convention de codage. Jetez un œil au style de code C++ de Google à titre d'exemple: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
- C est beaucoup plus rapide à compiler. Merci au manque de constructions difficiles à compiler.
Rien. TIOBE est un indice sans valeur. Si vous regardez réellement leur mesure, c'est au mieux une supposition absolue.
Beaucoup de logiciels hérités
De nombreuses entreprises ne peuvent pas changer instantanément tout leur code en C++ ou similaire.
De nombreuses entreprises ne peuvent pas se permettre de modifier leur code.
De nombreuses entreprises peuvent se permettre de modifier leur code, mais s'en moquent ou sont "bon marché".
De nombreuses entreprises sont en train de migrer, mais pas encore terminées.
Orientation des objets cachés
(Non orienté objet) Code source C conçu comme code source C orienté objet, applications modélisées avec Orientation Objet et codées avec "C pur", ou outils traduisant de "C++" ou d'autres O.O. progr. lang en C.
J'ai entendu dire que certains jeux vidéo se faisaient de cette façon. Certains outils multiplateformes et la bibliothèque d'interface visuelle GTK (GObject, GLibrary) pour GNome Linux O.S. distributions.
Parce que C a une énorme base d'utilisateurs. Oui, c'est un peu un catch-22, mais quand je pose une question sur C sur StackOverflow, j'obtiens la réponse presque instantanément. La même question sur Python pourrait prendre des heures pour obtenir une réponse.
En ce qui concerne C++, c'est IMO plus compliqué à apprendre. De plus, après avoir essayé OOP pendant 10 ans, je trouve que ce n'est pas toujours utile, et il est souvent plus facile d'utiliser à la place une programmation procédurale.
Je vois que certains des répondants expliquent pourquoi C est le plus populaire, il existe depuis longtemps, il est disponible sur la plupart des plateformes, gratuit, etc.
Mais la même chose peut être dite à propos d'autres langues, Pascal gratuit par exemple - c'est gratuit et pris en charge pour à peu près toutes les plates-formes.
Pascal a été inventé vers 1970, C a été inventé vers 1972, donc je pense que Pascal existe depuis aussi longtemps que C.
Personnellement, je pense que C est le langage le plus populaire car il y a juste plus de code open source disponible pour être réutilisé par n'importe qui. Et oui, c'est un niveau inférieur à Pascal, donc ça se rapproche de Assembly mais c'est beaucoup plus lisible que Assembly.
Je pense qu'il y a bien trop de langages de programmation. En tant que programmeurs, nous devons connaître la plupart des plus importants, mais à la fin, cela ne devrait pas être nécessaire. Un langage de programmation peut être mis en œuvre pour tout faire, de la création de sites Web aux jeux informatiques iOS.
C semble être ce langage global, mais j'aimerais que ce soit quelque chose comme Object Pascal. Pourquoi Object Pascal, c'est un langage de programmation plus lisible, OOP a tendance à être plus réutilisable et moins sujet aux bogues (à mon avis) que C.
Les applications très volumineuses sont plus faciles à gérer avec Object Pascal qu'avec C/C++.
Quant à avoir un langage de programmation qui a été certains depuis les années 70, et à ne pas aimer les langages qui changent tous les 5 ou 10 ans. Au fil du temps, la technologie avance et les méthodes de programmation s'améliorent. Si une langue change radicalement toutes les quelques années, elle n'a probablement pas été bien pensée par son concepteur. Mais de 1970 à 2012, c'est presque un demi-siècle, il est normal de modifier un langage à cette époque pour intégrer les avancées utilisées dans le développement de logiciels.
C lui-même a été révisé plusieurs fois. Donc, ce n'est pas mieux que les autres langues de ce point de vue.