Enfin ces capacité a gérer le flux de texte, même si ça reste encore une des grandes forces de Perl, est maintenant beaucoup moins critique. La majorité des autres langages ont des capacités similaire ou suffisante dans ce domaine.
Je souhaite rebondir sur ce sujet particulier.
En fait pour situer le contexte, j'ai bossé ces dernières années sur une très grosse application de traitements de données. La code-base, jusqu'à la fin de l'année dernière, était majoritairement en Perl 5, et depuis, on a décidé de la porter vers Python 3. Après plusieurs mois de développement, on a une différence très nette en termes de qualité de code, mais pas que. Ce passage a permis de résoudre intrinsèquement pas mal de casseroles qu'on s'était longtemps traînées, comme :
-
la gestion des encodages de chaînes de caractères. Elle se fait à coups de scotch en perl 5 (des flags sur la structure interne des chaînes de caractères, qui ne donnent lieu à aucune vérification particulière), et de façon explicite en Python. Le fait que Python 3 manipule des chaînes Unicode par défaut est un atout monstrueux : les erreurs d'encodage pètent tout de suite, sans nous faire d'enfants dans le dos. Du simple fait du portage, plusieurs dizaines de tickets (certains vieux de plusieurs années) ont été fermés du même coup.
-
ce que j'appellerais l'optimisabilité : que ce soit Perl 5 ou Python 3, les deux langages se situent globalement au même niveau d'abstraction et de performances brutes. Néanmoins, une codebase en Python propose beaucoup plus de vecteurs d'attaque pour optimiser les softs. En particulier Cython. Un comparatif entre Cython (Python 3) et SWIG (Perl 5) a rapidement porté ses fruits (l'overhead d'un binding est 6 à 7 fois plus petit en Cython qu'avec SWIG, et ne représente, concrètement, que le double d'un appel de code natif depuis un programme natif. Résultat qu'il est sûrement possible de perfectionner si on s'attelle à éviter les copies inutiles de données). En somme, la frontière en termes de performances atteignables est beaucoup plus mobile en Python, d'autant que ce dernier fournit de nombreux outils standard de profiling et inclut, également en standard, un module ctypes qui permet de très rapidement binder du code natif (avant de passer aux choses sérieuses avec Cython).
-
la gestion d'erreurs : anecdotique en Perl (tests sur la variable $@), son pendant Python est un véritable système d'exceptions. Là encore, sur une code base de plusieurs dizaines de milliers de lignes, Perl 5 s'essoufle, clairement.
Par contre, là où je pensais gagner et où je n'ai pas constaté de réel gain, c'est sur la différence de qualité entre les modules du CPAN et ceux du Pypi. Le seul avantage de Python à ce niveau est probablement que l'on a beaucoup moins besoin de recourir au Pypi qu'au CPAN en raison de sa bibliothèque standard exceptionnelle, mais dès que l'on commence à toucher aux bibliothèques tierces, les deux sources doivent être considérées avec la même vigilance.
Au final, aujourd'hui, je ne vois pas d'intérêt à se lancer dans Perl 5 en dehors du cas évident où on a besoin de maintenir rapidement du code existant.
Je ne connais pas suffisamment Perl 6 pour l'inclure à mes remarques. En ce qui me concerne, j'ai volontiers délaissé Perl 5 au profit de Python 3, et il a suffit de quelques semaines de développement sur un projet équivalent pour que j'en ressente très nettement les avantages (en plus du plaisir simple et évident d'utiliser le langage).
