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.

El Programador Humilde

Conferencia 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 Humilde"
por:
Edsger W. Dijkstra

Como resultado de una larga secuencia de coincidencias, ingresé oficialmente a la profesión de programación la primera mañana de primavera de 1952 y, por lo que he podido rastrear, fui el primer holandés en hacerlo en mi país. En retrospectiva, lo más sorprendente fue la lentitud con la que, al menos en mi parte del mundo, surgió la profesión de programación, una lentitud que ahora es difícil de creer. Pero estoy agradecido por dos vívidos recuerdos de ese período que establecen esa lentitud más allá de cualquier duda.
 
Después de haber programado durante unos tres años, tuve una discusión con A. van Wijngaarden, quien era mi jefe en el Centro de Matemáticas en Amsterdam, una discusión por la cual estaré agradecido con él mientras viva. El punto era que se suponía que debía estudiar física teórica en la Universidad de Leiden simultáneamente, y cuando encontré las dos actividades cada vez más difíciles de compaginar, tuve que decidir, ya sea para dejar de programar y convertirme en un teórico real y respetable. físico, o para llevar mi estudio de física a una finalización formal solamente, con un mínimo de esfuerzo, y para convertirme en ..... ¿sí qué? ¿Un programador? ¿Pero era una profesión respetable? Después de todo, ¿qué era la programación? ¿Dónde estaba el sólido cuerpo de conocimiento que podría apoyarlo como una disciplina intelectualmente respetable? Recuerdo vívidamente cómo envidiaba a mis colegas de hardware, quienes, cuando se les preguntó acerca de su competencia profesional, al menos pudieron señalar que sabían todo acerca de los tubos de vacío, los amplificadores y el resto, mientras que sentí que, al enfrentar esa pregunta, yo se pararía con las manos vacías. Lleno de dudas, llamé a la puerta de la oficina de van Wijngaarden y le pregunté si podía "hablar con él por un momento"; Cuando salí de su oficina varias horas después, era otra persona. Después de haber escuchado mis problemas con paciencia, estuvo de acuerdo en que hasta ese momento no había mucha disciplina de programación, pero luego explicó en voz baja que las computadoras automáticas estaban aquí para quedarse, que estábamos al principio y podíamos ¿No podría ser yo una de las personas llamadas a hacer de la programación una disciplina respetable en los próximos años? Este fue un punto de inflexión en mi vida y completé mi estudio de física formalmente tan rápido como pude. Una moraleja de la historia anterior es, por supuesto, que debemos ser muy cuidadosos cuando damos consejos a las personas más jóvenes; a veces lo siguen!
 
Otros dos años después, en 1957, me casé y los ritos de matrimonio holandeses requieren que declares tu profesión y dije que era programador. Pero las autoridades municipales de la ciudad de Amsterdam no lo aceptaron porque no existía tal profesión. Y, lo creas o no, pero bajo el título "profesión", ¡mi acto de matrimonio muestra la ridícula entrada "físico teórico"!
 
Tanto por la lentitud con la que vi surgir la profesión de programación en mi propio país. Desde entonces, he visto más del mundo, y tengo la impresión general de que en otros países, además de un posible cambio de fechas, el patrón de crecimiento ha sido muy similar.

Permítanme tratar de capturar la situación en esos viejos tiempos con un poco más de detalle, con la esperanza de comprender mejor la situación actual. Mientras seguimos nuestro análisis, veremos cuántos malentendidos comunes sobre la verdadera naturaleza de la tarea de programación se remontan a ese pasado ahora distante.
 
Las primeras computadoras electrónicas automáticas eran todas máquinas únicas de ejemplares únicos y todas se encontraban en un entorno con el sabor emocionante de un laboratorio experimental. Una vez que la visión de la computadora automática estuvo allí, su realización fue un tremendo desafío para la tecnología electrónica disponible en ese momento, y una cosa es cierta: no podemos negar el coraje de los grupos que decidieron intentar construir un equipo tan fantástico. Para equipos fantásticos eran: en retrospectiva, uno solo puede preguntarse si esas primeras máquinas funcionaron, al menos algunas veces. El problema abrumador era conseguir y mantener la máquina funcionando correctamente. La preocupación por los aspectos físicos de la informática automática todavía se refleja en los nombres de las sociedades científicas más antiguas en el campo, como la Asociación de Maquinaria de Computación (ACM) o la Sociedad Británica de Computación, nombres en los que se hace referencia explícita al equipo físico.

¿Qué pasa con el pobre programador? Bueno, para decir la verdad sincera: apenas lo notaron. Por un lado, las primeras máquinas eran tan voluminosas que apenas podía moverlas y, además, requerían un mantenimiento tan extenso que era bastante natural que el lugar donde las personas intentaran usar la máquina fuera el mismo laboratorio donde se había desarrollado la máquina. . En segundo lugar, su trabajo algo invisible era sin glamour: se podía mostrar la máquina a los visitantes y eso era varios órdenes de magnitud más espectacular que algunas hojas de codificación. Pero lo más importante de todo, el propio programador tenía una visión muy modesta de su propio trabajo: su trabajo derivaba todo su significado de la existencia de esa maravillosa máquina. Como se trataba de una máquina única, sabía muy bien que sus programas solo tenían un significado local y, como era obvio que esta máquina tendría una vida útil limitada, sabía que muy poco de su trabajo tendría un valor duradero. Finalmente, hay otra circunstancia que tuvo una profunda influencia en la actitud del programador hacia su trabajo: por un lado, además de no ser confiable, su máquina generalmente era demasiado lenta y su memoria era demasiado pequeña, es decir, se enfrentaba a un dolor en el zapato, mientras que, por otro lado, su código de orden, por lo general un tanto extraño, satisfaría las construcciones más inesperadas. Y en aquellos días, muchos programadores inteligentes obtuvieron una inmensa satisfacción intelectual de los trucos astutos mediante los cuales se las arregló para comprimirlo todo hasta lo imposible para adaptarse a las limitaciones de su equipo.
 
Dos opiniones sobre programación en aquellos dias. Los menciono ahora, volveré sobre ellos más tarde. La única opinión era que un programador realmente competente debería ser ingenioso y muy aficionado a los trucos inteligentes; la otra opinión era que la programación no era más que optimizar la eficiencia del proceso computacional, en una dirección u otra.
La última opinión fue el resultado de la frecuente circunstancia de que, de hecho, el equipo disponible era como un doloroso zapato que, y en esos días a menudo se encontraban con la ingenua expectativa de que una vez que hubiera máquinas más potentes disponibles, la programación ya no sería un problema, porque entonces la lucha para llevar la máquina al límite ya no sería necesaria ya que de eso se trataba la programación, ¿no? Pero en las siguientes décadas sucedió algo completamente diferente: máquinas más potentes estuvieron disponibles, no solo un orden de magnitud más poderoso, incluso varios órdenes de magnitud más potentes. Pero en lugar de encontrarnos en el estado de felicidad eterna de todos los problemas de programación resueltos, ¡nos encontramos hasta el cuello en la crisis del software! ¿Cómo podía ser?
 
Hay una causa menor: en uno o dos aspectos, la maquinaria moderna es básicamente más difícil de manejar que la maquinaria antigua. En primer lugar, tenemos las interrupciones de E/S, que ocurren en momentos impredecibles e irreproducibles; En comparación con la vieja máquina secuencial que pretendía ser un autómata totalmente determinista, este ha sido un cambio dramático y muchas canas de un programador de sistemas dan testimonio del hecho de que no debemos hablar a la ligera sobre los problemas lógicos creados por esa característica. En segundo lugar, tenemos máquinas equipadas con varios niveles de almacenamiento, lo que nos presenta problemas de estrategia de gestión que, a pesar de la extensa literatura sobre el tema, siguen siendo bastante esquivas. Esto aún más, con la complicación adicional debida a los cambios estructurales de las máquinas reales.
 
Pero llamé a esto una causa menor:  La causa principal es ... ¡que las máquinas se han vuelto más poderosas en varios órdenes de magnitud! Para decirlo sin rodeos: mientras no hubiera máquinas, la programación no era un problema en absoluto; cuando teníamos algunas computadoras débiles, la programación se convirtió en un problema leve, y ahora tenemos computadoras gigantes, la programación se convirtió en un problema igualmente gigantesco. En este sentido, la industria electrónica no ha resuelto un solo problema, solo los ha creado, ha creado el problema de usar sus productos. Para decirlo de otra manera: a medida que el poder de las máquinas disponibles creció en un factor de más de mil, la ambición de la sociedad de aplicar estas máquinas creció en proporción, y fue el pobre programador quien encontró su trabajo en este campo de tensión explotado entre fines y medios. La mayor potencia del hardware, junto con el aumento quizás aún más dramático en su confiabilidad, hizo posibles las soluciones con las que el programador no se había atrevido a soñar unos años antes. Y ahora, unos años más tarde, tuvo que soñar con ellos y, lo que es peor, ¡tuvo que transformar tales sueños en realidad! ¿Es sorprendente que nos encontremos en una crisis de software? No, ciertamente no, y como puede suponer, incluso se predijo con mucha antelación; pero el problema con los profetas menores, por supuesto, es que solo cinco años después se sabe realmente que tenían razón.
 
Luego, a mediados de los años sesenta, sucedió algo terrible: las computadoras de la llamada tercera generación hicieron su aparición. La literatura oficial nos dice que su relación precio / rendimiento ha sido uno de los principales objetivos de diseño. Pero si toma como "rendimiento" el ciclo de trabajo de los diversos componentes de la máquina, poco evitará que termine con un diseño en el que la mayor parte de su objetivo de rendimiento se alcanza mediante actividades internas de mantenimiento de dudosa necesidad. Y si su definición de precio es el precio que se pagará por el hardware, poco evitará que termine con un diseño que es terriblemente difícil de programar: por ejemplo, el código de pedido podría aplicarse, ya sea al programador o sobre el sistema, decisiones vinculantes tempranas que presentan conflictos que realmente no pueden resolverse. Y en gran medida, estas desagradables posibilidades parecen haberse convertido en realidad.

Cuando se anunciaron estas máquinas y se conocieron sus especificaciones funcionales, muchos de nosotros debimos de ser bastante poco fiables; Al menos yo lo fuí. Era razonable esperar que tales máquinas inundaran la comunidad informática y, por lo tanto, era aún más importante que su diseño fuera lo más sólido posible. Pero el diseño encarnaba defectos tan graves que sentí que de un solo golpe el progreso de la ciencia informática se había retrasado al menos diez años: fue entonces cuando tuve la semana más negra de toda mi vida profesional. Quizás lo más triste ahora es que, incluso después de todos esos años de experiencia frustrante, mucha gente cree sinceramente que alguna ley de la naturaleza nos dice que las máquinas tienen que ser así. Silencian sus dudas observando cuántas de estas máquinas se han vendido, y derivaban de esa observación la falsa sensación de seguridad de que, después de todo, el diseño no podría haber sido tan malo. Pero después de una inspección más cercana, esa línea de defensa tuvo la misma fuerza convincente que el argumento de que fumar cigarrillos debe ser saludable porque muchas personas lo hacen.

Es en este sentido que lamento que no sea habitual que las revistas científicas en el área de la informática publiquen revisiones de las computadoras recién anunciadas de la misma manera que revisamos las publicaciones científicas: revisar las máquinas sería al menos tan importante. Y aquí tengo una confesión que hacer: a principios de los años sesenta escribí tal revisión con la intención de presentarla al CACM, pero a pesar del hecho de que los pocos colegas a quienes se envió el texto para su consejo, me instaron para hacerlo, no me atreví a hacerlo, temiendo que las dificultades, tanto para mí como para el comité editorial, demostraran ser demasiado grandes. Esta supresión fue un acto de cobardía de mi parte por el cual me culpo cada vez más. Las dificultades que preveía eran consecuencia de la ausencia de criterios generalmente aceptados, y aunque estaba convencido de la validez de los criterios que había elegido aplicar, temía que mi revisión fuera rechazada o descartada como "una cuestión de gusto personal". . Todavía pienso que tales revisiones serían extremadamente útiles y anhelo verlas aparecer, ya que su apariencia aceptada sería un signo seguro de madurez de la comunidad informática.



La razón por la que he prestado la atención anterior a la escena del hardware es porque tengo la sensación de que uno de los aspectos más importantes de cualquier herramienta informática es su influencia en los hábitos de pensamiento de aquellos que intentan usarla, y porque tengo razones creer que esa influencia es muchas veces más fuerte de lo que comúnmente se supone. Pasemos ahora nuestra atención a la escena del software.
 
Aquí la diversidad ha sido tan grande que debo limitarme a unos pocos peldaños. Soy dolorosamente consciente de la arbitrariedad de mi elección y le ruego que no saque ninguna conclusión con respecto a mi agradecimiento por los muchos esfuerzos que quedarán sin mencionar.
 
1.-Al principio existía el EDSAC en Cambridge, Inglaterra, y creo que es bastante impresionante que desde el principio la noción de una biblioteca de subrutinas desempeñara un papel central en el diseño de esa máquina y de la forma en que debería usarse. Han pasado casi 25 años y la escena informática ha cambiado drásticamente, pero la noción de software básico todavía está con nosotros, y la noción de subrutina cerrada sigue siendo uno de los conceptos clave en la programación. Deberíamos reconocer las subrutinas cerradas como una de las mejores invenciones de software; ha sobrevivido a tres generaciones de computadoras y sobrevivirá a unas pocas más, porque abastece la implementación de uno de nuestros patrones básicos de abstracción. Lamentablemente, su importancia se ha subestimado en el diseño de las computadoras de tercera generación, en la que la gran cantidad de registros explícitamente nombrados de la unidad aritmética implica una gran sobrecarga en el mecanismo de subrutina. Pero incluso eso no eliminó el concepto de la subrutina, y solo podemos rezar para que la mutación no resulte hereditaria.
 
2.-El segundo desarrollo importante en la escena del software que me gustaría mencionar es el nacimiento de FORTRAN. En ese momento, este era un proyecto de gran temeridad y las personas responsables de él merecen nuestra gran admiración. Sería completamente injusto culparlos por las deficiencias que solo se hicieron evidentes después de una década de uso extenso: ¡los grupos con una anticipación exitosa de diez años son bastante raros! En retrospectiva, debemos calificar a FORTRAN como una técnica de codificación exitosa, pero con muy pocas ayudas efectivas para la concepción, ayudas que ahora se necesitan con tanta urgencia que ha llegado el momento de considerarla desactualizada. Cuanto antes podamos olvidar que FORTRAN ha existido, mejor, porque como vehículo de pensamiento ya no es adecuado: desperdicia nuestra capacidad intelectual, es demasiado arriesgado y, por lo tanto, demasiado costoso de usar. El destino trágico de FORTRAN ha sido su amplia aceptación, encadenando mentalmente a miles y miles de programadores a nuestros errores pasados. Rezo diariamente para que más de mis compañeros programadores encuentren los medios para liberarse de la maldición de la compatibilidad.
 
3.-El tercer proyecto que no quisiera dejar sin mencionar es LISP, una empresa fascinante de naturaleza completamente diferente. Con unos pocos principios muy básicos en su base, ha demostrado una notable estabilidad. Además de eso, LISP ha sido el proveedor de una considerable cantidad de aplicaciones informáticas más sofisticadas. LISP ha sido descrito en broma como "la forma más inteligente de hacer un mal uso de una computadora". Creo que esa descripción es un gran cumplido porque transmite todo el sabor de la liberación: ha ayudado a varios de nuestros seres humanos más talentosos a elaborar pensamientos que antes eran imposibles.
 
4.-El cuarto proyecto a mencionar es ALGOL 60. Mientras que hasta el día de hoy los programadores de FORTRAN todavía tienden a comprender su lenguaje de programación en términos de la implementación específica con la que están trabajando, de ahí la prevalencia de los volcados octal y hexadecimal, mientras que la definición de LISP sigue siendo una curiosa mezcla de lo que significa el lenguaje y cómo funciona el mecanismo, el famoso Informe sobre el lenguaje algorítmico ALGOL 60 es el fruto de un esfuerzo genuino para llevar la abstracción un paso vital más adelante y definir un lenguaje de programación en una implementación. forma independiente ¡Se podría argumentar que a este respecto sus autores han tenido tanto éxito que han creado serias dudas sobre si podría implementarse en absoluto! El informe demostró gloriosamente el poder del método formal BNF, ahora bastante conocido como Notación de Backus-Naur-Form [1], y el poder del inglés cuidadosamente redactado, al menos cuando es utilizado por alguien tan brillante como Peter Naur. Creo que es justo decir que solo unos pocos documentos tan cortos como este han tenido una influencia igualmente profunda en la comunidad informática. La facilidad con la que, en años posteriores, los nombres ALGOL y ALGOL-like se han utilizado, como una marca comercial desprotegida, para prestar parte de su gloria a una serie de proyectos más jóvenes, a veces poco relacionados, es un complemento un tanto impactante para su posición. La fuerza de BNF como dispositivo de definición es responsable de lo que considero una de las debilidades del lenguaje: una sintaxis demasiado elaborada y no demasiado sistemática ahora podría estar metida en los límites de muy pocas páginas. Con un dispositivo tan poderoso como BNF, el Informe sobre el lenguaje algorítmico ALGOL 60 debería haber sido mucho más corto. Además de eso, dudo mucho sobre el mecanismo de parámetros de ALGOL 60: permite al programador tanta libertad combinatoria que su uso seguro requiere una disciplina fuerte por parte del programador. Además de costoso de implementar, parece peligroso de usar.
 
5.-Finalmente, aunque el tema no es agradable, debo mencionar PL/1, un lenguaje de programación para el cual la documentación definitoria es de un tamaño y complejidad alarmantes. Usar PL/1 debe ser como volar un avión con 7000 botones, interruptores y manijas para manipular en la cabina. Absolutamente no veo cómo podemos mantener nuestros programas en crecimiento firmemente dentro de nuestro control intelectual cuando, por su barroco puro, el lenguaje de programación —nuestra herramienta básica, eso sí! - ya escapa a nuestro control intelectual. Y si tengo que describir la influencia que PL/1 puede tener en sus usuarios, la metáfora más cercana que me viene a la mente es la de una droga. Recuerdo de un simposio sobre lenguaje de programación de nivel superior una conferencia dada en defensa de PL/1 por un hombre que se describió a sí mismo como uno de sus usuarios dedicados. Pero dentro de una conferencia de una hora en elogio de PL/1, se las arregló para pedir la adición de unas cincuenta nuevas "características", cuando era de suponer que la fuente principal de sus problemas podría ser que contenía demasiadas "características". El orador mostró todos los síntomas deprimentes de la adicción, reducidos al estado de estancamiento mental en el que solo podía pedir más, más, más ... Así como cuando FORTRAN ha sido descrito como trastorno infantil, el PL/1 completo, con sus crecientes características de tumor maligno, podría llegar a ser considerado como una enfermedad mortal.
 
Ya he hablado demasiado sobre el pasado. Pero no tiene sentido cometer errores a menos que luego podamos aprender de ellos. De hecho, creo que hemos aprendido tanto, que dentro de unos años la programación puede llegar a ser una actividad muy diferente de lo que ha sido hasta ahora, tan diferente que es mejor que nos preparemos para el choque. Déjeme bosquejar uno de los futuros posibles. A primera vista, esta visión de la programación quizás en un futuro cercano tal vez pueda parecer absolutamente fantástica. Permítanme, por lo tanto, agregar también las consideraciones que pueden llevar a la conclusión de que esta visión podría ser una posibilidad muy real.
 
La visión es que, mucho antes de que los años setenta se hayan completado, podremos diseñar e implementar el tipo de sistemas que ahora están agotando nuestra capacidad de programación, a expensas de solo un pequeño porcentaje en años-hombre de lo que cuestan ahora, y además de eso, estos sistemas estarán prácticamente libres de errores. Estas dos mejoras van de la mano. En este último aspecto, el software parece ser diferente de muchos otros productos, donde, por regla general, una mayor calidad implica un precio más alto. Aquellos que quieran un software realmente confiable descubrirán que deben encontrar medios para evitar la mayoría de los errores desde el principio, y como resultado el proceso de programación se volverá más barato. Si desea programadores más efectivos, descubrirán que no deben perder el tiempo depurando, no deben introducir errores para comenzar. En otras palabras: ambos objetivos apuntan al mismo cambio.
 
Un cambio tan drástico en un período de tiempo tan corto sería una revolución, y para todas las personas que basan sus expectativas para el futuro en una extrapolación sin problemas del pasado reciente, en apego a algunas leyes no escritas de inercia social y cultural, la posibilidad de que se produzcaá un cambio drástico puede parecer insignificante. ¡Pero todos sabemos que a veces ocurren revoluciones! ¿Y cuáles son las posibilidades de ésta?
 
Parece que hay tres condiciones principales que deben cumplirse. El mundo en general debe reconocer la necesidad del cambio; en segundo lugar, la necesidad económica debe ser lo suficientemente fuerte; y, en tercer lugar, el cambio debe ser técnicamente factible. Permítanme discutir estas tres condiciones en el orden anterior.
 
1.-Con respecto al reconocimiento de la necesidad de una mayor fiabilidad del software, ya no espero desacuerdos. Hace solo unos años, esto era diferente: hablar de una crisis de software era una blasfemia. El punto de inflexión fue la Conferencia sobre Ingeniería de Software en Garmisch, octubre de 1968, una conferencia que creó una sensación cuando se produjo la primera admisión abierta de la crisis del software. Y a estas alturas generalmente se reconoce que el diseño de cualquier sistema sofisticado grande será un trabajo muy difícil, y cada vez que uno se encuentra con personas responsables de tales emprendimientos, uno se encuentra muy preocupado por el problema de la fiabilidad, y con razón. En resumen, nuestra primera condición parece haber sido satisfecha.
 
2.-Ahora, la necesidad económica. Hoy en día, a menudo se encuentra la opinión de que en los años sesenta la programación era una profesión sobrepagada, y que en los próximos años se espera que los salarios de los programadores bajen. Por lo general, esta opinión se expresa en relación con la recesión, pero podría ser un síntoma de algo diferente y bastante saludable, a saber. que tal vez los programadores de la última década no hayan hecho un trabajo tan bueno como deberían haberlo hecho. La sociedad se está insatisfecha con el desempeño de los programadores y de sus productos. Pero hay otro factor de mucho mayor peso. En la situación actual, es bastante habitual que para un sistema específico, el precio a pagar por el desarrollo del software sea del mismo orden de magnitud que el precio del hardware necesario, y la sociedad lo acepta más o menos. Pero los fabricantes de hardware nos dicen que en la próxima década se puede esperar que los precios del hardware bajen con un factor de diez. Si el desarrollo de software continuara siendo el mismo proceso torpe y costoso que es ahora, las cosas se saldrían completamente de balance. No puede esperar que la sociedad acepte esto y, por lo tanto, debemos aprender a programar un orden de magnitud con mayor eficacia. Para decirlo de otra manera: siempre y cuando las máquinas sean el elemento más importante en el presupuesto, la profesión de programación podría salirse con la suya con sus técnicas torpes, pero ese paraguas se doblará rápidamente. En resumen, también nuestra segunda condición parece estar satisfecha.
 
3.-Y ahora la tercera condición: ¿es técnicamente factible? Creo que podría serlo y le daré seis argumentos en apoyo de esa opinión.
 
Un estudio de la estructura de los programas reveló que éstos, incluso los  alternativos para la misma tarea y con el mismo contenido matemático, pueden diferir enormemente en su capacidad de gestión intelectual. Se han descubierto varias reglas, cuya violación perjudicará gravemente o destruirá totalmente la capacidad de gestión intelectual del programa. Estas reglas son de dos tipos. Los del primer tipo se imponen fácilmente mecánicamente, a saber. por un lenguaje de programación adecuadamente elegido. Ejemplos son la exclusión de declaraciones goto[2] y de procedimientos con más de un parámetro de salida. Para aquellos del segundo tipo, al menos, pero eso puede deberse a la falta de competencia por mi parte, no veo forma de imponerlo mecánicamente, ya que parece necesitar algún tipo de comprobador de teoremas automático para el que no tengo pruebas de su existencia. Por lo tanto, por el momento y quizás para siempre, las reglas del segundo tipo se presentan como elementos de disciplina requeridos para el programador. Algunas de las reglas que tengo en mente son tan claras que pueden enseñarse y nunca sería necesario discutir si un programa determinado las viola o no. Ejemplos son el requerimiento de que no debe escribirse ningún bucle sin proporcionar una prueba de finalización ni sin indicar la relación cuya invariabilidad no será destruida por la ejecución de la declaración repetible.
 
Ahora sugiero que nos limitemos al diseño e implementación de programas intelectualmente manejables. Si alguien teme que esta restricción sea tan severa que no podamos vivir con ella, puedo tranquilizarlo: la clase de programas intelectualmente manejables sigue siendo lo suficientemente rica como para contener muchos programas muy realistas para cualquier problema capaz de tener una solución algorítmica. No debemos olvidar que no es nuestro negocio hacer programas, es nuestro negocio diseñar clases de cómputos que muestren el comportamiento deseado. La sugerencia de limitarnos a programas manejables intelectualmente es la base de los primeros dos de mis seis argumentos anunciados:
 
1.- El primer argumento es que, dado que el programador solo necesita considerar programas manejables intelectualmente, las alternativas que está eligiendo deben ser mucho más fáciles de manejar.
 
2.- El segundo argumento consiste en que, tan pronto como hayamos decidido restringirnos al subconjunto de los programas intelectualmente manejables, habremos logrado, de una vez por todas, una reducción drástica del espacio de solución a considerar. Y este argumento es distinto del argumento uno.
 
3.- El argumento tres se basa en el enfoque constructivo del problema de la corrección del programa. Hoy una técnica habitual es hacer un programa y luego probarlo. Pero: las pruebas de programa pueden ser una forma muy efectiva de mostrar la presencia de errores, pero es irremediablemente inadecuado para mostrar su ausencia. La única forma efectiva de aumentar significativamente el nivel de confianza de un programa es dar una prueba convincente de su corrección. Pero primero no se debe hacer el programa y luego probar su idoneidad, porque entonces el requisito de proporcionar la prueba solo aumentaría la carga del pobre programador. Por el contrario: el programador debe permitir que la prueba de corrección y el programa crezcan de la mano. El argumento tres se basa esencialmente en la siguiente observación: Si primero se pregunta cuál sería la estructura de una prueba convincente y, una vez encontrado esto, construye un programa que satisfaga los requisitos de esta prueba, estas preocupaciones de corrección resultarían ser una guía heurística muy efectiva. Por definición, este enfoque solo es aplicable cuando nos limitemos a programas manejables intelectualmente, pero nos proporciona medios efectivos para encontrar uno satisfactorio entre estos.
 
4.- El argumento cuatro tiene que ver con la forma en que la cantidad de esfuerzo intelectual necesario para diseñar un programa depende de la longitud del programa. Se ha sugerido que hay algún tipo de ley de la naturaleza que nos dice que la cantidad de esfuerzo intelectual que se necesita aumenta con el cuadrado de la longitud del programa. Pero, gracias a Dios, nadie ha podido probar esta ley. Y esto se debe a que no tiene por qué ser cierta. Todos sabemos que la única herramienta mental por medio de la cual un razonamiento muy finito puede cubrir una miríada de casos se llama "abstracción"; Como resultado, la explotación efectiva de sus poderes de abstracción debe considerarse como una de las actividades más vitales de un programador competente. En este sentido, podría valer la pena señalar que el propósito de la abstracción no es ser vago, sino crear un nuevo nivel semántico en el que uno pueda ser absolutamente preciso. Por supuesto, he tratado de encontrar una causa fundamental que impida que nuestros mecanismos de abstracción sean lo suficientemente efectivos. Pero no importa cuánto lo intenté, no encontré tal causa. Como resultado, tiendo a suponer, y hasta ahora no ha sido refutado por la experiencia, que mediante la aplicación adecuada de nuestros poderes de abstracción, el esfuerzo intelectual necesario para concebir o comprender un programa no necesita crecer más que proporcionalmente a la duración del programa. Pero un subproducto de estas investigaciones puede tener una importancia práctica mucho mayor y, de hecho, es la base de mi cuarto argumento: El subproducto fue la identificación de una serie de patrones de abstracción que juegan un papel vital en todo el proceso de componer programas. Ahora se sabe lo suficiente sobre estos patrones de abstracción a los que podría dedicar una conferencia sobre cada uno de ellos. Lo que la familiaridad y el conocimiento consciente de estos patrones de abstracción implican y me dí cuenta de ello, es que si hubieran sido de conocimiento común hace quince años, el paso de BNF a compiladores dirigidos por sintaxis, por ejemplo, podría haber tomado unos minutos en lugar de unos años. Por lo tanto, presento nuestro conocimiento reciente de los patrones de abstracción como algo vital como cuarto argumento.
 
5.- Ahora el quinto argumento: Tiene que ver con la influencia de la herramienta que estamos tratando de usar sobre nuestros propios hábitos de pensamiento. Observo una tradición cultural, que probablemente tiene sus raíces en el Renacimiento, de ignorar esta influencia, considerar la mente humana como el maestro supremo y autónomo de sus artefactos. Pero si empiezo a analizar los hábitos de pensamiento de mí mismo y de mis semejantes, llego, me guste o no, a una conclusión completamente diferente, a saber: Que las herramientas que estamos tratando de usar y el lenguaje o la notación que estamos usando para expresar o registrar nuestros pensamientos, son los principales factores que determinan lo que podemos pensar o expresar !!. El análisis de la influencia que los lenguajes de programación tienen en los hábitos de pensamiento de sus usuarios, y el reconocimiento de que, por ahora, la capacidad intelectual es, con mucho, nuestro recurso más escaso, juntos nos dan una nueva colección de criterios para comparar los méritos relativos de los distintos lenguajes de programación. El programador competente es plenamente consciente del tamaño estrictamente limitado de su propio cráneo; por lo tanto, aborda la tarea de programación con total humildad y, entre otras cosas, huye de los trucos ingeniosos como de la peste. En el caso de un lenguaje de programación conversacional bien conocido, me han dicho desde varios lados que tan pronto como una comunidad de programación está equipada con un terminal para él, ocurre un fenómeno específico que incluso tiene un nombre bien establecido: se llama "las frases de una sola línea". Toma una de dos formas diferentes: un programador coloca un programa de una línea en el escritorio de otro y con orgullo dice lo que hace y agrega la pregunta "¿Puedes codificar esto con menos símbolos?", ¡Como si tuviera alguna relevancia conceptual! - o simplemente preguntar "¡Adivina qué hace!". De esta observación debemos concluir que este lenguaje como herramienta es una invitación abierta a trucos ingeniosos, y aunque exactamente esta pudiera ser la exposición pública de algunos de los recursos disponibles de aquellos a quienes les gusta mostrar cuán inteligentes son, lo siento, pero debo considerar esto como una de las cosas más condenatorias que se pueden decir sobre un lenguaje de programación. Otra lección que deberíamos haber aprendido del pasado reciente es que el desarrollo de lenguajes de programación “más ricos” o “más poderosos” fue un error en el sentido de que estas monstruosidades barrocas, estos conglomerados de idiosincrasias, son realmente inmanejables, tanto mecánica como mentalmente. Veo un gran futuro para lenguajes de programación muy sistemáticos y muy modestos. Cuando digo "modesto", quiero decir que, por ejemplo, no solo la "cláusula for" de ALGOL 60, sino incluso el "bucle DO" de FORTRAN podrían verse expulsados ​​por ser demasiado barrocos. He realizado un pequeño experimento de programación con voluntarios realmente experimentados, pero algo bastante inesperado apareció. Ninguno de mis voluntarios encontró la solución obvia y más elegante. Tras un análisis más detallado, esto resultó tener una fuente común: su noción de repetición estaba tan estrechamente relacionada con la idea de una variable controlada asociada que se fuera incrementando, que se bloquearon mentalmente sin poder ver lo obvio. Sus soluciones fueron menos eficientes, innecesariamente difíciles de entender, y les llevó mucho tiempo encontrarlas. Fue una experiencia reveladora pero también impactante para mí. Finalmente, en un aspecto, uno espera que los lenguajes de programación del mañana difieran mucho de lo que estamos acostumbrados hasta ahora: y en un grado mucho mayor que hasta ahora, deberían invitarnos a reflexionar en la estructura de lo que escribimos, en todas las abstracciones necesarias para enfrentar conceptualmente la complejidad de lo que estamos diseñando. Hasta aquí en cuanto a la mayor adecuación de nuestras herramientas futuras, ha sido la base del quinto argumento.
 
Como comentario adicional, me gustaría insertar una advertencia para aquellos que identifican la dificultad de la tarea de programación con la lucha contra las deficiencias de nuestras herramientas actuales, porque podrían concluir que, una vez que nuestras herramientas sean mucho más adecuadas, la programación ya no ser un problema. La programación seguirá siendo muy difícil, porque una vez que nos hayamos liberado de la circunstancia engorrosa actual, nos encontraremos libres para abordar los problemas que ahora están más allá de nuestra capacidad de programación.
 
6.- Pueden polemizar con mi sexto argumento, ya que no es tan fácil recopilar evidencia experimental para su apoyo, un hecho que no me impedirá creer en su validez. Hasta ahora no he mencionado la palabra "jerarquía", pero creo que es justo decir que este es un concepto clave para todos los sistemas que incorporan una solución bien realizada. Incluso podría ir un paso más allá y hacer un artículo de fe, a saber, que los únicos problemas que realmente podemos resolver de manera satisfactoria son aquellos que finalmente admiten una solución bien realizada. A primera vista, esta visión de las limitaciones humanas puede parecer una visión bastante deprimente de nuestra situación, ¡pero no lo siento así, al contrario! La mejor manera de aprender a vivir con nuestras limitaciones es conocerlas. En el momento en que seamos lo suficientemente modestos como para probar sólo soluciones bien ejecutadas, debido a que los otros esfuerzos escapan a nuestro control intelectual, haremos todo lo posible para evitar que todas esas interfaces perjudiquen nuestra capacidad de emplear el sistema de una manera útil. Y no puedo dejar de esperar que esto conduzca otra vez al descubrimiento de que, después de todo, se puede abordar un problema considerado anteriormente como no tratable. Cualquiera que haya visto cómo la mayoría de los problemas de la fase de compilación llamada "generación de código" puede rastrearse hasta las divertidas propiedades del código de órdenes, conocerá un ejemplo simple del tipo de cosas que tengo en mente. La aplicabilidad más amplia de las soluciones bien realizadas es mi sexto y último argumento para la viabilidad técnica de la revolución que podría tener lugar en la década actual.
 
En principio, te dejo decidir por ti mismo cuánto peso vas a dar a mis consideraciones, sabiendo muy bien que no puedo obligar a nadie más a compartir mis creencias. Como cada revolución seria, provocará una oposición violenta y uno puede preguntarse dónde esperar que las fuerzas conservadoras intenten contrarrestar tal desarrollo. No los espero principalmente en las grandes empresas, ni siquiera en el negocio de las computadoras; Los espero más bien en las instituciones educativas que brindan la capacitación de hoy y en esos grupos conservadores de usuarios de computadoras que piensan que sus viejos programas son tan importantes que no creen que valga la pena reescribirlos y mejorarlos. A este respecto, es triste observar que en muchos campus universitarios la elección de la instalación central de computación a menudo ha sido determinada por las demandas de algunas aplicaciones establecidas pero costosas, sin tener en cuenta la pregunta cuántos miles de "pequeños usuarios" que estén dispuestos a escribir sus propios programas iban a sufrir por esta elección. Con demasiada frecuencia, por ejemplo, la física de alta energía parece haber chantajeado a la comunidad científica con el precio de su equipo experimental existente. La respuesta más fácil, por supuesto, es una negación rotunda de la viabilidad técnica, pero me temo que necesita argumentos bastante sólidos para eso. No se puede obtener seguridad, por desgracia, de la observación de que el techo intelectual del programador promedio de hoy evitará que la revolución tenga lugar: con otros que programen de manera mucho más efectiva, es probable que sea eliminado de la foto de todos modos.
 
También puede haber impedimentos políticos. Incluso si sabemos cómo educar al programador profesional del mañana, no es seguro que la sociedad en la que vivimos nos permita hacerlo. El primer efecto de enseñar una metodología —más que diseminar conocimiento— es mejorar las capacidades de los que ya son capaces, magnificando así la diferencia en inteligencia. En una sociedad en la que el sistema educativo se utiliza como instrumento para el establecimiento de una cultura homogeneizada, en la que se impide que la crema llegue a la cima, la educación de programadores competentes podría ser difícil de llevar a la práctica.
 
Déjenme concluir. Las computadoras automáticas han estado con nosotros durante un cuarto de siglo. Han tenido un gran impacto en nuestra sociedad en su capacidad como herramientas, pero en esa capacidad su influencia no será más que una ondulación en la superficie de nuestra cultura, en comparación con la influencia mucho más profunda que tendrán en su capacidad de desafío intelectual sin precedente en la historia cultural de la humanidad. Los sistemas jerárquicos parecen tener la propiedad de que algo considerado como una entidad indivisa en un nivel, se considera como un objeto compuesto en el siguiente nivel inferior de mayor detalle; Como resultado, el grano natural de espacio o tiempo que es aplicable en cada nivel disminuye en un orden de magnitud cuando cambiamos nuestra atención de un nivel al siguiente nivel inferior. Entendemos las paredes en términos de ladrillos, ladrillos en términos de cristales, cristales en términos de moléculas, etc. Como resultado, el número de niveles que se pueden distinguir significativamente en un sistema jerárquico es algo proporcional al logaritmo de la relación entre los más grandes. y el grano más pequeño, y por lo tanto, a menos que esta relación sea muy grande, no podemos esperar muchos niveles. En la programación de computadoras, nuestro componente básico tiene un tiempo asociado de menos de un microsegundo, pero nuestro programa puede tomar horas de tiempo de cálculo. No conozco ninguna otra tecnología que cubra una proporción de 10^10 o más: la computadora, en virtud de su fantástica velocidad, parece ser la primera en proporcionarnos un entorno donde los artefactos altamente jerárquicos son posibles y necesarios. Este desafío, a saber. La confrontación con la tarea de programación es tan única que esta novedosa experiencia puede enseñarnos mucho sobre nosotros mismos. Esto, debería profundizar nuestra comprensión de los procesos de diseño y creación, debería darnos un mejor control sobre la tarea de organizar nuestros pensamientos. Si no fuera así, a mi gusto, ¡no deberíamos merecer la computadora en absoluto!
 
Esto ya nos ha dado algunas lecciones, y la que he elegido destacar en esta charla es la siguiente: Haremos un trabajo de programación mucho mejor, siempre que abordemos la tarea con una plena apreciación de su tremenda dificultad, siempre que nos atenemos a lenguajes de programación modestos y elegantes, siempre que respetemos las limitaciones intrínsecas de la mente humana y abordemos la tarea. como programadores muy humildes.

[1] https://es.wikipedia.org/wiki/Notaci%C3%B3n_de_Backus-Naur  es un metalenguaje usado para expresar gramáticas libres de contexto: es decir, una manera formal de describir lenguajes formales.
[2] https://es.wikipedia.org/wiki/GOTO GOTO es una instrucción propia de los primeros lenguajes de programación, como BASIC. Esta instrucción suele existir en todos los lenguajes aunque con un mnemónico adaptado al propio lenguaje. La instrucción GOTO ha sido menospreciada en los lenguajes de alto nivel, debido a la dificultad que presenta para poder seguir adecuadamente el flujo del programa, tan necesario para verificar y corregir los programas.
[NT] (Traduciendo esto, he tenido la momentánea y placentera sensación de estar un tiempo dentro de los razonamientos y estructura mental de una mente privilegiada y bien estructurada.)