Chaque langage de programmation a ses clichés, plus ou moins justifiés d’ailleurs. L’idée est de donner des clichés pour quelques technos, et de voir si oui ou non ils sont justifiés. Attention la liste est loin d’être exhaustive, n’hésitez pas à la compléter, voire à troller !
Débloque les + belles offres tech en 10 mins
Le Java est ultra verbeux
Java traîne avec lui une réputation d’être horriblement verbeux. Un exemple très simple, avant si on voulait lire un fichier texte ça se passait comme ça :
BufferedReader br = null;
try {
br = new BufferedReader(new FileReader("blablabla"));
// Actually read the file...
} catch (IOException e) {
throw new RuntimeException("Read failed !", e);
} finally {
if (br != null) {
try { br.close(); } catch (IOException ignored) {}
}
}
Et encore mon code n’est pas correct étant donné qu’il faudrait créer et fermer explicitement le FileReader que je crée, ce qui ajoute encore du code. Bref si on compte on obtient… 10 lignes de boilerplate code, comme disent les Anglais, pour lire un fichier ! Il est vrai que l’implémentation des streams en Java est un joli exemple d’utilisation du pattern decorator, mais quand même, c’est horriblement complexe à utiliser dans certains cas.
Heureusement à partir de Java 7 la situation s’améliore nettement, et encore davantage avec Java 8 et les lambdas. Bref à partir de la version 7 du langage on peut réécrire le code ci-dessous comme ça :
try (FileReader fr = new FileReader("blabla");
BufferedReader br = new BufferedReader(fr);) {
// Lire le fichier
}
Autant être honnête, c’est beaucoup mieux. Mais ça n’empêche que le langage Java reste encore bien trop verbeux pour certaines choses. On pourra citer notamment les horribles getters/setters, qui ont été gérés de manière bien plus élégante en C# via le système de properties.
Je ne parlerai pas de la lenteur de Java, c’était vrai au début mais ça fait longtemps que ce n’est plus vraiment d’actualité dans de nombreux cas. Le travail d’optimisation sur la JVM a été vraiment impressionnant sur le sujet.
Le Perl est illisible
Perl est un langage très puissant, qui permet d’écrire du code très compact… trop compact. Un exemple assez extrême est ce programme de décryptage de la protection CSS des DVD. Bon allez je le mets ci-dessous :
#!/usr/bin/perl -w
# 531-byte qrpff-fast, Keith Winstein and Marc Horowitz <[email protected]>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=(
$m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72,@z=(64,72,$a^=12*($_%16
-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h
=5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$
d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^$d>>4^
$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^
(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
Oui vous avez bien vu, il tient en sept lignes. Par contre si vous arrivez à le comprendre une explication m’intéresse, parce que moi, euh, bon, … L’avantage d’un tel code est qu’il n’y a absolument pas besoin de l’obfusquer…
Bref le plus gros problème de Perl est qu’il permet d’être compact au point d’être illisible. Certains ouvrages sur le sujet l’admettent volontiers. Cela dit cette compacité a tout de même l’avantage d’être bien pratique lorsqu’il s’agit de faire de petits programmes one shot, dont on sait qu’ils sont destinés à la poubelle. Mais dès qu’on sort de ça il vaut mieux faire un minimum attention quand même, et c’est regrettable que le langage n’impose pas un minimum de contraintes.
Le C est ultra rapide
Soyons honnêtes : un code en C bien écrit et optimisé est clairement ce qu’il y a de plus rapide. Le problème est qu’il faut que le code en question soit bien écrit et bien optimisé, et là, ça devient nettement plus compliqué. Bien peu de développeurs sont en fait capables de le faire, et bien souvent on se retrouve avec du code petit nègre qui aurait mieux fait d’être écrit en Java.
Pour vous en convaincre, vous pouvez lire cet article, et bien d’autres qui en traitent. La réalité est que la JVM comporte ce qu’on appelle un compilateur Just-in-time qui analyse en permanence l’exécution du code, et à partir d’un certain temps d’exécution va compiler nativement le code pour la plateforme cible. L’avantage d’une telle approche est notamment qu’on peut ainsi bénéficier des instructions processeur disponible sur la machine telles que l’AVX, ce qui n’est pas nécessairement possible avec un code C qu’il faut compiler pour supporter un maximum de machines, et donc sans ces extensions.
Cela dit, et encore une fois, rien n’est aussi efficace qu’un code C bien écrit et optimisé. Mais les progrès de la JVM et d’autres plateformes équivalentes sont tels qu’en entreprise, à moins de vraiment maîtriser le langage, il vaut mieux oublier l’option car les gains n’en vaudront pas la chandelle. C’est au moins le cas pour toutes les applications non graphiques qui tournent sur des serveurs d’application, qu’on retrouve couramment en informatique de gestion.
Le JavaScript, c’est coder avec des bouts de ficelles
Javascript a été conçu en deux semaines voilà plus de 20 ans par Brendan Eich. Et il est vrai que pendant longtemps ce langage a été une plaie, tant le comportement des programmes différait d’un navigateur à l’autre. L’image ci-dessous décrit d’ailleurs parfaitement la situation du développement web d’il y a encore cinq ans :
Il faut reconnaître aussi que le langage a été méchamment plombé par le fait que pendant longtemps il n’était utilisé que par rapport au DOM des pages HTML.
Il est indéniable que la situation a évolué, mais quand même, on remarque que les éléments suivants demeurent :
- Les navigateurs continuent à avoir une interprétation parfois assez YOLO du code.
- Le framework à la mode change tous les six mois, aussi quand on est expert sur l’un deux on est déjà dépassé.
D’ailleurs en général on ne dira pas « je fais du Javascript » mais « je fais de tel framework qui utilise Javascript ». Ainsi une page web écrite avec Angular n’aura rien à voir avec une page équivalente écrite avec jQuery. Et manque de bol, Angular 2 est incompatible avec le 1, ce qui nécessitera une réécriture complète de nombre de sites web. Car il est important de se tenir à jour vis-à-vis du framework utilisé, sous peine que le site ne fonctionne plus avec les nouveaux navigateurs. Tout ceci fait qu’à l’heure actuelle il demeure extrêmement difficile d’avoir du code de qualité en Javascript… j’entends par là qui continue encore à fonctionner tel quel dans deux ans.
Le PHP est mal conçu
Le langage PHP est, il est vrai, un ensemble de pièces rapportées. Le tout a été développé parfois de manière pour le moins… amateure. Et c’est une des raisons pour lesquelles il a été un nid à failles de sécurité, cf. les usages de variables superglobales qui devraient être totalement bannis.
Mais force est d’avouer que comme avec Javascript l’usage de certains frameworks change radicalement la donne. On pourra citer notamment Symfony 2 et 3 et Zend framework qui permettent de concevoir votre application d’une manière très semblable à ce qui se fait avec Java et Spring. Alors certes certains outils sont franchement pourris, notamment phpunit qui m’avait cassé plein de tests en passant de la version 5.6 à la 5.7, mais quand même, avec les outils bien adaptés on arrive à un truc pas trop mal…
Ça n’empêche que l’API du langage de base est vraiment moisie. Par exemple strpos retourne FALSE quand une sous-chaîne n’est pas trouvée dans une chaîne de caractères… et je ne parle pas du nommage des fonctions, lequel n’a tout simplement aucune règle.
En bref
La liste ci-dessus est loin d’être exhaustive. Chaque langage a ses travers, et est mieux adaptés pour certaines tâches que d’autres. À nous développeurs d’en tirer la quintessence ! Et surtout n’oubliez pas : vim est bien mieux qu’Emacs. Sur ce, les trolls sont ouverts.
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
- Un java-iste espère vous faire aimer son langage fétiche…
- Clichés sur les développeurs
- Trop belle pour être dév ?
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
