EL LENGUAJE DE LOS CIEN AOS

Abril 2003
(Este ensayo se deriva de una presentacin en PyCon 2003.)
Es difcil predecir como ser la vida dentro de cien aos. Slo hay unas pocas cosas que podemos mencionar
con certeza. Sabemos que todo el mundo conducir coches voladores, que las leyes de zonificacin se
relajaran para permitir edificios de cientos de pisos de altura, que estar oscuro la mayor parte del tiempo, y
que todas las mujeres estarn entrenadas en artes marciales. Aqu quisiera enfocarme en un detalle de esta
visin. Qu tipo de lenguaje de programacin usaran para escribir el software que controlara esos coches
voladores?
Vale la pena considerar esto no tanto porque en realidad llegaremos a utilizar estos lenguajes, sino porque,
si tenemos suerte, en el camino utilizaremos lenguajes desde este punto hasta ese.
Creo que, al igual que las especies, los lenguajes formarn rboles evolutivos, con callejones sin salida
brotando por todas partes. Podemos ver que esto ya est sucediendo. Cobol, a pesar de su popularidad en
algn momento, no parece tener ningn descendiente intelectual. Es un callejn sin salida evolutivo un
lenguaje Neanderthal.
Predigo un destino similar para Java. A veces la gente me enva correo diciendo: "Cmo puedes decir que
Java no ser un lenguaje exitoso? Ya es un lenguaje exitoso." Y admito que lo es, si mides el xito por el
espacio que ocupa en las estanteras los libros que tratan sobre el mismo (sobre todo los libros individuales
que tratan sobre este), o por el nmero de estudiantes de licenciatura que creen que tienen que aprenderlo
para conseguir un trabajo. Cuando digo que Java no ser un lenguaje exitoso, me refiero a algo ms
especfico: que Java resultara ser un callejn sin salida evolutivo, como Cobol.
Esta es slo una conjetura. Puedo estar equivocado. Mi objetivo aqu no es ser irrespetuoso con Java, sino
plantear la cuestin de los rboles evolutivos y hacer que la gente se pregunte en qu parte del rbol esta
el lenguaje X? La razn de esta pregunta no es slo para que dentro de cien aos nuestros fantasmas
puedan decir: te lo dije. Es porque permanecer cerca de las ramas principales es una heurstica til para
encontrar lenguajes que sean buenos para programar hoy.
En un momento dado, eres ms feliz, probablemente, en las ramas principales de un rbol evolutivo. An
cuando todava haba muchos Neandertales, debe haber sido un fastidio ser uno. Los Cro-Magnons habran
venido constantemente a golpearte y robarte la comida.
La razn por la que quiero saber como sern los lenguajes dentro de cien aos es para saber a qu rama del
rbol apostar ahora.
La evolucin de los lenguajes se diferenca de la evolucin de las especies, porque las ramas pueden
converger. La rama de Fortran, por ejemplo, parece estar fusionndose con los descendientes de Algol. En
teora esto es posible para las especies tambin, pero no es probable que le haya ocurrido a algo ms
grande que una clula.
La convergencia es ms probable para los lenguajes, en parte debido a que el espacio de posibilidades es
menor, y en parte porque las mutaciones no son aleatorias. Los diseadores de un lenguaje incorporan
deliberadamente ideas de otros lenguajes.
Es especialmente til para los diseadores de lenguajes pensar hacia dnde llevara la evolucin de los
lenguajes de programacin, para que pueden orientar el curso en consecuencia. En ese caso, "permanecer
en una rama principal" se convierte en ms que una manera de elegir un buen lenguaje. Se convierte en una
heurstica para tomar las decisiones correctas sobre el diseo de lenguajes.
Cualquier lenguaje de programacin se puede dividir en dos partes: un conjunto de operadores
fundamentales que desempean el papel de los axiomas, y el resto del lenguaje, que en principio podra ser
escrito en trminos de estos operadores fundamentales.

Creo que los operadores fundamentales son el factor ms importante en la supervivencia a largo plazo de un
lenguaje. El resto se puede cambiar. Es como la regla de que en la compra de una casa debes tener en
cuenta la ubicacin en primer lugar. Todo lo dems se puede arreglar ms adelante, pero no puedes arreglar
la ubicacin.
Creo que es importante no slo que los axiomas sean bien elegidos, sino que haya pocos de ellos. Los
matemticos siempre se han sentido as respecto a los axiomas mientras menos, mejor y creo que estan
en lo cierto.
Por lo menos, tiene que ser un ejercicio til observar de cerca el ncleo de un lenguaje para ver si hay
axiomas que podran eliminarse. En mi larga carrera de haragn he descubierto que el polvo engendra
polvo, y he visto que esto sucede tanto en el software, como debajo de las camas y en las esquinas de las
habitaciones. [a]
Tengo la corazonada de que las principales ramas del rbol evolutivo pasan a travs de los lenguajes que
tienen los ncleos ms pequeos y limpios. Mientras ms puedas escribir de un lenguaje en el mismo, mejor.
Por supuesto, estoy haciendo una gran suposicin en preguntar incluso como sern los lenguajes de
programacin dentro de cien aos. Estaremos an escribiendo programas en cien aos? No le diremos
simplemente a las computadoras lo que queremos que hagan?
No ha habido mucho progreso en ese apartado hasta el momento. Mi conjetura es que en un centenar de
aos la gente todava le dir a las computadoras que hacer utilizando programas que se reconocern como
tales. Es posible que haya tareas que ahora resolvemos escribiendo programas y que en cien aos no
tendrs que escribir para resolverlas, pero creo que todava habr una buena cantidad de programacin del
tipo de la que hacemos hoy.
Puede parecer presuntuoso pensar que alguien pueda predecir como lucir cualquier tecnologa dentro de
cien aos. Pero recuerda que ya tenemos casi cincuenta aos de historia a nuestras espaldas. Ver un
centenar de aos hacia el futuro es una idea comprensible si tenemos en cuenta la lentitud con que los
lenguajes han evolucionado en los ltimos cincuenta aos.
Los lenguajes evolucionan lentamente porque no son realmente tecnologas. Los lenguajes son notacin. Un
programa es una descripcin formal del problema que quieres que te resuelva una computadora. Por lo que
la tasa de evolucin de los lenguajes de programacin se parece ms a la tasa de evolucin de la notacin
matemtica que, digamos, al transporte o las comunicaciones. La notacin matemtica evoluciona, pero no
a los gigantescos saltos que se ven en la tecnologa.
Sin importar de que estn hechas las computadoras dentro de cien aos, parece seguro predecir que sern
mucho ms rpidas de lo que son ahora. Si la Ley de Moore contina hacindose patente, sern 74 trillones
(73,786,976,294,838,206,464) de veces ms rpidas. Eso es un tanto difcil de imaginar. Y, en efecto, la
prediccin ms probable en el apartado de la velocidad puede ser que la Ley de Moore dejar de funcionar.
Cualquier cosa que se supone que se duplique cada dieciocho meses parece probable que se encuentre
contra algn tipo de lmite primordial eventualmente. Pero no tengo problemas para creer que las
computadoras sern mucho ms rpidas. Incluso si slo terminan siendo un msero milln de veces ms
rpidas, eso debe cambiar considerablemente las reglas para los lenguajes de programacin. Entre otras
cosas, habr ms espacio para lo que ahora se consideran lenguajes lentos, es decir, lenguajes que no
generan un cdigo muy eficiente.
Y sin embargo, algunas aplicaciones todava demandaran velocidad. Algunos de los problemas que
queremos resolver con las computadoras son creados por las mismas; por ejemplo, la velocidad a la que
tienes que procesar imgenes de vdeo depende de la velocidad a la que otra computadora las puede
generar. Y hay otra clase de problemas que tienen inherentemente una capacidad ilimitada para absorber
los ciclos: la representacin de imgenes, la criptografa, las simulaciones.
Si algunas aplicaciones pueden ser cada vez ms ineficientes, mientras que otras siguen exigiendo toda la
velocidad que el hardware pueda ofrecer, una computadora ms rpida significara que los lenguajes tienen
que cubrir una gama cada vez ms amplia de eficiencia. Hemos visto que esto ya est sucediendo. Las
implementaciones actuales de algunos nuevos lenguajes populares son terriblemente derrochadoras

comparadas con los estndares de dcadas anteriores.

Esto no es slo algo que ocurre con los lenguajes de programacin. Se trata de una tendencia histrica
general. Conforme las tecnologas mejoran, cada generacin puede hacer cosas que la generacin anterior
hubiera considerado un desperdicio. La gente de hace treinta aos se sorprendera de la forma tan casual
con que hacemos llamadas de larga distancia. La gente hace cien aos estara an ms sorprendida de que
un paquete viajara un da de Boston a Nueva York pasando por Memphis.
Ya puedo decirte lo que le pasara a todos esos ciclos extra que un hardware ms rpido nos dar en los
prximos cien aos. Casi todos se desperdiciaran.
Aprend a programar cuando la potencia de las computadoras era escasa. Recuerdo eliminar todos los
espacios de mis programas Basic para que encajaran en la memoria de un 4K TRS-80. La idea de todo este
software estupendamente ineficiente quemando ciclos haciendo la misma cosa una y otra vez me parece un
poco grosera. Pero creo que aqu mis intuiciones estn equivocadas. Soy como alguien que creci en la
pobreza, y no soporta gastar dinero aunque sea para algo importante, como ir al mdico.
Algunos tipos de desperdicios son realmente repugnantes. Las SUVs, por ejemplo, podra decirse que seran
groseras, aunque funcionaran con un combustible que nunca se agota y no generaran contaminacin. Las
SUVs son groseras porque son la solucin a un problema grosero. (Cmo hacer que las minivans tengan un
aspecto ms masculino.) Pero no todo el desperdicio es malo. Ahora que tenemos la infraestructura de
apoyo, contar los minutos de tus llamadas de larga distancia empieza a parecer insignificante. Si tienes los
recursos, es ms elegante pensar en todas las llamadas telefnicas como un tipo de cosa, sin importar
donde esta la otra persona.
Hay desperdicio bueno, y desperdicio malo. Estoy interesado en el desperdicio bueno del tipo que, al
gastar ms, podemos conseguir diseos ms simples. Cmo aprovecharemos las oportunidades para
desperdiciar ciclos que obtendremos del nuevo hardware ms rpido?
El deseo de velocidad esta tan profundamente arraigado en nosotros, con nuestras endebles computadoras,
que tomar un esfuerzo consciente superarlo. En el diseo de lenguajes, debemos estar conscientemente
buscando situaciones en las que se pueda cambiar la eficiencia por el ms mnimo aumento de la
comodidad.
La mayora de las estructuras de datos existen debido a la velocidad. Por ejemplo, muchos lenguajes hoy en
da tienen tanto cadenas como listas. Semnticamente, las cadenas son ms o menos un subconjunto de las
listas en las que los elementos son caracteres. Entonces, por qu necesitas un tipo de datos separado? En
realidad, no lo necesitas. Las cadenas slo existen por eficiencia. Pero es poco original llenar la semntica
del lenguaje con hacks para que los programas funcionen ms rpido. Tener cadenas en un lenguaje parece
ser un caso de optimizacin prematura.
Si pensamos en el ncleo de un lenguaje como un conjunto de axiomas, sin duda es grosero tener axiomas
adicionales que no aaden potencia expresiva, por el mero hecho de la eficiencia. La eficiencia es
importante, pero no creo que ese sea el camino correcto para conseguirla.
La forma correcta de resolver el problema, creo yo, es separar lo que significa un programa de los detalles
de su implementacin. En lugar de tener tanto listas como cadenas, ten slo listas, con alguna manera de
dar al compilador recomendaciones de optimizacin que le permitan tender cadenas de bytes contiguos, si
es necesario.
Puesto que la velocidad no importa en la mayor parte de un programa, normalmente no tendrs que
preocuparte por este tipo de microgestin. Esto ser cada vez ms cierto a medida que las computadoras se
vuelvan ms rpidas.
Ser breve al explicar la implementacin tambin debe hacer los programas ms flexibles. Las
especificaciones cambian mientras se escribe un programa y esto no es slo inevitable, sino deseable.
La palabra "ensayo" proviene del verbo francs "essayer", que significa "intentar". Un ensayo, en el sentido
original, es algo que escribes para intentar encontrar algo mejor. Esto sucede en el software tambin. Creo

que algunos de los mejores programas fueron ensayos, en el sentido de que los autores no saben cundo
comenz exactamente lo que estaban tratando de escribir.
Los hackers [b] de Lisp ya saben sobre el valor de ser flexible con las estructuras de datos. Tenemos la
tendencia a escribir la primera versin de un programa de manera que haga todo con las listas. Estas
versiones iniciales pueden ser tan terriblemente ineficientes que requiere un esfuerzo consciente no pensar
en lo que estn haciendo, as como, al menos para m, comer un bistec requiere un esfuerzo consciente en
no pensar de dnde viene.
Lo que los programadores dentro de cien aos estarn buscando, sobre todo, es un lenguaje donde puedas
crear una versin 1 increblemente ineficiente de un programa con el menor esfuerzo posible. Al menos, as
es como lo describimos en trminos actuales. Lo qu dirn es que quieren un lenguaje en el que sea fcil
programar.
El software ineficiente no es lo grave. Lo grave es un lenguaje que hace que los programadores hagan
trabajo innecesario. Desperdiciar el tiempo del programador es la verdadera ineficiencia, no desperdiciar el
tiempo de la mquina. Esto ser cada vez ms claro a medida que las computadoras se vuelvan ms
rpidas.
Creo que deshacerse de las cadenas es ya algo que podramos soportar pensar. Lo hicimos en Arc, y parece
ser una ganancia, algunas operaciones que serian difciles describir como expresiones regulares pueden ser
descritas fcilmente como funciones recursivas.
Hasta dnde llegar este aplanamiento de las estructuras de datos? Se me ocurren algunas posibilidades
que me escandalizan incluso a mi, con todo y ser de amplio criterio. Nos desharemos de las matrices, por
ejemplo? Despus de todo, son slo un subconjunto de tablas hash donde las claves son vectores de
nmeros enteros. Reemplazaremos las tablas hash con listas?
Hay perspectivas an ms chocantes que esas. El Lisp que McCarthy describi en 1960, por ejemplo, no
tenia nmeros. Lgicamente, no es necesario tener una nocin separada de nmeros, ya que pueden
representarse como listas: el entero n puede ser representado como una lista de n elementos. Puedes hacer
clculos de esta manera. Es slo que es insoportablemente ineficiente.
En realidad, en la prctica, nadie propuso implementar nmeros como listas. De hecho, el articulo de 1960
de McCarthy no tena, en ese momento, la intencin de ser aplicado en absoluto. Fue un ejercicio terico, un
intento de crear una alternativa ms elegante a la mquina de Turing. Cuando alguien, inesperadamente,
tom este articulo y lo tradujo a un intrprete de Lisp funcional, los nmeros ciertamente no estaban
representados como listas; estaban representados en el sistema binario, como en cualquier otro lenguaje.
Podra un lenguaje de programacin ir tan lejos como para librarse de los nmeros como un tipo de datos
fundamental? Pregunto esto, no tanto como una cuestin seria, sino como una manera de afrontar el futuro.
Es como el caso hipottico de una fuerza irresistible encontrndose con un objeto inamovible aqu, una
implementacin increblemente ineficiente encontrando recursos inimaginablemente grandes. No veo por
qu no. El futuro es bastante extenso. Si hay algo que podamos hacer para disminuir el nmero de axiomas
en el ncleo del lenguaje, parece ser el lado para apostar conforme t tiende a infinito. Si la idea an parece
insoportable dentro de cien aos, tal vez no lo parecer en un millar.
Para ser claros en esto, no estoy proponiendo que todos los clculos numricos en realidad se llevaran a
cabo utilizando listas. Estoy proponiendo que el ncleo del lenguaje, previo a cualquier notacin adicional
sobre la implementacin, sea definido de esta manera. En la prctica cualquier programa que quisiera hacer
alguna cantidad de matemticas probablemente representar los nmeros en binario, pero esto sera una
optimizacin, no parte de la semntica del ncleo del lenguaje.
Otra manera de quemar ciclos es tener muchas capas de software entre la aplicacin y el hardware. Esta
tambin es una tendencia que vemos que est sucediendo ya: muchos lenguajes recientes se compilan en
byte code. Bill Woods, una vez me dijo que, como regla general, cada capa de interpretacin cuesta un
factor de 10 en la velocidad. Este costo extra te da flexibilidad.
La primera versin de Arc fue un caso extremo de este tipo de lentitud multinivel, con los consiguientes
beneficios. Fue un clsico intrprete "metacircular" escrito sobre Common Lisp, con un definitivo aire de

familia a la funcin eval definida en el artculo original de McCarthy sobre Lisp. El todo era slo un par de
cientos de lneas de cdigo, as que era muy fcil de comprender y modificar. El Common Lisp que
utilizamos, Clisp, se ejecuta sobre un intrprete de byte code. As que aqu tenemos dos niveles de
interpretacin, uno de ellos (el superior) terriblemente ineficiente, pero el lenguaje es utilizable. Apenas
utilizable, lo admito, pero utilizable.
Escribir software en forma de capas mltiples es una tcnica potente incluso dentro de las aplicaciones. La
programacin de abajo-hacia arriba significa escribir un programa como una serie de capas, cada una de las
cuales sirve como un lenguaje para la que esta sobre ella. Este enfoque tiende a producir programas
flexibles ms pequeos. Es tambin la mejor ruta a ese santo grial, la reutilizacin. Un lenguaje es, por
definicin, reutilizable. Cuanto ms puedas forzar tu aplicacin hacia un lenguaje para escribir ese tipo de
aplicacin, mayor cantidad de tu software ser reutilizable.
De alguna manera, la idea de reutilizacin qued unida a la programacin orientada a objetos en la dcada
de 1980, y ninguna cantidad de evidencia contraria parece ser capaz de liberarla. Pero aunque algo del
software orientado a objetos es reutilizable, lo que lo hace reutilizable es su naturaleza orientada de abajohacia arriba, no su orientacin a objetos. Considera las bibliotecas: son reutilizables porque son lenguaje, ya
sea que estn escritas en un estilo orientado a objetos o no.
Por cierto, no predigo la desaparicin de la programacin orientada a objetos. Aunque no creo que tenga
mucho que ofrecer a los buenos programadores, excepto en determinados mbitos especializados, es
irresistible para las grandes organizaciones. La programacin orientada a objetos ofrece una manera
sustentable de escribir cdigo espagueti. Te permite acrecentar los programas como una serie de parches.
Las grandes organizaciones siempre tienden a desarrollar software de esta manera, y creo que esto ser tan
cierto dentro de cien aos como lo es hoy.
En tanto estemos hablando del futuro, sera mejor hablar de la computacin en paralelo, porque ah es donde
esta idea parece residir. Es decir, no importa de cuando ests hablando, la computacin en paralelo parece
ser algo que suceder en el futuro.
La alcanzar el futuro? La gente ha estado hablando de la computacin paralela como algo inminente por al
menos 20 aos, y hasta ahora no ha afectado mucho a la prctica de la programacin. O no es as? Ya los
diseadores de chips tienen que pensar en ello, e igual la gente que trata de escribir software de sistema en
computadoras con mltiples CPUs.
La verdadera pregunta es, que tan alto llegara el paralelismo en la escalera de la abstraccin? Afectar
dentro de cien aos incluso a los programadores de aplicaciones? O ser algo en lo que pensaran los
escritores de compiladores, pero que suele ser invisible en el cdigo fuente de las aplicaciones?
Una cosa que parece probable es que la mayora de las oportunidades para el paralelismo se habrn de
desperdiciar. Este es un caso especial de mi prediccin ms general de que la mayora de la potencia
adicional que nos darn las computadoras se desperdiciar. Espero que, al igual que con la estupenda
velocidad del hardware subyacente, el paralelismo ser algo que estar disponible si lo solicitas
expresamente, pero que normalmente no se utilizar. Esto implica que el tipo de paralelismo que tendremos
en cien aos no ser, salvo en ciertas aplicaciones, masivo. Espero que para los programadores ordinarios
ser ms como poder empalmar procesos que terminaran todos corriendo en paralelo.
Y esto har que, al igual que pedir implementaciones especficas de estructuras de datos, sea algo que
hagas hasta ms tarde en la vida de un programa, cuando tratas de optimizarlo. Las versiones 1
normalmente ignorarn cualquier ventaja que se pueda obtener de la computacin en paralelo, del mismo
modo que ignorarn las ventajas que se puedan obtener de representaciones de datos especficas.
Excepto en tipos especiales de aplicaciones, el paralelismo no impregnar los programas que sean escritos
en un centenar de aos. Sera optimizacin prematura si lo hicieran.
Cuntos lenguajes de programacin habr dentro de cien aos? Parece haber un gran nmero de lenguajes
de programacin nuevos ltimamente. Parte de la razn es que el hardware ms rpido le ha permitido a los
programadores hacer diferentes concesiones entre velocidad y conveniencia, dependiendo de la aplicacin.
Si esta es una tendencia real, el hardware que tendremos dentro de cien aos no hara ms que aumentarla.

Y sin embargo, puede que en cien aos slo haya unos pocos lenguajes ampliamente utilizados. Parte de la
razn por la que digo esto es optimismo: parece que, si hiciste un trabajo realmente bueno, podras hacer un
lenguaje que era ideal para escribir una versin lenta 1, y sin embargo, con la adecuada sugerencia de
optimizacin para el compilador, tambin arrojar cdigo muy rpido cuando sea necesario. Por lo tanto, ya
que soy optimista, voy a predecir que, a pesar de la enorme brecha que tendrn entre eficiencia mxima y
aceptable, los programadores dentro de cien aos tendrn lenguajes que pueden abarcar la mayor parte de
ella.
A medida que esta brecha se ampla, los perfiladores sern cada vez ms importantes. Se presta poca
atencin al perfilado ahora. Mucha gente todava parece creer que la manera de conseguir aplicaciones
rpidas es escribir compiladores que generen cdigo rpido. A medida que la brecha entre desempeo
aceptable y mximo se ample, ser cada vez ms claro que la forma de obtener aplicaciones rpidas es
tener una buena gua de una a la otra.
Cuando digo que puede que slo haya unos pocos lenguajes, no estoy incluyendo lenguajes pequeos de
dominio especfico. Creo que tales lenguajes integrados son una gran idea, y espero que proliferen. Pero
espero que sean escritos como pieles suficientemente delgadas para que los usuarios puedan ver el
lenguaje de propsito general por debajo.
Quin disear el lenguaje del futuro? Una de las tendencias ms interesantes en los ltimos diez aos ha
sido el aumento de lenguajes de cdigo abierto como Perl, Python y Ruby. El diseo de lenguajes esta siendo
asumido por los hackers. Los resultados hasta ahora son desordenados, pero alentadores. Hay algunas ideas
increblemente novedosas en Perl, por ejemplo. Muchas son increblemente malas, pero eso siempre es
cierto de los esfuerzos ambiciosos. A su actual tasa de mutacin, sabr Dios en lo que podra convertirse Perl
en cien aos.
No es verdad que aquellos que no pueden hacer, ensean (algunos de los mejores hackers que conozco son
profesores), pero es cierto que hay muchas cosas que los que ensean no pueden hacer. La investigacin
impone limitantes restricciones de casta. En cualquier mbito acadmico hay temas que son aceptables
para trabajar y otros que no lo son. Por desgracia, la distincin entre los temas aceptables y prohibidos se
basa generalmente en que tan intelectual suena el trabajo cuando se describe en los artculos de
investigacin, en lugar de que tan importante es para obtener buenos resultados. El caso extremo es,
probablemente, la literatura; la gente que estudia literatura raramente dice algo que pueda ser de la menor
utilidad para aquellos que la producen.
Aunque la situacin es mejor en las ciencias, la coincidencia entre el tipo de trabajo que se te permite hacer
y el tipo de trabajo que produce buenos lenguajes es preocupantemente pequeo. (Olin Shivers se quej con
elocuencia acerca de esto) Por ejemplo, los tipos parecen ser una fuente inagotable de trabajos de
investigacin, a pesar de que el tipado esttico parece excluir las verdaderas macros sin las cuales, en mi
opinin, no vale la pena usar ningn lenguaje.
La tendencia no es slo hacia lenguajes que estn siendo desarrollados como proyectos de cdigo abierto en
lugar de "investigacin", sino hacia lenguajes siendo diseados por los programadores de aplicaciones que
necesitan usarlos, en lugar de por los escritores de compiladores. Esta parece una tendencia positiva y
espero que contine.
A diferencia de la fsica dentro de cien aos, que es casi por necesidad imposible de predecir, creo que
puede ser posible, en principio, disear un lenguaje hoy que sea atractivo a los usuarios dentro de cien aos.
Una forma de disear un lenguaje es simplemente escribir el programa que te gustara poder escribir,
independientemente de si existe un compilador que pueda traducirlo o hardware que pueda ejecutarlo.
Cuando haces esto puedes suponer recursos ilimitados. Parece que debemos ser capaces de imaginar
recursos ilimitados, tanto hoy como dentro de cien aos.
Qu programa querra escribir uno? El que cueste menos trabajo. Excepto no exactamente: cualquiera que
fuera menos trabajo si tus ideas acerca de la programacin no se vieron afectadas ya por los lenguajes a los
que actualmente estas acostumbrado. Esta influencia puede ser tan penetrante que se necesita un gran
esfuerzo para superarla. Se podra pensar que sera obvio para criaturas tan flojas como nosotros la forma
de expresar un programa con el mnimo esfuerzo. De hecho, nuestras ideas acerca de lo que es posible
tiende a estar tan limitada por cualquier lenguaje en el que pensamos que formulaciones mas sencillas de

programas parecen muy sorprendentes. Son algo que tienes que descubrir, no algo en lo que te pones a
trabajar.
Un truco til en este caso es utilizar la longitud del programa como una aproximacin a cuanto trabajo es
escribir. No la longitud en caracteres, por supuesto, sino la longitud de distintos elementos sintcticos
bsicamente, el tamao del rbol de anlisis. Puede que no sea del todo cierto que el programa ms corto
es el que da menos trabajo escribir, pero esta tan cerca que te ira mejor apuntando al slido blanco de la
brevedad que al difuso y cercano, de menor trabajo. Entonces, el algoritmo para el diseo de lenguajes se
convierte en: Observa un programa y pregunta, hay alguna manera de escribir esto que sea ms corta?
En la prctica, escribir programas en un imaginario lenguaje de cien aos funciona a diferentes grados
dependiendo de que tan cerca ests al ncleo. Clasifica las rutinas que puedas escribir ahora. Pero sera
difcil predecir qu tipo de bibliotecas podran necesitarse en un centenar de aos. Es de suponer que
muchas bibliotecas sern para dominios que no existen todava. Si SETI@home funciona, por ejemplo,
vamos a necesitar bibliotecas para comunicarnos con los extraterrestres. A menos que, por supuesto, estn
lo suficientemente avanzados que ya se comunican en XML.
En el otro extremo, creo que podras ser capaz de disear el ncleo del lenguaje en la actualidad. De hecho,
algunos podran argumentar que ya estaba casi todo diseado en 1958.
Si el lenguaje de los cien aos estuviera disponible hoy en da, querramos programar en l? Una forma de
responder a esta pregunta es mirar hacia atrs. Si los lenguajes de programacin de hoy en da hubieran
estado disponibles en 1960, alguien habra querido utilizarlos?
En cierta forma, la respuesta es no. Los lenguajes de hoy en da asumen infraestructura que no exista en
1960. Por ejemplo, un lenguaje en el que las sangras son importantes como Python, no iba a funcionar muy
bien en las terminales de las impresoras. Pero dejando a un lado este tipo de problemas asumiendo, por
ejemplo, que los programas slo estuvieran escritos en papel Le hubiera gustado a los programadores de
la dcada de 1960 escribir programas en los lenguajes que usamos hoy da?
Creo que s. Algunos de los menos imaginativos, que tuvieran residuos de lenguajes tempranos incorporados
en sus ideas de lo que era un programa, podran haber tenido problemas. (Cmo se pueden manipular los
datos sin tener que hacer aritmtica de punteros? Cmo se pueden implementar diagramas de flujo, sin
gotos?) Pero creo que los programadores ms inteligentes no hubieran tenido problemas para sacar el
mximo partido de los lenguajes de hoy en da, si los hubieran tenido.
Si tuviramos el lenguaje de los cien aos ahora, por lo menos hara un gran pseudocdigo. Qu tal usarlo
para escribir software? Dado que el lenguaje de los cien aos tendr que generar cdigo rpido para algunas
aplicaciones, es de suponer que podra generar cdigo lo suficientemente eficiente para funcionar
aceptablemente bien en nuestro hardware. Puede que tengamos que dar ms recomendaciones de
optimizacin que usuarios dentro de cien aos, pero an podra ser una ganancia neta.
Ahora tenemos dos ideas que, si se combinan, sugieren interesantes posibilidades: (1) el lenguaje de los cien
aos podra, en principio, ser diseado hoy en da, y (2) tal lenguaje, si existiera, podra ser bueno para
programar en la actualidad. Cuando ves estas ideas expuestas as, es difcil no pensar, por qu no intentar
escribir el lenguaje de los cien aos ahora?
Cuando ests trabajando en el diseo de lenguajes, creo que es bueno tener ese objetivo y mantenerlo
conscientemente en la mente. Cuando se aprende a conducir, uno de los principios que te ensean es no
alinear el auto empatando el cofre contra las rayas pintadas en el camino, sino apuntando a algn sitio en la
distancia. Incluso si lo nico que importa es lo que sucede en los prximos tres metros, esta es la respuesta
correcta. Creo que podemos y debemos hacer lo mismo con los lenguajes de programacin.

Notas. Creo que Lisp Machine Lisp fue el primer lenguaje en encarnar el principio de que las declaraciones
(excepto las de las variables dinmicas) no eran ms que recomendaciones de optimizacin, y no cambiara
el significado de un programa correcto. Common Lisp parece haber sido el primero en declarar esto de
manera explcita.

Gracias a Trevor Blackwell, Robert Morris, y Dan Giffin por leer borradores de esto y a Guido van Rossum,
Jeremy Hylton, y el resto del equipo de Python por haberme invitado a hablar en PyCon.