« Shabbat de ramadan | Derby parisien » |
Amis du goret-codage, des GOTO's calculés, des IF's arithmétiques, des blocs COMMON et des EQUIVALENCE's, vous devriez commencer à comprendre que mon langage de programmation de prédilection est le FORTRAN et que je ne parle C que contraint et forcé, lorsque j'ai des choses subtiles à faire avec la mémoire du calculateur ou qu'il me faut écrire une interface graphique à grands coups de X11/Xt/Xm en d'autres termes Motif que je parle — heureusement pour moi — dans le texte. Si je m'écoutais, j'écrirais pourtant tout dans deux langages issus de mes réflexions les plus tordues — qui a dit avinées ? —, les RPL/2 et RPL/C, qui comme tout le monde sait, comportent une extension Motif sous la forme d'un module motif.rplso
(rplso pour RPL/2 shared object). Il doit certainement rester un tas de problèmes dans ces deux langages, mais au moins, je sais qui engueuler lorsque ça ne fonctionne pas. D'un autre côté, malgré le nombre d'utilisateurs qui commence à devenir important, les rapports de dysfonctionnement sont plutôt rares, signe s'il en est qu'on arrive à écrire des choses propres en restant strictement dans les bornes imposées par le C (en mouture C99) et le FORTRAN (en versions 1977 et 2003). Il faut dire que j'ai écrit des dizaines de lignes de code en C pour l'armée française, plus exactement pour la Délégation Générale de l'Armement, et que, si les militaires marchent au pas, les codes sources de leurs applications ont eux-aussi le petit doigt sur la couture du pantalon si vous voyez bien ce que je veux dire, ce dont je doute pour les plus jeunes qui n'ont pas eu la joie de faire leur service militaire…
Autant le dire tout de suite, pour moi, en dehors de la programmation fonctionnelle, il n'y a point de salut. La programmation orientée objet est un paradigme que je n'arriverai jamais à comprendre. Pourtant, je vous promets que j'ai essayé. J'ai tenté l'écriture de choses en C++, en Ada 95 et même en Java, c'est vous dire, mais je suis toujours revenu à mes premières amours. Pour être tout à fait exact, je pense ne pas comprendre l'intérêt de la programmation orientée objet, voire, j'arrive à penser certains jours — et de plus en plus souvent — que c'est une débauche d'énergie pour rien et qui ne sert au développeur médiocre qu'à masquer sous un vernis de concepts abstrus et mal maîtrisés son inculture et son indigence crasse.
Le RPL/2 est un langage fonctionnel impur utilisant les notations algébrique ou polonaise inversée, fruit de plusieurs années de réflexions autour des langages de programmation et dont la documentation est disponible au bas de cette page. Il faudrait que je trouve le temps de l'achever. Elle me sert pourtant à tester les développeurs qui veulent travailler avec moi. Ce n'est pas par vice, simplement parce que mon travail consiste à implanter des algorithmes sur des machines massivement parallèles et que ce langage est le seul langage efficace pour le faire. J'ai pourtant essayé des choses comme OpenMP sans véritable satisfaction. Il masque par exemple tous les problèmes de concurrence qui peuvent apparaître sur des calculateurs parallèles sans limiter les possibilités du développeur. Il est donc un excellent compromis entre un langage comme le C qui permet de tout faire, mais à la main, et un truc ou un grand machin — suivez mon regard, non, je ne parle pas d'OpenMP qui fonctionne bien mais n'est pas adapté à mon problème — issu des techniques de programmation orientée objet qui permet de programmer des calculateurs parallèles mais sans vraiment savoir ce que l'on fait.
Je mets donc mes candidats devant une machine avec une documentation complète, un éditeur de texte de base — vim pour ne pas le citer parce que je ne suis pas assez pervers pour les mettre devant emacs, la plupart utilisant difficilement deux doigts pour taper un texte —, un compilateur RPL/2 et un cahier des charges minimaliste pour regarder leurs réactions et la façon qu'ils ont de résoudre le problème posé sachant que le programme demandé est presque à la portée du premier venu. Il suffit de savoir lire une documentation en français et d'avoir les idées claires.
À ce moment, je peux avoir plusieurs réactions totalement différentes. Le candidat peut s'effondrer après avoir paniqué ou, plus rarement, résoudre le problème demandé. Ce qui est amusant, ou désolant c'est selon, c'est que dans la plupart des cas, il va essayer de reproduire dans un langage fonctionnel, le schéma qu'il aurait utilisé dans un langage objet, créant le nouveau paradigme de la programmation orientée abjecte.
Reproduire les techniques de programmation objet dans un langage fonctionnel monte une méconnaissance totale de l'outil informatique et de son fonctionnement. En creusant, on se rend compte sans peine que les candidats qui tombent dans ce travers n'ont étudié dans toute leur formation que le langage Java. La conséquence directe est que la génération montante des développeurs, outre d'être majoritairement incapable d'utiliser autre chose qu'un langage orienté objet, ne connaît pas les bases du fonctionnement de l'outil informatique et imagine qu'un processeur comprend directement les objets créés par leur programme. Jamais ils n'ont pris conscience qu'un compilateur est un programme qui transforme un algorithme écrit dans un langage de programmation quelconque en un langage binaire strictement impératif et que le bytecode Java, contrairement au code source, n'est plus un langage objet.
Et c'est comme ça qu'on retrouve du code inutilisable chez des stagiaires, que des salariés veulent être payés très cher parce qu'ils connaissant Java alors que leur production est indigne d'un développeur C débutant et que la qualité des logiciels est en chute libre depuis quelques années. Lorsque j'ai commencé la programmation, tous mes programmes étaient testés une fois qu'ils fonctionnaient avec un programme singe — un truc qui se comportait comme si un singe était assis devant la console et appuyait n'importe où sur le clavier. Certains jours, j'aimerais ressortir un tel programme pour voir combien de temps tiendrait un programme écrit par cette race de développeurs. C'est juste un rêve, avant d'utiliser un programme singe, il fallait déjà que le programme à tester fonctionne normalement…
Tout programmeur devrait commencer par faire de l’assembleur (pendant un mois), histoire de voir qu’un ordinateur n’est pas une boite noire à orienter des objets.
Ensuite il pourrait s’attaquer au C ou Fortran selon les applications. Au final si le besoin de programmation OO est impératif, pourquoi pas, mais il aurait à l’esprit ce qui se passe dans les coulisses.
L’assembleur est de nos jours réservé à une élite. Même les stagiaires que j’avais à l’époque où je faisais beaucoup d’électronique et de traitement du signal ne savaient plus coder en assembleur. Les voir coder sans vergogne des FFT en C++ pour générer un binaire allant dans un DSP Texas me déprimait déjà… Naturellement, le tout en virgule flottante, parce que je n’ai jamais réussi à leur faire comprendre l’intérêt des formats à virgule fixe. Pour comprendre cet intérêt, il faut avoir mis les mains dans les ALU et FPU au niveau du transistor, voire du séquenceur.
Il est illusoire de mettre un développeur face à un processeur sparc - je ne parle même pas d’un x86 qui est une aberration du point de vue strictement technique. C’est impossible parce qu’ils n’ont pas les notions de base de fonctionnement d’un système informatique. Pour attaquer en assembleur, il faut avoir des idées très claires et surtout réussir à les formaliser correctement.
Ça fait plaisir de savoir qu’on fait partie d’une élite :)
Là où je bosse, on est 2 (sur 3) à lire l’assembleur (x86, pas eu l’occasion de faire autre chose) dans le texte et à aimer le C. Le 3e… il ressemble plus à la description de tes postulants :)