Magazine Focus Emploi

Les langages de programmation – Partie 1 : Ce que je connais

Publié le 06 janvier 2012 par Abouchard

Régulièrement (enfin, disons tous les 3/4 ans) je me pose des questions existentielles au sujet des langages de programmation. Pourquoi est-ce que j’aime tel langage, pourquoi je déteste tel autre, qu’est-ce que je pourrais vouloir et que je n’ai pas, et ainsi de suite…

Ne me demandez pas pourquoi, mais ça me reprend en ce moment. Ça va sûrement repartir aussi vite que c’est venu, mais ça amène quand même quelques réflexions.

Je pense écrire 3 articles sur le sujet. Dans celui-ci, je vais lister les langages que je connais, histoire de situer un peu les choses. Dans le suivant, je parlerai un peu du modèle objet sous un angle inhabituel. Pour terminer, je « réfléchirai à haute voix » sur ce que j’attends d’un langage de programmation, et pourquoi je serai toujours un éternel insatisfait.

BASIC

C’est le premier langage que j’ai appris. Quand j’étais gamin, dans les années 80, il y avait deux émissions télévisées au Québec − Octo-puce et Octo-giciel − qui enseignaient entre autre à programmer en Basic. C’est comme ça que j’ai commencé à programmer sur papier en rêvant au jour où j’aurais un ordinateur. Environ 10 ans plus tard, j’ai passé un couple d’années à programmer en Visual Basic ; c’était avant de commencer mes études d’informatique, et je croyais savoir programmer…

Ce que j’en retiens, c’est que le Basic, le « vrai » (celui des Apple II et Commodore 64) était en fait complètement imbitable. Après coup, j’ai compris en partie pourquoi Dijkstra avait la dent si dure à son encontre.
Malgré tout, ses déclinaisons successives, depuis le QuickBasic, les STOS et AMOS, jusqu’au RealBasic et le VB.NET, en ont fait un langage moderne et utilisable.

Moderne et utilisable, mais je n’ai désormais strictement aucune envie de coder en Basic.

Javascript

Je me suis intéressé au Web dès 1995. Je me suis mis alors au HTML, et même à cette époque cela incitait à rapidement se pencher sur le Javascript. Les premières années, je n’en ai fait qu’un survol, mais j’ai fini par mettre en œuvre des techniques assez poussées (notamment concernant la programmation orientée objet en Javascript) qui me sont encore utiles aujourd’hui au quotidien. Je suis même passé par une phase de développement assez intensive à base de XUL, où tout le code est réalisé en Javascript.

À une époque, j’étais assez fan du Javascript. J’aimais sa simplicité et sa malléabilité. J’ai imaginé l’utiliser pour des usages très divers. Pour les développements « client lourd », après avoir développé en XUL, j’en suis un peu revenu ; comme expliqué dans un précédent article, je me suis fatigué de devoir taper 8 lignes de code illisible pour simplement lire le contenu d’un fichier. Pareil pour les développements côté serveur ; j’ai longtemps pensé que le Javascript combinait assez de qualités pour s’y montrer à son avantage ; cette idée va et vient, depuis le serveur de Netscape dans les années 90, jusqu’à  des projets comme CommonJS et Node.js.
J’espère que Mathieu ne m’en voudra pas, mais l’ensemble du langage me paraît maintenant trop bancal pour sortir de l’usage Web client qui est sa spécialité. Entre le modèle objet incomplet, la bibliothèque standard plutôt limitée et une évolution très lente (qui ne laisse pas apercevoir d’améliorations profondes à courte échéance), je préférerai toujours d’autres solutions.

C

Ce fut la grande révélation de ma vie. Ce que j’apprécie dans ce langage, c’est sa simplicité et sa limpidité. Quelques types scalaires, des structures (et des énumérations et des unions), des fonctions… et des pointeurs au milieu de tout ça. Difficile de faire plus évident. J’ai acquis une certaine expertise en C ; durant mes études j’ai fait du développement kernel (Linux et BSD), et par la suite j’ai travaillé dans le développement système et réseau. C’est formateur.

On entend souvent dire que le C n’est qu’un assembleur à peine amélioré… C’est tellement faux ! Par contre, ce qui est certain, c’est qu’il est quasi-impossible de faire des exécutables plus rapides et plus petits que ceux écrits en C. Bon, il n’est évidemment pas exempt de défauts, mais qui sont inhérents à ce qu’il est intrinsèquement. Si vous savez ce que vous faites, le C est un outil redoutable ; par contre, si vous vous permettez des approximations, vous ne vous en relèverez pas.

Aujourd’hui, je ne code plus du tout en C, au profit du PHP (j’en parle juste après). Cela m’ennuie un peu, le manque de pratique émousse le niveau d’expertise que j’avais ; mais d’un autre côté, si on peut coder plus vite sans avoir besoin des performances maximales…

Perl

J’ai appris les bases du Perl durant mes études d’informatique. Comme disait mon professeur d’administration système (Marc Espie, l’un des principaux contributeurs à OpenBSD), “il faut savoir laisser son compilateur au placard quand on a juste besoin d’un petit script”. Plus tard, j’ai travaillé pendant 4 ans dans une entreprise où le Perl était le principal langage de développement ; j’y ai considérablement amélioré ma connaissance du langage.

J’ai apprécié ce langage, qui est particulièrement souple et puissant. Il intègre nativement les listes, les tableaux associatifs et les expressions régulières, ce qui est très pratique au quotidien. Le CPAN est un fantastique outil centralisé pour trouver des bibliothèques, tellement complet qu’il est difficile à mettre en défaut.

Par contre, j’ai aussi été profondément gêné par les bizarreries du langage. La syntaxe qui autorise d’écrire certaines choses « à l’envers ». La notion de référence qui casse les noix quand on manipule des types scalaires (c’est comme des pointeurs… mais ça n’a rien à voir). Les variables magiques (on aime ou on déteste, moi je ne suis pas fan). Le modèle objet est incomplet bien que largement utilisable. Mais surtout, c’est un langage qui incite presque à faire du code illisible, tellement il permet d’écrire les choses de plusieurs manières différentes ; si vous n’êtes pas vigilant, vous finissez par privilégier les écritures les plus denses mais les moins maintenables.

PHP

J’ai commencé à utiliser le PHP dans sa version 3 en 1999. Pendant plusieurs années j’alternais mes développement serveur entre le PHP et le C. J’ai fini par m’habituer aux qualités du PHP, sa simplicité et sa bibliothèque très fournie. Sa syntaxe très inspirée de celles du C et du Perl me convenait très bien, et j’ai fini par me rendre compte que recompiler un exécutable à chaque modification d’un site web, c’est quand même pénible.

J’ai suivi les évolutions successives du langage, à travers ses versions majeures (4, 5, 5.3) et les différentes améliorations qu’elles ont apportées. J’apprécie le PHP pour sa souplesse et son équilibre entre contrainte et permissivité. Syntaxiquement, son intégration des tableaux associatifs est particulièrement réussie, et son modèle objet est complet depuis 2004 (version 5).

La quasi-totalité de mes développements se font désormais en PHP. J’ai réalisé quelques projets assez pointus avec ce langage (FineFS, Temma), et je suis très heureux de profiter des facilités qu’il offre.

C++

J’ai fait du C++ à l’école, je l’ai même utilisé pour développer un projet sous licence libre (Headerbrowser). C’est un langage très puissant, qui comble la plupart des lacunes du C, tout en gardant une syntaxe très similaire (au contraire de l’ObjectiveC, par exemple).

Malgré tout, je me suis toujours senti « le cul entre deux chaises » avec le C++. Si j’ai un grand besoin de performance ou de portabilité, j’aurai tendance à choisir le C pour sa simplicité. Si je cherche un langage de haut niveau, je prendrais le PHP pour son typage faible et sa gestion dynamique de la mémoire. Certaines fonctionnalités du C++ complexifient la syntaxe à l’extrême. Nul doute que cela ne soit qu’une question d’habitude, mais je n’arrive pas à m’y faire.

J’ai parfois hésité à écrire du code C++ comme si je codais en C, en utilisant seulement les fonctionnalités qui m’intéressaient (les objets et les exceptions, par exemple). Mais j’ai lu tellement de choses disant que c’est une mauvaise idée… Je vais peut-être revenir là-dessus, parce que les donneurs de leçon qui disent que tel ou tel truc, « il faut le faire à fond ou pas du tout », j’ai fini par ne plus les écouter.

Java

J’ai appris le Java durant mes études d’informatique. Pour quelqu’un qui s’orientait vers le développement système, ce langage ne jouissait pas d’une bonne réputation.
Je l’ai au final très peu utilisé en dehors du cadre académique. Dans toute ma carrière, je n’ai qu’une expérience d’un an en JEE.

J’ai trouvé que le Java était un plutôt bon langage. Sa grande force vient de sa bibliothèque standard d’objets, qui est très complète et très proprement structurée. J’ai par contre connu des problèmes avec l’environnement général, pas évident à mettre en place au premier abord.

Dans le cadre du développement Web, j’ai trouvé le JEE d’une lourdeur incroyable. L’ensemble des technologies impliquées est vaste et complexe. À mon sens, inutilement vaste et complexe. Beaucoup de choses semblent séduisantes d’un point de vue théorique, mais leur utilisation est malaisée, ce qui allonge les temps de développement et les coûts associés.

Au final, j’ai un peu les mêmes griefs que pour le C++. Pour un langage qui se veut de haut niveau, il lui manque beaucoup de facilités d’écriture, tout en manquant de clarté sur plein de points. S’il fallait faire un match en C++ et Java, je les mettrais ex æquo. Le Java me semble plus clair, et son API standard est ultra-complète ; par contre, le C++ est plus dans mes habitudes par son absence de machine virtuelle et sa compatibilité avec le C (aussi bien le code que les bibliothèques compilées).

Fortran

J’en parle juste pour déconner. J’ai fait un peu de Fortran quand j’étais en fac de biologie. Je n’en garde presque aucun souvenir. Il n’empêche que ce langage a continué à évoluer, qu’il est toujours beaucoup utilisé dans la communauté scientifique, et que c’est l’un des langages les plus facilement optimisable sur des architectures réparties (il n’y avait pas d’allocation dynamique de la mémoire jusqu’au Fortran90).

Pascal

Là aussi, j’en parle juste pour le fun. Quand j’étais petit et que je commençais à m’intéresser à l’informatique, un ami informaticien qui avait fait le MIT m’a donné un livre traitant de la programmation en Pascal. Je n’y ai pas compris grand chose sur le moment. Bien plus tard, alors étudiant en informatique, je me souviens avoir aidé des amis qui étaient en prépa, et qui bûchaient sur de la programmation en Pascal. J’ai pu comprendre sans problème les bases du langage en quelques secondes. Et j’ai compris de quoi mon prof de C parlait, lorsqu’il évoquait les différences entre les langages créés par les mathématiciens suisses et ceux créés par les hippies américains. Niveau syntaxe et clarté, pas de soucis, je préfère les baba-cools.

Lisp et OCaml

Oui, je continue avec les trucs à la con. Juste pour la petite histoire, j’ai eu à développer un interpréteur de Lisp durant mes études. La syntaxe est tellement simple que ce type d’interpréteur n’est vraiment pas très compliqué à coder. Bon, de là à vouloir coder en Lisp au quotidien, c’est une autre paire de manches. À une époque, c’était une idée tout à fait valable quand on voulait intégrer un langage dans un logiciel, pour permettre d’écrire des extensions (comme dans Emacs, par exemple).

L’OCaml, je l’ai étudié durant mes études. Avec le Lisp et l’OCaml, je me suis vite rendu compte que j’avais beaucoup de mal à me faire aux langage fonctionnels (je sais, OCaml peut être considéré comme à la fois fonctionnel et impératif, mais zut). J’ai sûrement été trop marqué par les langages procéduraux, mais on peut quand même remarquer que les langages fonctionnels sont globalement l’apanage des chercheurs et des mathématiciens, alors que les langages procéduraux sont utilisés par « ceux qui veulent faire du vrai code » ; je forcis le trait, mais il y a un peu de vrai là-dedans.

Et pourtant, on peut voir l’héritage des langages fonctionnels se cacher dans le Javascript, ou dans des notions comme le map-reduce. Il est important de connaître le principe, même sans l’utiliser au quotidien.


Retour à La Une de Logo Paperblog

A propos de l’auteur


Abouchard 392 partages Voir son profil
Voir son blog

l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte