El Programador Humil

Conferència ACM Turing (Association for Computing Machinery) 1972

From: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html 
Original typescript: http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF

"El Programador Humil"
per:
Edsger W. Dijkstra

Com a resultat d'una llarga seqüència de coincidències, vaig ingressar oficialment a la professió de programació el primer matí de primavera de 1952 i, pel que he pogut rastrejar, vaig ser el primer holandès en fer-ho al meu país. En retrospectiva, el més sorprenent va ser la lentitud amb què, almenys en la meva part del món, va sorgir la professió de programació, una lentitud que ara és difícil de creure. Però estic agraït per dos vívids records d'aquell període que estableixen aquesta lentitud més enllà de qualsevol dubte.

Després d'haver programat durant uns tres anys, vaig tenir una discussió amb A. van Wijngaarden, qui era el meu cap al Centre de Matemàtiques a Amsterdam, una discussió per la qual estaré agraït amb ell mentre visqui. El punt era que se suposava que havia d'estudiar física teòrica a la Universitat de Leiden simultàniament, i quan vaig trobar les dues activitats cada vegada més difícils de compaginar, vaig haver de decidir, ja sigui per deixar de programar i convertir-me en un teòric real i respectable. físic, o per portar el meu estudi de física a una finalització formal només, amb un mínim d'esforç, i per convertir-me en ..... sí què? Un programador? ¿Però era una professió respectable? Després de tot, què era la programació? On era el sòlid cos de coneixement que podria donar-li suport com una disciplina intel·lectualment respectable? Recordo vívidament com envejava als meus col·legues de maquinari, els quals, quan se'ls va preguntar sobre la seva competència professional, almenys van poder assenyalar que sabien tot sobre els tubs de buit, els amplificadors i la resta, mentre que vaig sentir que, a l'enfrontar aquesta pregunta, jo s'aturaria amb les mans buides. Ple de dubtes, vaig trucar a la porta de l'oficina de van Wijngaarden i li vaig preguntar si podia "parlar amb ell per un moment"; Quan vaig sortir de la seva oficina diverses hores després, era una altra persona. Després d'haver escoltat els meus problemes amb paciència, va estar d'acord que fins aquell moment no hi havia molta disciplina de programació, però després va explicar en veu baixa que els ordinadors automàtics estaven aquí per quedar-se, que estàvem al principi i podíem No podria ser jo  una de les persones cridades a fer de la programació una disciplina respectable en els propers anys? Aquest va ser un punt d'inflexió en la meva vida i vaig completar el meu estudi de física formalment tan ràpid com vaig poder. Una moralitat de la història anterior és, per descomptat, que hem de ser molt curosos quan donem consells a les persones més joves; de vegades el segueixen!

Dos anys després, el 1957, em vaig casar i els ritus de matrimoni holandesos requereixen que declaris la teva professió i vaig dir que era programador. Però les autoritats municipals de la ciutat d'Amsterdam no ho van acceptar perquè no existia tal professió. I, ho creguis o no, però sota el títol "professió", el meu acte de matrimoni mostra la ridícula entrada "físic teòric"!

Tant per la lentitud amb la que vaig veure sorgir la professió de programació al meu propi país. Des de llavors, he vist més del món, i tinc la impressió general que en altres països, a més d'un possible canvi de dates, el patró de creixement ha estat molt similar.

Permetin-me intentar capturar la situació en aquests vells temps amb una mica més de detall, amb l'esperança de comprendre millor la situació actual. Mentre seguim la nostra anàlisi, veurem quants malentesos comuns sobre la veritable naturalesa de la tasca de programació es remunten a aquest passat ara distant.

Les primeres computadores electròniques automàtiques eren totes màquines úniques, exemplars únics i totes es trobaven en un entorn amb el regust emocionant d'un laboratori experimental. Una vegada que la visió de l'ordinador automàtica hi va ser, la seva realització va ser un gran desafiament per a la tecnologia electrònica disponible en aquest moment, i una cosa és certa: no podem negar el coratge dels grups que van decidir intentar construir un equip tan fantàstic. Pel fantàstics equips que eren: en retrospectiva, un només  pot preguntar-se si aquestes primeres màquines van funcionar, almenys algunes vegades. El problema aclaparador era aconseguir i mantenir la màquina funcionant correctament. La preocupació pels aspectes físics de la informàtica automàtica encara es reflecteix en els noms de les societats científiques més antigues que hi ha encara actualment en aquest camp, com l'Associació de Maquinària de Computació (ACM) o la Societat Britànica de Computació, noms en els quals es fa referència explícita a l'equip físic.

Què passa amb el pobre programador? Bé, per dir la veritat sincera: ni tan sols es van adonar de la seva existència. D'una banda, les primeres màquines eren tan voluminoses que amb prou feines podia moure-les i, a més, requerien un manteniment tan extens que era bastant natural que el lloc on les persones intentaven fer servir la màquina fos el mateix laboratori on s'havia desenvolupat i construit. En segon lloc, el seu treball era alguna cosa invisible i sense glamour: es podia mostrar la màquina als visitants i això era diversos ordres de magnitud més espectacular que alguns fulls de codificació. Però el més important de tot, el propi programador tenia una visió molt modesta del seu propi treball: el seu treball derivava tot el seu significat de l'existència d'aquesta meravellosa màquina. Com es tractava d'una màquina única, sabia molt bé que els seus programes només tenien un significat local i, com era obvi que aquesta màquina tindria una vida útil limitada, sabia que molt poc de la seva feina tindria un valor durador, amb transcendència. Finalment, hi ha una altra circumstància que va tenir una profunda influència en l'actitud del programador cap al seu treball: d'una banda, a més de no ser fiable, la seva màquina generalment era massa lenta i la seva memòria era massa petita, és a dir, s'enfrontava a l'euivalent mal de peu degut a la sabata, mentre que, d'altra banda, el seu codi d'ordres, en general un tant estrany, satisfaria les construccions més inesperades. I en aquells dies, molts programadors intel·ligents van obtenir una immensa satisfacció intel·lectual dels trucs astuts mitjançant els quals les hi va arreglar per comprimir tot el codi fins a l'impossible per adaptar-se a les limitacions del seu equip.

Dues opinions sobre programació en aquells dies. Els esmento ara, tornaré sobre ells més tard. L'única opinió era que un programador realment competent hauria de ser enginyós i molt aficionat als trucs intel·ligents; l'altra opinió era que la programació no era més que optimitzar l'eficiència del procés computacional, en una direcció o una altra.

L'última opinió va ser el resultat de la freqüent circumstància que, de fet, l'equip disponible era com posar-se unes sabates que fan mal que, i en aquests dies sovint es trobaven amb la ingènua expectativa que una vegada que hi hagués màquines més potents disponibles, la programació ja no seria un problema, perquè llavors la lluita per portar la màquina al límit ja no seria necessària ja que d'això es tractava la programació, no? Però en les següents dècades va passar una cosa completament diferent: màquines més potents van estar disponibles, no només un ordre de magnitud més poderós, fins i tot diversos ordres de magnitud més potents. Però en lloc de trobar-nos en l'estat de felicitat eterna de tots els problemes de programació resolts, ens trobem fins al coll en la crisi del programari! Com podia ser?

Hi ha una causa menor: en un o dos aspectes, la maquinària moderna és bàsicament més difícil de fer funcionar que la maquinària antiga. En primer lloc, tenim les interrupcions d'E/S, que ocorren en moments impredictibles i irreproduïbles; En comparació amb la vella màquina seqüencial que pretenia ser un autòmat totalment determinista, aquest ha estat un canvi dramàtic i molts cabells blancs de programador de sistemes donen testimoni del fet que no hem de parlar a la babalà dels problemes lògics creats per aquesta característica. En segon lloc, tenim màquines equipades amb diversos nivells d'emmagatzematge, el que ens presenta problemes d'estratègia de gestió que, tot i l'extensa literatura sobre el tema, segueixen sent bastant esquives. Això encara més, amb la complicació addicional deguda als canvis estructurals de les màquines reals.

Però ja he dit que això era una causa menor: La causa principal és ... que les màquines s'han tornat més poderoses en diversos ordres de magnitud! Ras i curt: mentre no hi hi havia màquines, la programació no era un problema en absolut; quan vam tenir algunes computadores febles, la programació es va convertir en un problema lleu, i ara tenim ordinadors gegants, la programació s'ha convertit en un problema igualment gegantí. En aquest sentit, la indústria electrònica no ha resolt un sol problema, només els ha creat, ha creat el problema d'usar els seus productes. Per dir-ho d'una altra manera: a mesura que el poder de les màquines disponibles creixia en un factor de més de mil, l'ambició de la societat d'aplicar aquestes màquines va créixer en proporció, i va ser el pobre programador qui va trobar el seu treball en aquest camp de tensió pressionat entre els fins i els mitjans. La major potència del maquinari, juntament amb l'augment potser encara més dramàtic en la seva fiabilitat, va fer possibles les solucions amb les que el programador no s'havia atrevit a somiar uns anys abans. I ara, uns anys més tard, va haver de somiar amb ells i, el que és pitjor, ¡va haver de transformar tals somnis en realitat! És sorprenent que ens trobem en una crisi de programari? No, certament no, i com pot suposar, fins i tot es va predir amb molta antelació; però el problema amb els profetes menors, per descomptat, és que només cinc anys després se sap realment que tenien raó.

Després, a mitjans dels anys seixanta, va passar una cosa terrible: els ordinadors de l'anomenada tercera generació van fer la seva aparició. La literatura oficial ens diu que la seva relació preu / rendiment ha estat un dels principals objectius de disseny. Però si pren com "rendiment" el cicle de treball dels diversos components de la màquina, poc evitarà que acabi amb un disseny en el qual la major part del seu objectiu de rendiment s'aconsegueix mitjançant activitats internes de manteniment de dubtosa necessitat. I si la seva definició de preu és el preu que es pagarà pel maquinari, poc evitarà que acabi amb un disseny que és terriblement difícil de programar: per exemple, el codi de comanda podria aplicar-se, ja sigui al programador o sobre el sistema, decisions vinculants primerenques que presenten conflictes que realment no poden resoldre. I en gran mesura, aquestes desagradables possibilitats semblen haver-se convertit en realitat.

Quan es van anunciar aquestes màquines i es van conèixer les seves especificacions funcionals, molts de nosaltres vam haver de ser bastant poc fiables; Almenys jo ho vaig ser. Era raonable esperar que aquestes màquines inundéssin la comunitat informàtica i, per tant, era encara més important que el seu disseny fos el més sòlid possible. Però el disseny encarnava defectes tan greus que vaig sentir que de cop el progrés de la ciència informàtica s'havia tirat enrere almenys deu anys: va ser llavors quan vaig tenir la setmana més negra de tota la meva vida professional. Potser el més trist ara és que, fins i tot després de tots aquests anys d'experiència frustrant, molta gent creu sincerament que alguna llei de la natura ens diu que les màquines han d'evolucionar així. Silenciaven els seus dubtes observant quantes d'aquestes màquines s'havien venut, i derivaven d'aquesta observació la falsa sensació de seguretat que, després de tot, el disseny no podria haver estat tan dolent. Però després d'una inspecció més acurada, aquesta línia de defensa va tenir la mateixa força convincent que l'argument que fumar cigarrets ha de ser saludable perquè moltes persones ho fan.

És en aquest sentit que lamento que no sigui habitual que les revistes científiques en l'àrea de la informàtica publiquin revisions de les computadores recentment anunciades de la mateixa manera que revisem les publicacions científiques: revisar les màquines seria almenys tan important. I aquí tinc una confessió que fer: a principis dels anys seixanta vaig escriure una revisió d'aquestes amb la intenció de presentar-la al CACM, però malgrat el fet que els pocs col·legues als que els vaig enviar el text per al seu consell, em van instar per fer-ho, no em vaig atrevir a fer-ho, tement que les dificultats, tant per a mi com per al comitè editorial, demostressin ser massa grans. Aquesta abstenció va ser un acte de covardia de per part meva per la qual em culpo cada vegada més. Les dificultats que preveia eren conseqüència de l'absència de criteris generalment acceptats, i encara que estava convençut de la validesa dels criteris que havia triat aplicar, temia que la meva revisió fos rebutjada o descartada com "una qüestió de gust personal". . Encara penso que aquestes revisions serien extremadament útils i anhelo veure-les aparèixer, ja que la seva aparença acceptada seria un signe segur de maduresa de la comunitat informàtica.

La raó per la qual he prestat l'atenció anterior a l'escena del maquinari és perquè tinc la sensació que un dels aspectes més importants de qualsevol eina informàtica és la seva influència en els hàbits de pensament d'aquells que intenten usar-la, i perquè tinc raons creure que aquesta influència és moltes vegades més forta del que comunament se suposa. Passem ara la nostra atenció a l'escena del programari.

Aquí la diversitat ha estat tan gran que he de limitar-me a uns pocs esglaons. Sóc dolorosament conscient de l'arbitrarietat de la meva elecció i li prego que no tregui cap conclusió pel que fa al meu agraïment pels molts esforços que quedaran sense esmentar.

1.-Al principi existia el EDSAC a Cambridge, Anglaterra, i crec que és bastant impressionant que des del principi la noció d'una biblioteca de subrutines exercís un paper central en el disseny d'aquesta màquina i de la forma en què hauria d'usar. Han passat gairebé 25 anys i l'escena informàtica ha canviat dràsticament, però la noció de programari bàsic encara està amb nosaltres, i la noció de subrutina tancada segueix sent un dels conceptes clau en la programació. Hauríem reconèixer les subrutines tancades com una de les millors invencions de programari; ha sobreviscut a tres generacions d'ordinadors i sobreviurà a unes poques més, perquè abasteix la implementació d'un dels nostres patrons bàsics d'abstracció. Lamentablement, la seva importància s'ha subestimat en el disseny de les computadores de tercera generació, en la qual la gran quantitat de registres explícitament nomenats de la unitat aritmètica implica una gran sobrecàrrega en el mecanisme de subrutina. Però fins i tot això no va eliminar el concepte de la subrutina, i només podem resar perquè la mutació no resulti hereditària.

2.-El segon desenvolupament important en l'escena del programari que m'agradaria esmentar és el naixement de FORTRAN. En aquest moment, aquest era un projecte de gran temeritat i les persones responsables d'ell mereixen la nostra gran admiració. Seria completament injust culpar per les deficiències que només es van fer evidents després d'una dècada d'ús extens: els grups amb una anticipació reeixida de deu anys són bastant rars! En retrospectiva, hem de qualificar a FORTRAN com una tècnica de codificació reeixida, però amb molt poques ajudes efectives per a la concepció, ajudes que ara es necessiten amb tanta urgència que ha arribat el moment de considerar-la desactualitzada. Com més aviat puguem oblidar que FORTRAN ha existit, millor, perquè com a vehicle de pensament ja no és adequat: malgasta la nostra capacitat intel·lectual, és massa arriscat i, per tant, massa costós d'utilitzar. El destí tràgic de FORTRAN ha estat la seva àmplia acceptació, encadenant mentalment a milers i milers de programadors als nostres errors passats. Prego diàriament perquè més dels meus companys programadors trobin els mitjans per alliberar-se de la maledicció de la compatibilitat.

3.-El tercer projecte que no voldria deixar sense esmentar és LISP, una empresa fascinant de naturalesa completament diferent. Amb uns pocs principis molt bàsics a la base, ha demostrat una notable estabilitat. A més d'això, LISP ha estat el proveïdor d'una considerable quantitat d'aplicacions informàtiques més sofisticades. LISP ha estat descrit en broma com "la forma més intel ligent de fer un mal ús d'un ordinador". Crec que aquesta descripció és un gran compliment perquè transmet tot el sabor de l'alliberament: ha ajudat a diversos dels nostres éssers humans més talentosos a elaborar pensaments que abans eren impossibles.

4.-El quart projecte a esmentar és ALGOL 60. Mentre que fins al dia d'avui els programadors de FORTRAN encara tendeixen a comprendre el seu llenguatge de programació en termes de la implementació específica amb la qual estan treballant, d'aquí la prevalença dels bolcats octal i hexadecimal, mentre que la definició de LISP segueix sent una curiosa barreja del que significa el llenguatge i com funciona el mecanisme, el famós Informe sobre el llenguatge algorítmic ALGOL 60 és el fruit d'un esforç genuí per portar l'abstracció un pas vital més endavant i definir un llenguatge de programació en una implementació de forma independent. Es podria argumentar que referent a això els seus autors han tingut tant d'èxit que han creat seriosos dubtes sobre si podria implementar-se en absolut! L'informe va demostrar gloriosament el poder del mètode formal BNF, ara força conegut com Notació de Backus-Naur-Form [1], i el poder de l'anglès acuradament redactat, almenys quan és utilitzat per algú tan brillant com Peter Naur. Crec que és just dir que només uns pocs documents tan curts com aquest han tingut una influència igualment profunda en la comunitat informàtica. La facilitat amb què, en anys posteriors, els noms ALGOL i de tipus ALGOL s'han utilitzat, com una marca comercial desprotegida, per prestar part de la seva glòria a una sèrie de projectes més joves, de vegades poc relacionats, és un complement d'allò més impactant per la seva posició. La força de BNF com a dispositiu de definició és responsable del que considero una de les debilitats del llenguatge: una sintaxi massa elaborada i no massa sistemàtica ara podria estar ficada dins els límits de molt poques pàgines. Amb un dispositiu tan poderós com BNF, l'Informe sobre el llenguatge algorítmic ALGOL 60 hauria d'haver estat molt més curt. A més d'això, dubto molt sobre el mecanisme de paràmetres d'ALGOL 60: permet al programador tanta llibertat combinatòria que el seu ús segur requereix una disciplina forta per part del programador. A més de costós d'implementar, sembla perillós d'utilitzar.

5.-Finalment, encara que el tema no és agradable, he de dir PL/1, un llenguatge de programació per al qual la documentació definitòria és d'una grandària i complexitat alarmants. Utilitzar PL/1 deu ser com volar un avió amb 7000 botons, interruptors i manetes per manipular a la cabina. Absolutament no veig com podem mantenir els nostres programes en creixement fermament delimitats dins del nostre control intel·lectual quan, pel seu barroquisme, el llenguatge de programació -la nostra eina bàsica, això sí! - ja escapa al nostre control intel·lectual. I si he de descriure la influència que PL/1 pot tenir en els seus usuaris, la metàfora més propera que em ve al cap és la d'una droga. Record d'un simposi sobre llenguatge de programació de nivell superior una conferència donada en defensa de PL/1 per un home que es va descriure a si mateix com un dels seus usuaris més dedicats. Però dins d'una conferència d'una hora en elogi de PL/1, se les va arreglar per demanar l'addició d'unes cinquanta noves "característiques", quan era de suposar que la font principal dels seus problemes podria ser que contenia massa "característiques". L'orador va mostrar tots els símptomes depriments de l'addicció, reduïts a l'estat d'estancament mental en què només podia demanar més, més, més ... Així com quan FORTRAN ha estat descrit com a trastorn infantil, el PL/1 complert, amb les seves creixents característiques de tumor maligne, podria arribar a ser considerat com una malaltia mortal.

Ja he parlat massa sobre el passat. Però no té sentit cometre errors a menys que després puguem aprendre d'ells. De fet, crec que hem après tant, que d'aquí a uns anys la programació pot arribar a ser una activitat molt diferent del que ha estat fins ara, tan diferent que és millor que ens preparem per al xoc. Deixeu-me esbossar un dels futurs possibles. A primera vista, aquesta visió de la programació potser en un futur proper potser pugui semblar absolutament fantàsiosa. Permetin-me, per tant, afegir també les consideracions que poden portar a la conclusió que aquesta visió podria arribar a ser una possibilitat molt real.

La visió és que, molt abans que els anys setanta s'hagin completat, podrem dissenyar i implementar el tipus de sistemes que ara estan esgotant la nostra capacitat de programació, a costa de només un petit percentatge en anys-home del que costen ara, ia més d'això, aquests sistemes estaran pràcticament lliures d'errors. Aquestes dues millores van de la mà. En aquest últim aspecte, el programari sembla ser diferent de molts altres productes, on, per regla general, una major qualitat implica un preu més alt. Aquells que vulguin un programari realment fiable descobriran que han de trobar mitjans per evitar la majoria dels errors des del principi, i com a resultat el procés de programació es tornarà més barat. Si voleu programadors més efectius, descobriran que no han de perdre el temps depurant, El que han de fer, és no introduïr errors des del principi. En altres paraules: els dos objectius apunten al mateix canvi.

Un canvi tan dràstic en un període de temps tan curt seria una revolució, i per a totes les persones que basen les seves expectatives per al futur en una extrapolació lineal de l'ocorregut en un passat recent, en afecció a algunes lleis no escrites d'inèrcia social i cultural, la possibilitat que es produeixi un canvi dràstic pot semblar insignificant. Però tots sabem que de vegades ocorren revolucions! I quines són les possibilitats d'aquesta?

Sembla que hi ha tres condicions principals que s'han de complir. El món en general ha de reconèixer la necessitat del canvi; en segon lloc, la necessitat econòmica ha de ser prou forta; i, en tercer lloc, el canvi ha de ser tècnicament factible. Permetin-me discutir aquestes tres condicions en l'ordre anterior.

1.-Pel que fa al reconeixement de la necessitat d'una major fiabilitat del programari, ja no espero desacords. Fa només uns anys, això era diferent: parlar d'una crisi de programari era una blasfèmia. El punt d'inflexió va ser la Conferència sobre Enginyeria de Software a Garmisch, octubre de 1968, una conferència que va crear sensació quan es va produir la primera admissió oberta de la crisi del programari. I a hores d'ara generalment es reconeix que el disseny de qualsevol sistema sofisticat gran serà una feina molt difícil, i cada vegada que un es troba amb persones responsables de tals iniciatives, un els troba molt preocupats pel problema de la fiabilitat, i amb raó . En resum, la nostra primera condició sembla haver estat satisfeta.

2.-Ara, la necessitat econòmica. Avui dia, sovint es troba l'opinió que en els anys seixanta la programació era una professió sobrepagada, i que en els propers anys s'espera que els salaris dels programadors baixin. En general, aquesta opinió s'expressa en relació amb la recessió, però podria ser un símptoma d'alguna cosa diferent i bastant saludable, a saber. que potser els programadors de l'última dècada no hagin fet un treball tan bo com haurien d'haver fet. La societat s'està insatisfeta amb l'exercici dels programadors i dels seus productes. Però hi ha un altre factor de molt més pes. En la situació actual, és força habitual que per a un sistema específic, el preu a pagar pel desenvolupament del programari sigui del mateix ordre de magnitud que el preu del maquinari necessari, i la societat ho accepta més o menys. Però els fabricants de maquinari ens diuen que en la pròxima dècada es pot esperar que els preus del maquinari baixin amb un factor de deu. Si el desenvolupament de programari continués sent el mateix procés maldestre i costós que és ara, les coses es sortirien completament de balanç. No pot esperar que la societat accepti això i, per tant, hem d'aprendre a programar un ordre de magnitud amb més eficàcia. Per dir-ho d'una altra manera: sempre que les màquines siguin l'element més important en el pressupost, la professió de programació podria sortir-se amb la seva amb les seves tècniques barroeres, però aquest paraigua es trencarà ben aviat. En resum, també la nostra segona condició sembla estar satisfeta.

3.-I ara la tercera condició: és tècnicament factible? Crec que podria ser-ho i li donaré 6 arguments en suport d'aquesta opinió.

Un estudi de l'estructura dels programes revelar que aquests, fins i tot els seus alternatius per a abordar la mateixa tasca i amb el mateix contingut matemàtic, poden diferir enormement en la seva capacitat de gestió intel·lectual. S'han descobert diverses regles, la violació perjudicarà greument o destruirà totalment la capacitat de gestió intel·lectual del programa. Aquestes regles són de dos tipus. Els del primer tipus s'imposen fàcilment mecànicament, a saber. per un llenguatge de programació adequadament triat. Exemples són l'exclusió de declaracions GOTO [2] i de procediments amb més d'un paràmetre de sortida. Per a aquells del segon tipus, almenys, però això pot ser degut a la manca de competència per part meva, no veig forma d'imposar-lo mecànicament, ja que sembla necessitar algun tipus de comprovador de teoremes automàtic per al qual no tinc proves de la seva existència. Per tant, de moment i potser per sempre, les regles del segon tipus es presenten com a elements de disciplina requerits per al programador. Algunes de les regles que tinc en ment són tan clares que poden ensenyar-se i mai seria necessari discutir si un programa determinat les viola o no. Exemples són el requeriment que no s'ha d'escriure mai cap bucle sense proporcionar una prova de finalització ni sense indicar la relació la invariabilitat no serà destruïda per l'execució de la declaració repetible.

Ara suggereixo que ens limitem al disseny i implementació de programes intel·lectualment manejables. Si algú té por que aquesta restricció sigui tan severa que no puguem viure amb ella, puc tranquil·litzar-la: La classe de programes intel·lectualment manejables continua sent prou rica com per contenir molts programes molt realistes per a qualsevol problema capaç de tenir una solució algorísmica. No hem d'oblidar que no és el nostre negoci fer programes, el nostre negoci és dissenyar classes de còmputs que mostrin el comportament desitjat. El suggeriment de limitar-nos a programes manejables intel·lectualment és la base dels primers dos dels meus sis arguments anunciats:

1.- El primer argument és que, com que el programador només necessita considerar programes manejables intel·lectualment, les alternatives que està triant han de ser molt més fàcils de manejar.

2.- El segon argument consisteix en que, tan aviat com hàgim decidit restringir al subconjunt dels programes intel·lectualment manejables, haurem aconseguit, d'una vegada per totes, una reducció dràstica de l'espai de solució a considerar. I aquest argument és diferent del primer argument.

3.- L'argument tercer es basa en l'enfocament constructiu del problema en quant a la correcció del programa. Avui una tècnica habitual és fer un programa i després provar-ho. Però: les proves de programa poden ser una forma molt efectiva de mostrar la presència d'errors, però és irremeiablement inadequat per mostrar la seva absència. L'única manera efectiva d'augmentar significativament el nivell de confiança d'un programa és donar una prova convincent de la seva correcció. Però primer no s'ha de fer el programa i després provar la seva idoneïtat, perquè llavors el requisit de proporcionar la prova només augmentaria la càrrega del pobre programador. Per contra: el programador ha de permetre que la verificació de correcció i el programa creixin de la mà. L'argument 3 es basa essencialment en la següent observació: Si primer es pregunta quina seria l'estructura d'una prova convincent i, un cop trobat això, construeix un programa que satisfaci els requisits d'aquesta prova, aquestes preocupacions de correcció resultarien ser una guia heurística molt efectiva. Per definició, aquest enfocament només és aplicable quan ens limitem a programes manejables intel·lectualment, però ens proporciona mitjans efectius per trobar-ne un satisfactori entre aquests.

4.- L'argument quart té a veure amb la forma en què la quantitat d'esforç intel·lectual necessari per dissenyar un programa depèn de la longitud del programa. S'ha suggerit que hi ha algun tipus de llei de la natura que ens diu que la quantitat d'esforç intel·lectual que es necessita augmenta amb el quadrat de la longitud del programa. Però, gràcies a Déu, ningú ha pogut provar aquesta llei. I això es deu al fet que no deu ser certa. Tots sabem que l'única eina mental per mitjà de la qual un raonament molt finit pot cobrir una miríada de casos es diu "abstracció"; Com a resultat, l'explotació efectiva dels seus poders d'abstracció ha de considerar-se com una de les activitats més vitals d'un programador competent. En aquest sentit, podria valer la pena assenyalar que el propòsit de l'abstracció no és ser un gandul, sinó crear un nou nivell semàntic en el qual un pugui ser absolutament precís. Per descomptat, he tractat de trobar una causa fonamental que impedeixi que els nostres mecanismes d'abstracció siguin prou efectius. Però no importa quant ho vaig intentar, no vaig trobar tal causa. Com a resultat, tendeixo a suposar, i fins ara no ha estat refutat per l'experiència, que mitjançant l'aplicació adequada dels nostres poders d'abstracció, l'esforç intel·lectual necessari per concebre o comprendre un programa no necessita créixer més que proporcionalment a la durada del programa . Però un subproducte d'aquestes investigacions pot tenir una importància pràctica molt més gran i, de fet, és la base de la meu quart argument: El subproducte va ser la identificació d'una sèrie de patrons d'abstracció que juguen un paper vital en tot el procés de compondre programes . Ara es sap prou sobre aquests patrons d'abstracció a què podria dedicar una conferència sobre cadascun d'ells.El que la familiaritat i el coneixement conscient d'aquests patrons d'abstracció impliquen i em vaig adonar d'això, és que si haguessin estat de coneixement comú fa quinze anys, el pas de BNF a compiladors dirigits per sintaxi, per exemple, podria haver pres uns minuts en lloc d'uns anys. Per tant, presento el nostre coneixement recent dels patrons d'abstracció com una cosa vital com a quart argument.

5.- Ara el cinquè argument: Té a veure amb la influència de l'eina que estem tractant d'usar sobre els nostres propis hàbits de pensament. Observo una tradició cultural, que probablement té les seves arrels en el Renaixement, d'ignorar aquesta influència, considerar la ment humana com el mestre suprem i autònom dels seus artefactes. Però si començo a analitzar els hàbits de pensament de mi mateix i dels meus semblants, arribo, m'agradi o no, a una conclusió completament diferent, a saber: que les eines que estem tractant d'usar i el llenguatge o la notació que estem fent servir per expressar o registrar els nostres pensaments, són els principals factors que determinen el que podem pensar o expressar!. L'anàlisi de la influència que els llenguatges de programació tenen en els hàbits de pensament dels seus usuaris,i el reconeixement que, per ara, la capacitat intel·lectual és, de bon tros, el nostre recurs més escàs, junts ens donen una nova col·lecció de criteris per comparar els mèrits relatius dels diferents llenguatges de programació. El programador competent és plenament conscient de la mida estrictament limitada del seu propi crani; per tant, aborda la tasca de programació amb total humilitat i, entre altres coses, fuig dels trucs enginyosos com de la pesta. En el cas d'un llenguatge de programació conversacional ben conegut, m'han dit des de diversos costats que tan aviat com una comunitat de programació està equipada amb un terminal per a ell, ocorre un fenomen específic que fins i tot té un nom ben establert: es diu "les frases d'una sola línia ". Pren una de dues formes diferents:un programador col·loca un programa d'una línia a l'escriptori d'un altre i amb orgull diu el que fa i afegeix la pregunta "Pots codificar això amb menys símbols?", Com si tingués alguna rellevància conceptual! - o simplement preguntar "Endevina què fa!". D'aquesta observació hem de concloure que aquest llenguatge com a eina és una invitació oberta a trucs enginyosos, i encara que exactament aquesta pogués ser l'exposició pública d'alguns dels recursos disponibles d'aquells a qui els agrada mostrar quan intel·ligents són, ho sento, però he de considerar això com una de les coses més condemnatòries que es poden dir sobre un llenguatge de programació.Una altra lliçó que hauríem d'haver après del passat recent és que el desenvolupament de llenguatges de programació "més rics" o "més poderosos" va ser un error en el sentit que aquestes monstruositats barroques, aquests conglomerats de idiosincràsies, són realment immanejables, tant mecànica com mentalment. Veig un gran futur per a llenguatges de programació molt sistemàtics i molt modestos. Quan dic "modest", vull dir que, per exemple, no només la "clàusula for" d'ALGOL 60, sinó fins i tot el "bucle DO" de FORTRAN es podrien veure expulsats per ser massa barrocs. He fet un petit experiment de programació amb voluntaris realment experimentats, però alguna cosa bastant inesperada va aparèixer. Cap dels meus voluntaris va trobar la solució òbvia i més elegant. Després d'una anàlisi més detallada,això va resultar tenir una font comuna: la seva noció de repetició estava tan estretament relacionada amb la idea d'una variable controlada associada que s'anés incrementant, que es van bloquejar mentalment sense poder veure el que és obvi. Les seves solucions van ser menys eficients, innecessàriament difícils d'entendre, i els va portar molt de temps trobar-les. Va ser una experiència reveladora però també impactant per a mi. Finalment, en un aspecte, un espera que els llenguatges de programació del demà difereixin molt del que estem acostumats fins ara: i en un grau molt més gran que fins ara, haurien de convidar-nos a reflexionar en l'estructura del que escrivim, en totes les abstraccions necessàries per enfrontar conceptualment la complexitat del que estem dissenyant. Fins aquí pel que fa a la major adequació de les nostres eines futures,ha estat la base del cinquè argument.

Com a comentari addicional, m'agradaria inserir un advertiment per a aquells que identifiquen la dificultat de la tasca de programació amb la lluita contra les deficiències de les nostres eines actuals, perquè podrien concloure que, un cop que les nostres eines siguin molt més adequades, la programació ja no ser un problema. La programació seguirà sent molt difícil, perquè una vegada que ens hàgim alliberat de la circumstància enutjosa actual, ens trobarem lliures per abordar els problemes que ara estan més enllà de la nostra capacitat de programació.

6.- Poden polemitzar amb el meu sisè argument, ja que no és tan fàcil recopilar evidència experimental per al seu suport, un fet que no em impedirà creure en la seva validesa. Fins ara no he esmentat la paraula "jerarquia", però crec que és just dir que aquest és un concepte clau per a tots els sistemes que incorporen una solució ben realitzada. Fins i tot podria anar un pas més enllà i fer un article de fe, és a dir, que els únics problemes que realment podem resoldre de manera satisfactòria són aquells que finalment admeten una solució ben realitzada. A primera vista, aquesta visió de les limitacions humanes pot semblar una visió bastant depriment de la nostra situació, però no ho sento així, al contrari! La millor manera d'aprendre a viure amb les nostres limitacions és conèixer-les.En el moment en què siguem prou modestos com per provar només solucions ben executades, pel fet que els altres esforços escapen al nostre control intel·lectual, farem tot el possible per evitar que totes aquestes interfícies perjudiquin la nostra capacitat d'emprar el sistema d'una manera útil . I no puc deixar d'esperar que això condueixi una altra vegada al descobriment que, després de tot, es pot abordar un problema considerat anteriorment com no tractable. Qualsevol que hagi vist com la majoria dels problemes de la fase de compilació anomenada "generació de codi" pot rastrejar-se fins les divertides propietats del codi d'ordres, coneixerà un exemple simple del tipus de coses que tinc en ment.L'aplicabilitat més àmplia de les solucions ben realitzades és el meu sisè i últim argument per a la viabilitat tècnica de la revolució que podria tenir lloc en la dècada actual.

En principi, et deixo decidir per tu mateix quant pes vas a donar als meus consideracions, sabent molt bé que no puc obligar a ningú més a compartir les meves creences. Com cada revolució seriosa, provocarà una oposició violenta i un pot preguntar-se on esperar que les forces conservadores intentin contrarestar tal desenvolupament. No els espero principalment en les grans empreses, ni tan sols en el negoci de les computadores; Els espero més aviat en les institucions educatives que brinden la capacitació d'avui i en aquests grups conservadors d'usuaris d'ordinadors que pensen que els seus vells programes són tan importants que no creuen que valgui la pena reescriure'ls i millorar-los. Referent a això,és trist observar que en molts campus universitaris l'elecció de la instal·lació central de computació sovint ha estat determinada per les demandes d'algunes aplicacions establertes però costoses, sense tenir en compte la pregunta quants milers de "petits usuaris" que estiguin disposats a escriure els seus propis programes patiràn per aquesta elecció. Massa sovint, per exemple, la física d'alta energia sembla haver fet xantatge a la comunitat científica amb el preu del seu equip experimental existent. La resposta més fàcil, per descomptat, és una negació rotunda de la viabilitat tècnica, però em temo que necessita arguments prou sòlids per això. No es pot obtenir seguretat, per desgràcia, de l'observació que el sostre intel·lectual del programador mitjana d'avui evitarà que la revolució tingui lloc: amb altres que programin de manera molt més efectiva, és probable que sigui eliminat de la foto de totes maneres.

També pot haver impediments polítics. Fins i tot si sabem com educar el programador professional del demà, no és segur que la societat en què vivim ens permeti fer-ho. El primer efecte d'ensenyar una metodologia -més que disseminar coneixement- és millorar les capacitats dels que ja són capaços, magnificant així la diferència en intel·ligència. En una societat en la qual el sistema educatiu s'utilitza com a instrument per a l'establiment d'una cultura homogeneïtzada, en la qual s'impedeix que la crema arribi al cim, l'educació de programadors competents seria difícil de dur a la pràctica.

Deixin-me concloure. Els ordinadors automàtics han estat amb nosaltres durant un quart de segle. Han tingut un gran impacte en la nostra societat en la seva capacitat com a eines, però en aquesta capacitat seva influència no serà més que una ondulació en la superfície de la nostra cultura, en comparació amb la influència molt més profunda que tindran en la seva capacitat de desafiament intel·lectual sense precedent en la història cultural de la humanitat. Els sistemes jeràrquics semblen tenir la propietat de que alguna cosa considerat com una entitat indivisa en un nivell, es considera com un objecte compost en el següent nivell inferior de major detall; Com a resultat, el gra natural d'espai o temps que és aplicable en cada nivell disminueix en un ordre de magnitud quan canviem la nostra atenció d'un nivell al següent nivell inferior.Entenem les parets en termes de maons, maons en termes de cristalls, cristalls en termes de molècules, etc. Com a resultat, el nombre de nivells que es poden distingir significativament en un sistema jeràrquic és una cosa proporcional al logaritme de la relació entre els més grans. i el gra més petit, i per tant, llevat que aquesta relació sigui molt gran, no podem esperar molts nivells. A la programació d'ordinadors, el nostre component bàsic té un temps associat de menys d'un microsegon, però el nostre programa pot prendre hores de temps de càlcul. No conec cap altra tecnologia que cobreixi una proporció de 10^10 o més: l'ordinador, en virtut de la seva fantàstica velocitat, sembla ser la primera a proporcionar-nos un entorn on els artefactes altament jeràrquics són possibles i necessaris.Aquest desafiament, a saber, la confrontació amb la tasca de programació és tan única que aquesta nova experiència pot ensenyar molt sobre nosaltres mateixos. Això, d'aprofundir la nostra comprensió dels processos de disseny i creació, hauria de donar-nos un millor control sobre la tasca d'organitzar els nostres pensaments. Si no fos així, al meu gust, no hauríem de merèixer l'ordinador en absolut!

Això ja ens ha donat algunes lliçons, i la que he triat destacar en aquesta xerrada és la següent: Farem un treball de programació molt millor, sempre que abordem la tasca amb una plena apreciació de la seva tremenda dificultat, sempre que ens atenim a llenguatges de programació modestos i elegants, sempre que respectem les limitacions intrínseques de la ment humana i abordem la tasca. com a programadors molt humils.

[1] https://es.wikipedia.org/wiki/Notaci%C3%B3n_de_Backus-Naur és un metallenguatge usat per expressar gramàtiques lliures de context: és a dir, una manera formal de descriure llenguatges formals.
[2] https://es.wikipedia.org/wiki/GOTOGOTO és una instrucció pròpia dels primers llenguatges de programació, com BASIC. Aquesta instrucció sol existir en tots els llenguatges encara que amb un mnemònic adaptat al propi llenguatge. La instrucció GOTO ha estat menyspreada en els llenguatges d'alt nivell, a causa de la dificultat que presenta per poder seguir adequadament el flux del programa, tan necessari per a verificar i corregir els programes.
[NT] (Traduint això, he tingut l'agradable sensació d'estar una estona dins dels raonaments i estructura mental d'una ment privilegiada i ben estructurada.) Revisat per segona vegada.