☰ Menu

06.10.2026 · Signal Titans Editorial

Larry Wall avait besoin de meilleurs rapports. Awk ne suffisait pas — alors il a créé Perl.

Larry Wall à côté d’un pipeline visuel de fichiers Unix, awk et sed, Perl et un rapport généré.

Larry Wall n’avait pas prévu d’inventer un langage de programmation.

Il devait produire des rapports.

Les données vivaient dans des fichiers texte répartis sur un réseau.

Les outils Unix disponibles pouvaient théoriquement faire le travail.

Mais le processus était pénible.

Et lent.

Wall fit donc ce que font parfois les programmeurs lorsqu’une tâche répétitive les agace suffisamment.

Il construisit un nouvel outil.

Puis cet outil devint Perl.

Le problème initial était d’une banalité totale

En 1987, Wall travaillait sur un projet qui exigeait de collecter des informations depuis des fichiers texte et de les transformer en rapports utiles.

L’environnement impliquait des systèmes Unix et du network management.

Shell, sed et awk étaient puissants, mais Wall voulait faire du traitement de texte et de la génération de rapports plus complexes sans assembler une chaîne de scripts de plus en plus inconfortable.

Il dira plus tard qu’il aurait probablement pu résoudre le problème avec awk et shell.

Il ne voulait simplement pas le résoudre de cette façon.

Awk aurait dû sauter à travers trop d’obstacles.

Et il était trop lent pour ce qu’il imaginait.

Wall avait trois célèbres « vertus » contre l’ancien workflow

Il décrivit ensuite les vertus du programmeur comme :

Paresse.

Impatience.

Hubris.

Les mots sont humoristiques, mais l’idée d’ingénierie est sérieuse.

La paresse dit que le travail répétitif devrait être automatisé.

L’impatience dit que l’ordinateur ne devrait pas gaspiller le temps de l’utilisateur.

Hubris dit que vous êtes prêt à croire que vous pouvez construire quelque chose de meilleur.

Perl est né des trois.

Au lieu de forcer awk à faire encore plus d’acrobaties, il a créé un langage

Wall avait déjà écrit des compilateurs.

Il connaissait les outils Unix.

Il aimait les langues — humaines autant que de programmation.

Plutôt que de continuer à étendre une chaîne de scripts, il conçut quelque chose capable d’absorber les forces de plusieurs outils existants.

Perl hérita d’idées de C, sed, awk, du shell Unix et de plusieurs autres langages.

Mais il les rassembla autour d’un type de travail très concret :

Scanner du texte.

Extraire de l’information.

La transformer.

Produire un rapport.

Et gérer fichiers et processus au passage.

Une version interne vint d’abord

L’historique officiel de Perl mentionne un « Perl 0 » utilisé en interne.

Puis Perl 1.000 fut publié le 18 décembre 1987.

Wall décrivit cette release comme le moment où Perl passa de ses collègues de bureau au monde entier.

L’annonce initiale décrivait Perl comme un langage optimisé pour scanner des fichiers texte, extraire de l’information et imprimer des rapports.

C’est presque la description exacte de la frustration qui lui donna naissance.

Le Web lui donna ensuite un travail beaucoup plus grand

Perl n’a pas été créé pour les sites web.

En 1987, le Web public n’existait pas.

Mais ses forces correspondaient étonnamment bien au Web des débuts.

Les programmes CGI devaient recevoir du texte, analyser des paramètres, lire des fichiers, parler à des bases de données et produire du texte — souvent du HTML.

Perl excellait déjà dans le texte et le glue work.

Au milieu des années 1990, il devint l’un des langages emblématiques du développement web initial.

Un langage né des rapports réseau trouva une nouvelle montagne de texte à traiter.

Perl était volontairement éclectique

Certains langages cherchent une manière propre et unique d’exprimer une idée.

Perl développa une autre personnalité.

Il absorba plusieurs styles.

Un utilisateur de sed pouvait écrire du Perl qui ressemblait un peu à sed.

Un utilisateur d’awk retrouvait des idées familières.

Un programmeur C reconnaissait la syntaxe.

La philosophie célèbre de Wall devint : « There’s more than one way to do it. »

Cette flexibilité rendit Perl très productif pour résoudre rapidement des problèmes pratiques.

Elle lui donna aussi la réputation de permettre du code cryptique lorsque la cleverness dépassait la clarté.

La même liberté qui rend un langage expressif rend la discipline plus importante.

Le motif profond dépasse largement Perl

Beaucoup d’outils utiles apparaissent lorsque quelqu’un atteint la limite du glue code.

Au début, le workflow reste gérable.

Exécuter commande A.

La passer à B.

Parser la sortie avec C.

Ajouter un petit script shell.

Puis un autre.

Puis gestion d’erreur, configuration et state.

Finalement, la colle devient le système lui-même.

À ce moment, une meilleure abstraction peut valoir davantage qu’un patch supplémentaire.

Les workflows IA modernes atteignent déjà le même point

Aujourd’hui, les équipes connectent prompts, APIs, scrapers, bases de données et scripts.

Au départ, quelques calls suffisent.

Puis arrivent retries.

State.

Memory.

Routing.

Evaluation.

Permissions.

Observability.

Très vite, le workflow devient son propre environnement de programmation.

La question ressemble alors à celle de Wall en 1987 :

Faut-il continuer à forcer les outils existants à faire davantage d’acrobaties, ou créer une abstraction où le motif récurrent devient natif ?

Les meilleures idées d’automatisation commencent souvent par l’irritation

Perl n’est pas né d’une analyse de marché concluant que le monde avait besoin d’un langage de plus.

Il est né d’un programmeur regardant une tâche de reporting et décidant que la méthode existante était trop pénible.

C’est utile à retenir, car les produits ambitieux commencent souvent par des plaintes peu ambitieuses.

Ça prend trop de temps.

Je répète toujours la même transformation.

Ces outils s’emboîtent presque, mais pas complètement.

Je peux résoudre le problème, mais je déteste la façon dont je dois le faire.

Ce ne sont pas toujours des signes qu’il faut travailler plus dur.

Parfois, ce sont des signes que l’abstraction est mauvaise.

Quel workflow répétitif résolvez-vous encore avec une chaîne de scripts de plus en plus longue parce que personne n’a encore admis qu’il mérite son propre outil ?

Sources