Je développe en C sur mon temps personnel, sous Linux, et en Java pour mes clients. Voilà pourquoi c'est une excellente source de progression professionnelle.
Raison 1 : obligé de faire de la qualité
Deux éléments majeurs manquent quand on développe en C avec un passé de Java-iste : pas d'objet, et pas de gestion automatique de la mémoire. Allons y pour les malloc / free, allons y pour ne plus disposer d'interfaces (encore que... voir mon article précédent), plus de surcharge, et plus de polymorphisme. On se sent revenir à l'age de pierre, et bâtir un projet ressemble à passer des mois sur des notions de base (listes, maps, manipulation de strings). Du coup, la mise en place d'une fonctionnalité est un chemin de croix qu'on espère ne parcourir qu'une seule fois. On fait donc du code robuste. On veut surtout éviter de le reprendre plus tard, de revenir sur quelque chose sur lequel on a sué et (parfois) pleuré de colère (en tous cas, moi ça m'est arrivé). Et du coup, on teste à fond. On documente à fond. On pense à "son soi du futur" qui voudra éviter de revenir sur une implémentation. On va donc vraiment travailler son style de programmation pour que le code soit impeccable et facile à reprendre. Et ça, c'est une qualité fondamentale.
Raison 2 : obligé de faire simple
Ce point là se comprend d'autant mieux quand on sait que Java vient avec une API gigantesque, où coder une structure de donnée soi même n'arrive pour ainsi dire jamais. Le langage en lui même est tellement simple qu'il devient aisé de multiplier les interfaces, d'oublier YAGNI pour partir sur "un système générique qui procède par introspection et qui se base sur les annotations des classes pour décider si ceci ou cela". Bref, du code dont on est fier quand on l'écrit mais qui nécessite un passage de connaissance d'une demi journée quand votre collègue reprend le projet... Et en C, c'est tout simplement impensable. On ne peut pas, intellectuellement, dépasser une certaine complexité, qui du coup dépend des gens et de leur expérience. Au delà, le code ne nous parle plus, on n'a pas idée de ce qu'il fait, et de toute façon, il ne marche pas. La complexité de la gestion de la mémoire quand on a perdu l'habitude est déjà un problème en soi. Inutile donc de faire du code ésotérique qui va rendre le code ingérable, ou tellement documenté que les commentaires eux même ne sont plus d'aucune aide. Donc, on simplifie une conception, on dégage une structure de donnée trop compliquée au profit qu'une liste ou de quelque chose de directement efficace. On fait simple parce que le langage lui même sera (en tous cas au début) bien assez complexe.
Raison 3 : faire enfin de l'algorithmique
Java, au sens large, vient avec des API complètes, couvrant à peu près tous les besoins possibles. De plus, des projets comme spring rendent encore la tâche de développement aisée. Il suffit de poser quelques annotations et un objet devient sérialisable, une méthode devient appelable via REST. J'ai eu souvent l'impression en développant en Java de ne faire que de l'assemblage de composants écrits par d'autres. Donc, soyons clairs, en algorithmique, j'ai régressé. Le C, lui, n'a pas tout ça. Bien sûr, il existe des librairies, comme Glib, mais on n'a de toute façon pas ce même niveau de maturité, ou autant de code disponible. Java, au sens large, est formidablement en avance là dessus. Et par conséquent, coder en C, c'est accepter de coder des choses soi même, beaucoup. Personnellement, je n'aime pas glib. Donc, j'ai codé mes listes, mes maps, mes ensembles ordonnés (ah, les arbres rouge et noir), mes graphes avec des parcours de graphe. Et de reprendre ça rend humble, vraiment.
Raison 4 : comprendre les mécanismes objets
On vous l'a souvent dit : c'est quand on perd quelque chose, ou quelqu'un, qu'on mesure ce qu'il amenait. En C, pas d'objet. Pas de polymorphisme, pas de surcharge. Ce sont vraiment les deux choses qui manquent le plus. La gestion à la main de la mémoire est un coup à prendre, et en quelques mois, on y arrive. C'est au fond une discipline qui devient automatique. Mais le polymorphisme... Et donc, il arrive qu'on le "réimplémente à la main". Par exemple : je code un serveur web complet (gestion des sessions, parallélisme, etc). La tentation est de mettre en place le pattern Front controller qui répond merveilleusement bien au besoin (et pour cause...) Sans objet, sans héritage, j'en reviens à faire de la composition. Et je mesure ce que je perds en passant par du C (mais il a d'autres avantages). De même, quand on dispose d'une méthode de sérialisation surchargée en Java (serialize(Integer), serialize(Float), serialize(List), etc) mais pas en C, nous voilà obligés de passer par un switch et de reprendre le mécanisme à la main ! Génial pour apprendre, une plaie à faire, et une joie indicible quand le client demande à coder en Java ! Comprendre les mécanismes objet se fait un peu "à la dure" en ne les ayant plus, donc en mesurant à quel point ils nous manquent.
Raison 5 : parce que connaitre un seul outil est une aberration
Je ne partage pas du tout l'avis de mes collègues qui me jurent que de ne connaitre qu'un seul langage permet de se concentrer donc de devenir expert. Déjà pour la raison 4 ci dessus, mais surtout parce que connaitre un seul langage, Java en particulier, c'est tout penser en POO. C'est rester de marbre devant le paradigme fonctionnel, alors que, bien employé, il apporte une solution simple aux traitements parallélisés (et pas l'objet qui induit des états). En codant en C, on découvre des nouvelles techniques : automates à états finis qu'on croise pour les regexp, et qui servent à la preuve de programmes. Comme on n'a pas d'équivalent de spring boot, et en général pas de serveur web REST embarqué tout prêt, on ne sort pas l'artillerie du micro services à chaque question de scalabilité. On pense au delà des réflexes et outils de l'écosystème Java / Spring / JPA. Le C, beaucoup moins riche que la planète Java en outils, fait qu'on va vraiment penser sa conception. Et c'est comme ça qu'on devient un vrai architecte, pas un commercial qui récite sans réfléchir les dernières évolutions de son produit fétiche.
If you enjoyed this article, please consider sharing it!
