Pourquoi apprendre le C fait de moi un meilleur développeur Java
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.
-
Categories
-
Articles
- juillet 2018
- mai 2018
- mars 2018
- février 2018
- janvier 2018
- décembre 2017
- octobre 2017
- juin 2017
- mai 2017
- avril 2017
- mars 2017
- février 2017
- décembre 2016
- novembre 2016
- septembre 2016
- août 2016
- juillet 2016
- juin 2016
- avril 2016
- février 2016
- janvier 2016
- décembre 2015
- octobre 2015
- septembre 2015
- août 2015
- juin 2015
- mai 2015
- avril 2015
- mars 2015
- février 2015
- janvier 2015
- décembre 2014
- novembre 2014
- septembre 2014
- août 2014
- juillet 2014
- juin 2014
- mai 2014
- avril 2014
- mars 2014
- janvier 2014
- décembre 2013
- août 2013
- juillet 2013
- juin 2013
- mai 2013
- février 2013
- janvier 2013
- décembre 2012
- novembre 2012
- septembre 2012
- août 2012
- juillet 2012
- juin 2012
- mai 2012
- février 2012
- janvier 2012
- décembre 2011
- novembre 2011
-
Calendar
février 2019 L M M J V S D « Juil 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 -
Meta