« Alan Perlis » : différence entre les versions

Une page de Wikiquote, le recueil des citations libres.
Contenu supprimé Contenu ajouté
Nojhan (discussion | contributions)
→‎« Perlisismes » : quelques corrections de la traduction de Philippe Guglielmetti, avancement dans l'indication des numéro et des pages
Nojhan (discussion | contributions)
→‎Citations : <references />
Ligne 145 : Ligne 145 :
|collection=
|collection=
|langue=en}}
|langue=en}}

<references />


{{interprojet|w}}
{{interprojet|w}}

Version du 17 août 2010 à 08:24

Alan Jay Perlis (1er avril 1922 - 7 février 1990) était un informaticien américain connu pour son travail pionnier dans les langages de programmation, plus notablement comme l'un des membres de l'équipe qui développa le langage de programmation ALGOL. Il fut le premier à recevoir le prestigieux ACM Turing Award.

« Perlisismes »

Certaines citations sont mal sourcées
Cet article ou section d'article manque de sources depuis le lundi 16 août 2010.
Vous pouvez contribuer à l'améliorer en ajoutant des références aux citations.
Toute citation non référencée sera, à terme, enlevée de Wikiquote en accord avec la charte.


Les citations suivantes sont tirées de l'article indiqué, la page et le numéro de citation dans l'article original sont indiqués entre parenthèses.

  • (en) « Epigrams on Programming », Alan J. Perlis (trad. Philippe Guglielmetti, Johann Dréo), SIGPLAN Notices (ISSN 0362-1340), vol. 17 nº 9, septembre 1982, p. 7--13 (lire en ligne)


Philosophie

  • La constante d’une personne est la variable d’une autre. (1, p. 7)
  • 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. (31, p. 8)
  • 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. (21, p. 8)
  • 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.

o 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. (26, p. 8)
  • 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 des émulations extérieures satisfaisantes. La standardisation des ordinateurs réels serait un désastre − donc ça n’arrivera probablement pas. (36, p. 9)

Programmation

  • Il y a deux manières d’écrire des programmes sans erreurs ; seule la troisième marche. (40, p. 9)
  • Le 11e commandement était « Tu programmeras » ou « Tu ne programmeras pas » − je ne me souviens plus lequel.
  • Programmer est un acte contre nature. (33, p. 9)
  • Tout programme a (au moins) deux buts : celui pour lequel il a été écrit, et un autre pour lequel il ne l’a pas été. (16, p. 8)
  • 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 », mais c'est parce que c’est le meilleur livre pour le profane sur tous les sujets. (48, p. 9)

Code

  • Chaque programme est un bout d’un autre programme et y trouve rarement sa place. (4, p. 7)
  • Tout doit être construit du haut vers le bas[1], sauf la première fois. (15, p. 8)
  • Si vous avez une fonction avec 10 paramètres, vous en avez probablement oublié. (11, p. 7)
  • Un programme sans boucle et sans structure de donnée ne vaut pas la peine d’être écrit. (18, p. 8)
  • Rendre quelque chose variable est facile. Le problème, c’est de contrôler la durée de la constance.
  • À long terme, tout programme devient rococo − puis décombres. (14, p. 7)
  • La récursion est la racine du calcul car elle échange la description contre du temps. (12, p. 7)
  • 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 seule structure de données que 10 fonctions pour 10 structures. (9, p.7)

Programmeurs

  • Une fois que vous comprenez comment écrire un programme, trouvez quelqu’un d’autre pour l’écrire. (27, p. 8)
  • Pour comprendre un programme, vous devez devenir à la fois la machine et le programme. (23, p. 8)
  • Il est plus facile d’écrire un programme incorrect que d’en comprendre un correct. (7, p. 7)
  • Si votre interlocuteur hoche la tête pendant que vous lui expliquez votre programme, réveillez-le. (17, p. 8)
  • 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’âge adulte. (24, p. 8)
  • 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 trop vite. (30, p. 8)
  • Vous pouvez mesurer la perspective[2] d’un programmeur par son attitude par rapport à la vitalité persistante[3] de FORTRAN.
  • Il ne faut pas évaluer les programmeurs par leur ingéniosité ou leur logique, mais par l’exhaustivité[4] de leur étude de cas[5].

Langages

  • Un langage qui n'affecte pas votre manière de penser la programmation ne vaut pas la peine d'être connu. (19, p. 8)
  • Certains langages de programmation arrivent à absorber le changement, mais résistent au progrès. (41, p. 9)
  • 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 son programme nécessite de faire attention à ce qui n’est pas pertinent. (8, p.7)
  • Un bon système ne peut pas avoir un langage de commande faible. (22, p.8)
  • 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é (les co-routines incluent des sous-routines) : recherchez-la partout. (6, p.7)
  • Entrez tôt dans la routine : faites les mêmes processus de la même façon. Accumulez les tournures[6]. Standardisez. La seule différence (!) entre Shakespeare et vous est la taille de sa liste de tournures − pas la taille de son vocabulaire. (10, p.7)

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. (35, p. 9)
  • 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 syntactique cause le cancer du point-virgule) (3, p. 7)
  • 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. (43, p. 9)

Citations

Je pense qu'il est extraordinairement important que dans le monde de l'informatique, nous continuions à prendre plaisir à nous servir des ordinateurs. A l'origine, l'amusement y était omniprésent. Bien sûr, les clients qui payaient se retrouvaient bloqués de temps à autre, et après un certain temps nous commençâmes à prendre leurs plaintes au sérieux. Nous commençâmes à nous imaginer responsables de la fiabilité sans faille de ces machines. Je ne crois pas que nous en soyons responsables. Je pense que notre responsabilité se borne à en étendre les fonctionnalités, à les relancer dans de nouvelles directions, et à s'assurer que l'amusement ne se tarisse pas. J'espère que le domaine de l'informatique ne perdra jamais son sens du plaisir. Par-dessus tout, j'espère que nous ne deviendrons pas des missionnaires. Ne vous imaginez pas que vous êtes des vendeurs de Bible. Il y a déjà trop de gens de cette sorte dans le monde. Ce que vous savez de l'informatique, d'autres gens l'apprendront. Ne vous imaginez pas que toutes les connaissances nécessaires pour réussir dans l'informatique résident entre vos mains. Ce qu'il y a entre vos mains, je pense et je l'espère, c'est l'intelligence : la capacité à voir la machine de manière plus poussée que lorsqu'on vous l'a montrée pour la première fois, et que vous pouvez en tirer davantage.
  • (en) I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.
  • (en) The Structure and Interpretation of Computer Programs (1996), Hab Abelson, Gerald Jay Sussman et Julie Sussman, éd. The MIT Press, 1999  (ISBN 0-262-01153-0), p. 3


  1. top-down
  2. measure a programmer's perspective, pourrait aussi se traduire par « capacité à prendre du recul » ou « les perspectives d'avenir », NdT
  3. continuing vitality
  4. completeness
  5. case analysis
  6. idioms, NdT

Autres projets: