Différences entre versions de « Alan Perlis »

9 144 octets supprimés ,  il y a 9 ans
ajout d'une source
(→‎« Perlisismes » : avancement des corrections)
(ajout d'une source)
==« Perlisismes »==
 
{{citation|citation=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.
{{à sourcer|date=10-08-16}}
|original=
==« Perlisismes »==
|langue=
 
|précisions=
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.
}}
{{Réf Article
|titre=Epigrams on Programming
|url=http://doi.acm.org/10.1145/947955.1083808
}}
 
===Philosophie===
 
* La constante d’une personne est la variable d’une autre. (1, p. 7)
* Les idiots ignorent la complexité. Les pragmatiques en souffrent. Certains parviennent à l’éviter. Les génies la suppriment. (58, p. 10)
* 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. (62, p. 10)
* 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 pourquoi nous recommençons toujours de zéro. (52, p. 10)
 
===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 11{{e}} 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. (57, p. 10)
* 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<ref>''top-down''</ref>, 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''<ref>''measure a programmer's perspective'', pourrait aussi se traduire par « capacité à prendre du recul » ou « les perspectives d'avenir », NdT</ref> d’un programmeur par son attitude par rapport à la vitalité persistante<ref>''continuing vitality''</ref> de FORTRAN.
* Il ne faut pas évaluer les programmeurs par leur ingéniosité ou leur logique, mais par l’exhaustivité<ref>''completeness''</ref> de leur étude de cas<ref>''case analysis''</ref>.
 
===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 connaît la valeur de tout, mais le coût<ref>''cost''</ref> de rien. (55, p. 10)
* 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<ref>''idioms'', NdT</ref>. 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 ==