Pourquoi Comment Combien le blog du Dr. Goulu
le blog du Dr. Goulu

Perlisismes : les dictons informatiques d’Alan Perlis

Alan Jay Perlis

En préparant un autre article, je suis tombé sur quelques citations d'Alan Perlis, un précurseur de la programmation et célèbre professeur à Carnegie Mellon et Yale. Les dictons informatiques dont il émaillait ses cours ont été publiés [1] et sont passés à la postérité sous le nom de « Perlisismes », mais ne sont disponibles qu’en anglais. Ne les ayant pas trouvé en français, je me suis fendu (de rire) d’une traduction, en les reclassant par thèmes subjectifs et en les classant selon mes préférences. Régalez vous !

Philosophie

  • La constante d’une personne est la variable d’une autre.
  • Les inconscients ignorent la complexité. Les pragmatistes en souffrent. Certains parviennent à l’éviter. Les génies la suppriment.
  • En poursuivant l’inaccessible, la simplicité se trouve en travers du chemin.
  • La simplicité ne précède pas la complexité, elle la suit.
  • Vous ne pouvez pas communiquer la complexité, juste en faire prendre conscience.
  • N’ayez pas de bonnes idées si vous n’êtes pas prêt à en être responsable.
  • L’optimisation entrave l’évolution.
  • Souvent les moyens justifient la fin : le but fait avancer la technique, et la technique survit même quand le but s’effondre.
  • On ne peut pas aller de l’informel au formel par des moyens formels.
  • Slogan pour un labo de recherche : Nous travaillons aujourd’hui sur ce à quoi d’autres vont penser demain (What we work on today, others will first think of tomorrow.)

Informatique

  • Dans la symbiose homme-machine, c’est l’homme qui doit s’adapter parce que la machine ne peut pas.
  • En informatique, les invariants sont éphémères.
  • La preuve de la valeur d’un système informatique est son existence.
  • Le contact prolongé avec les ordinateurs transforme les mathématiciens en comptables et vice versa.
  • L’informatique (Computer Science) est gênée par les ordinateurs.
  • L’ordinateur est le pollueur ultime : ses fèces sont indistinguables de la nourriture qu’il produit.
  • Les systèmes ont des sous-systèmes, et les sous-systèmes ont des sous-sous-systèmes et ainsi de suite à l’infini. C’est la raison pour laquelle nous recommençons chaque fois de zéro.

Intelligence artificielle

  • Une année de travail sur l’intelligence artificielle est suffisante pour vous faire croire en Dieu.
  • Dans un ordinateur, le langage naturel n’est pas naturel.
  • Si votre ordinateur parle anglais, il a probablement été fabriqué au Japon.
  • Quand nous écrivons des programmes qui « apprennent », ce qui arrive c’est que nous apprenons, et eux pas.
  • Il y aura toujours des choses que nous aimerions dire dans nos programmes, mais qui ne peuvent être que mal dites avec tous les langages connus.
  • La seule théorie constructive liant les neurosciences et la psychologie surviendra de l’étude du logiciel.
  • Le but de l’informatique est l’émulation de nos facultés de synthèse, pas la compréhension des facultés analytiques.
  • L’ordinateur le plus important est celui qui bouillonne dans nos crânes et recherche de nouvelles satisfactions extérieures. La standardisation des ordinateurs serait un désastre, donc ça n’arrivera probablement pas.

Programmation

  • Il y a deux manières d’écrire des programmes sans erreurs. Seule la troisième marche.
  • Le 11ème commandement était « Tu programmeras » ou « Tu ne programmeras pas », je ne me souviens plus au juste.
  • Programmer est un acte contre nature.
  • Tout programme a (au moins) deux buts : celui pour lequel il a été écrit, et celui pour lequel il ne l’a pas été.
  • Il est plus facile de changer la spécification pour qu’elle corresponde au programme que le contraire.
  • Adapter de vieux programmes à de nouvelles machines signifie habituellement adapter les nouvelles machines pour qu’elles se comportent comme les anciennes.
  • En informatique, passer de l’évident à l’utile est une définition vivante du mot « frustration ».
  • La documentation est comme une assurance-vie : le bénéficiaire n’est presque jamais celui qui l’a signée.
  • On ne manquera jamais de choses à programmer aussi longtemps qu’il y aura un seul programme.
  • le meilleur livre grand public sur la programmation est « Alice au Pays des Merveilles », parce que c’est le meilleur livre grand public sur tous les sujets.

Code

  • Chaque programme est un bout d’un autre programme qui convenait mal.
  • Tout doit être construit de haut en bas (top-down), sauf la première fois.
  • Si vous avez une fonction avec 10 paramètres, vous en avez probablement oublié.
  • Un programme sans boucle et sans structure de donnée ne vaut pas la peine d’être écrit.
  • Rendre quelque chose variable est facile. Le problème, c’est de contrôler la durée de la constance.
  • A long terme, tout programme devient rococo, puis des gravats.
  • La récursion est la racine du calcul car elle échange la description contre du temps.
  • Un programme qui manipule un grand nombre de données le fait d’un petit nombre de manières.
  • C’est mieux d’avoir 100 fonctions travaillant sur une structure de données que 10 fonctions pour 10 structures.

Programmeurs

  • Une fois que vous comprenez comment écrire un programme, trouvez quelqu’un d’autre pour l’écrire.
  • Pour comprendre un programme, vous devez devenir à la fois la machine et le programme.
  • Il est plus facile d’écrire un programme incorrect que d’en comprendre un correct.
  • Si votre interlocuteur hoche la tête pendant que vous lui expliquez votre programme, réveillez-le!
  • Quand deux programmeurs se rencontrent pour critiquer leurs programmes, les deux sont silencieux.
  • Peut-être que si nous écrivions des programmes depuis notre enfance, nous pourrions les lire à l’age adulte.
  • En programmation, tout ce que nous faisons est un cas particulier de quelque chose de plus général, et souvent nous nous en apercevons très vite.
  • Vous pouvez mesurer les perspectives d’avenir d’un programmeur par son attitude par rapport à la vitalité de FORTRAN.
  • Il ne faut pas évaluer les programmeurs par leur ingéniosité ou leur logique, mais par l’étendue (completeness) de leur étude de cas (case analysis).

Langages

  • Il ne vaut pas la peine de connaitre un langage qui ne modifie pas votre façon de penser la programmation.
  • Certains langages de programmation arrivent à absorber des changements, mais résistent au progrès.
  • Sur une période de 5 ans on trouve un superbe langage de programmation. Mais on ne sait pas quand cette période de 5 ans aura lieu.
  • Un langage de programmation est « bas niveau » quand il nécessite de faire attention à ce qui n’a aucune importance.
  • Un bon système ne peut pas avoir un langage de commande faible.
  • Si quelqu’un dit « je veux un langage de programmation dans lequel je n’aurais qu’à dire ce qui doit être fait », donnez lui une sucette.
  • Alors que les chinois devraient adorer APL, ils investissent dans FORTRAN.
  • Un programmeur LISP connait la valeur de tout, mais le cout (cost) de rien.
  • Au cours des siècles, les Indiens ont développé un langage de signes pour communiquer des phénomènes intéressants. les programmeurs des différentes tribus (FORTRAN, LISP, ALGOL, SNOBOL, etc.) auraient pu en utiliser un pour éviter de transporter un tableau noir sur leur poneys.

Bons conseils:

  • la symétrie est un concept réduisant la complexité : utilisez la partout.
  • Entrez tôt dans une routine : faites la même chose de la même façon. Accumulez les tournures (idioms). Standardisez. la seule différence (!) entre Shakespeare et vous est la liste de ses tournures, pas la taille de son vocabulaire.

Enseignement

  • Enseigner la programmation va à l’encontre de l’éducation moderne : Quel est le plaisir à planifier, se discipliner à organiser ses pensées, faire attention aux détails et apprendre à être autocritique ?
  • On n’apprend pas l’informatique avec une calculatrice de poche, mais on peut oublier l’arithmétique.
  • La plupart des gens trouvent le concept de la programmation évident, mais la réalisation impossible.
  • Tout le monde peut apprendre à sculpter : on aurait du dire à Michel-Ange comment ne pas le faire.  C’est la même chose avec les grands programmeurs. (édité le 23.11.11 à partir de WikiQuote)
  • Vous croyez savoir quand vous apprenez, vous en êtes sur quand vous écrivez, persuadé quand vous enseignez, mais certain seulement quand vous programmez.

Jeux de mots intraduisibles

  • Syntactic sugar causes cancer of the semicolon. (Le sucre syntaxique cause le cancer du point-virgule)
  • Editing is a rewording activity. (L’édition est une activité de rephrasage (rewOrding) récompensante (rewArding))
  • Like punning, programming is a play on words.
  • In software systems, it is often the early bird that makes the worm.

Vous trouverez encore sur cette page quelques « perlisisms » en anglais que je n’ai pas traduits, soit parce que je ne les trouvais pas terribles, soit parce que je ne les ai pas compris …

Référence :

  1. [altmetric doi= »10.1145/947955.1083808″ float= »right »]Alan J. Perlis « Epigrams on Programming« , SIGPLAN Notices Vol. 17, No. 9, September 1982, pages 7 – 13 DOI>10.1145/947955.1083808

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

9 commentaires sur “Perlisismes : les dictons informatiques d’Alan Perlis”