J’ai déjà écrit plusieurs articles sur les langages de programmation : ceux que je connais, le modèle objet, l’utilisation de TinyCC pour créer un interpréteur, quelques remarques sur les syntaxes, ainsi qu’un article dans lequel j’expliquais les forces du PHP (et qui a reçu des réponses qui me font toujours rire un an après).
J’ai déjà exprimé clairement que mes deux langages préférés sont le PHP et le C ; le premier pour sa souplesse, son adaptabilité et la rapidité avec laquelle on atteint son objectif ; le second pour sa simplicité, son efficacité et le fait qu’il donne un accès direct et transparent à la machine.
Et c’est justement du C dont je vais rapidement vous parler. On a souvent l’impression que c’est devenu avec le temps un langage complètement has-been, et que même ceux qui veulent faire du développement compilé nativement s’orientent tous vers le C++ ; et qu’à moins que vous ne fassiez du développement embarqué (style mbed ou Arduino), choisir le C est forcément un mauvais choix.
J’ai toujours été contre cette vision des choses, mais je me disais que je devais être un peu particulier dans mon genre.
Récemment, je suis tombé sur plusieurs articles sur le web, qui m’ont fait voir que je suis loin d’être le seul à penser que les qualités du C sont toujours intactes.
Popularité
L’index TIOBE est très connu ; il mesure la popularité des langages de programmation. Devinez quel est le langage le plus populaire actuellement ?
Eh oui, il s’agit bien du C, qui se tire la bourre avec le Java depuis pas mal de temps. Comprenez bien qu’il s’agit d’un indice de popularité, pas d’un benchmark de performances ou une étude sur les qualités intrinsèques des langages ou sur les fonctionnalités qu’ils proposent.
Non, cela montre simplement que le C est toujours un langage très utilisé de par le monde.
Performances
C’est un peu une évidence, mais ça va toujours mieux avec des chiffres. Je connais deux sites qui proposent des benchmarks entre les langages de programmation, basés sur différents algorithmes (certains très théoriques, d’autres plus proches de l’usage réel) : The Computer Language Benchmarks Games et The Great Win32 Computer Language Shootout.
Je vous laisse regarder par vous-même, mais les différents compilateurs C se retrouvent régulièrement en tête − ou dans le peloton de tête − des résultats.
Les autres exemples
Pour tout vous avouer, l’idée d’écrire cet article a commencé à germer en lisant un post sur le blog de Damien Katz, le créateur de CouchDB et directeur technique de CouchBase. Ce post a pour titre The Unreasonable Effectiveness of C.
Dedans, il explique pourquoi il apprécie le C, et pourquoi de plus en plus de parties du CouchBase Server sont écrites en C (il est écrit en Erlang à la base). Son article est très clair, et le point de vue de quelqu’un avec autant d’expérience est forcément très intéressant. Je vous invite à le lire en entier.
Juste pour le plaisir, je vais vous traduire le premier paragraphe :
Pendant des années j’ai essayé de m’éloigner du C. Trop simple, trop de détails à gérer, trop vieux et plein de cochonneries, de trop bas niveau. J’ai eu des amours intenses et torrides avec Java, C++, et Erlang. J’ai construit des choses dont je suis fier avec chacun d’eux, et pourtant ils m’ont tous brisé le cœur. Ils ont fait des promesses qu’ils ne pouvaient pas tenir, créé des cultures qui mettent l’accent sur de mauvaises choses, et ont fait des compromis dévastateurs qui font souffrir douloureusement au final. Et je reviens à chaque fois au C.
Plus récemment, je suis tombé sur un article (en fait deux) écrit par Martin Sústrik, le co-créateur, architecte et principal développeur de ZeroMQ. Je vous ai déjà parlé de cette bibliothèque réseau (là, là et là, ainsi que lors de conférences), c’est un incroyable morceau de logiciel.
Son article s’intitule Why should I have written ZeroMQ in C, not C++. Difficile de faire plus explicite. Là encore, je vous conseille de le lire en entier (ainsi que la seconde partie). C’est assez technique, il parle des exceptions et de la gestion mémoire, notamment. On peut ne pas être d’accord avec sa vision des listes intrusives, mais là encore son expertise rend son opinion intéressante.
Pour info, il a réimplémenté ZeroMQ en pur C. Le projet s’appelle nanomsg, j’ai commencé à l’utiliser, c’est une tuerie.
Et pour moi ?
J’ai commencé tout récemment à travailler sur un nouveau projet (pour occuper mon temps, comme s’il m’en restait de libre…). Si ce projet aboutit, il n’aura d’intérêt que par ses performances. Je me suis donc tourné vers le langage le plus rapide que je connaisse. Et comme à chaque fois que je refais un peu de C, c’est un grand plaisir.
Évidemment, il faut un peu plus de temps que si je codais les choses en PHP (ou un autre langage interprété), particulièrement quand on commence à vouloir manipuler des chaînes de caractères, des listes ou des tableaux associatifs. Et il faut courir après les bibliothèques nécessaires, là où les autres langages fournissent beaucoup de choses de base.
Mais l’impression de puissance est grisante. La mémoire est là, à portée de main, on en fait ce qu’on veut. On contrôle exactement les threads et les processus à notre guise. Pas d’overhead, pas de choses cachées, pas de “magie” qui fait le boulot à notre place. La maîtrise du code est totale, et en contrepartie il n’y a aucune aide derrière laquelle se réfugier.
Avantage secondaire, du code écrit en C compile partout et n’a pas d’autre dépendances que celles que vous avez choisies.
Merci pour cet article.
Je suis toutefois obligé de revenir sur un point. l’indice TIOBE représente les recherches faites sur l’internet. On a donc non pas un indice de popularité au sens stricte du terme.
Oui, sa pertinence est semble-t-il assez remise en question. Mais bon, ce n’est pas complètement fumé non plus, donc à défaut d’autre chose… 🙂
Je trouve que C++ ou C ont les mêmes performance, de toute façon à toi de connaitre ce que va produire ton compilateur. Que celui qui n’a jamais regardé le code assembleur généré lève la main 😉
Après avoir testé pas mal de chose pour Linux (Ruby, Mono, …) nous sommes revenus au C++ (vive Boost::Asio) pour faire de la socket qui « pulse et scale ». L’occupation CPU est toujours étonnante (dans le bon sens), et économiser du hardware quand tu dimensionnes à plusieurs centaine de milliers d’utilisateurs simultanés c’est bien pour le portefeuille (et la planète).
C’est pour cela que j’adore .NET, l’appel au C++ est hyper simple à faire.
Présentation en C# / WinForm / ASPX et traitement en C++ : une super complémentarité.
Salut Amaury,
en réponse à « a défaut d’autre chose » concernant l’indice TIOBE voir cette page :
https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY-of-Programming-Language
Les résultats sont moins flatteurs pour le C mais ça ne change pas grand chose par rapport au contenu de l’article je pense.
Bien vu. Effectivement, ça ne change rien sur le fond. Même là on peut considérer que c’est toujours un langage très populaire.
« l’impression de puissance est grisante » : jouer avec pointeurs est vraiment un truc qui fait du bien. Savoir exactement ce qu’on envoie, pouvoir économiser des swap de variables en changeant simplement des valeurs de pointeurs.
Win32 Shootout
2003-11-25.17:52:55 [BUILD] c: \ jdk \ bin \ javac ackermann.java
Java (TM) 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02)
@Arkh : On est d’accord 🙂
@Isaac : Ah oui, effectivement, ça fait tâche… J’accorde d’ailleurs plus de crédit au Computer Language Benchmarks Games (je trouve les conditions de test plus variées et détaillées), mais je ne suis pas allé jusqu’à vérifier les versions des compilateurs.
C rapide ? Oui et non. J’ai déjà dégouté plein de type en leur montrant que mon code Python était plus rapide que leur code C/Fortran.
Mon secret: les librairies de bas niveau. Pour mon domaine (simulation numérique), si vous utiliser le C de base pour faire des opérations sur des vecteurs vous serez très lent.
Bien utiliser ces librairies (genre BLAS) est complexe en C (code multithread, cluster, mélange assembleur SSE/C/Fortran, …) donc les gens le font pas.
En Python l’utilisation de ces librairies est transparente donc mon code est très souvent plus rapide.
Je vois trop souvent du « tout en C ». J’ai des collègue qui génèrent des plots en C (et aussi des qui parsent des GB de données en VBscript…).
Sans compter les dégats que cela produit: code illisible, bourré de fautes, …
Perso, je recommande:
– Tout coder en Python (ou PHP/Ruby/Perl)
– Profiler le code
– Recoder éventuellement certaines parties en C/C++/Fortran (perso en C, je trouve le C++ très complexe et le Fortran a très mal vielli)
– De mon expérience, le travail de recodage concerne environ 5% du code
Après je sais pas si cette philosophie de choisir deux langages pour un projet est utilisable pour du dev web.
NB. Je viens de découvrir votre blog et j’y ai trouvé pleins de poste super intéressant. Vous êtes même lu en suisse germanophone…
@hans : Merci, je suis flatté d’être lu par des voisins non francophones ! 🙂
Je suis tout à fait d’accord avec ta vision. Et de manière générale, c’est comme ça que je procède, sauf qu’en temps normal, je suis plus proche du 100% PHP… 😉
L’utilisation de langages interprétés apporte plein d’avantages : le code est plus rapide à écrire, plus facile à maintenir et faire évoluer ; comme il est de plus haut niveau, le code est souvent plus concis et moins sujet aux bugs (il suffit de voir le nombre de lignes pour faire une connexion réseau en C versus la même chose en PHP/Perl/Python/Ruby/Lua/…).
L’utilisation de bibliothèque de bas niveau permet effectivement de concilier les choses, et de profiter du meilleur de chaque monde. Sans oublier que certains usages ne se prêtent pas du tout au C (j’ai fait du développement web en C il y a plus de 10 ans, pour le fun, mais je ne le ferais plus maintenant).
Mais ce que je voulais communiquer, c’est que lorsque je reviens au C je revis un peu. Je redécouvre certains aspects que j’ai tendance à perdre de vue à force de travailler avec d’autres langages. Les témoignages de Damien Katz et Martin Sústrik illustrent la même idée, je pense.
C’est marrant parce qu’on a ecrit des articles similaires professant notre amour pour des langages radicalement opposés sans se concerter 🙂 Comment je suis tombé amoureux de ruby.
Personnellement, ce que j’aime par dessus tout dans ruby, c’est la vitesse d’implémentation et de prototypage, et comme mon énergie est limitée, c’est vraiment un facteur crucial (et la syntaxe visuellement très dépouillée, qui est très reposante).
Mais je comprend totalement ce que tu dis sur C, je m’y suis remis l’année dernière et j’aimerais vraiment maitriser aussi bien que toi afin de pouvoir coder un vrai projet en C. En l’état actuel de mes connaissances, je suis capable de lire, débugguer et modifier du code, mais pas d’écrire un projet from scratch, pas assez d’expérience. D’ailleurs, c’est aussi un des pb de C: la barrière a l’entrée est bcp plus grande! Ruby, j’apprend au fur et à mesure, C, il me semble que cela serait beaucoup plus compliqué. Peut-être que je me trompe, d’ailleurs, et qu’avec un peu de pratique, je m’y mettrais facilement.