Intro

Time is a gypsy caravan
Steals away in the night

En 1997 Rush era una banda exitosa, su baterista, Neil Peart era considerado el mejor del mundo, tanto por sus pares como por la crítica. Pero en ese año, su única hija, de 19 años, muere en un accidente automovilístico,  diez meses después su mujer, quien nunca superó la pérdida, fallece afectada de cáncer. Un dolido Neil comunica a sus compañeros que ha decidido tomarse una pausa, para reflexionar, no sabe por cuanto tiempo, toma su motocicleta y parte a recorrer la carretera. El futuro de la banda es incierto.

Estrofa

We will pay the price,
But we will not count the cost

Nicholas Taleb nos diría que lo sucedido a Neil Peart es uno de esos eventos desastrosos que impacta profundamente nuestro entorno, algo totalmente impredecible, para lo cual no estamos preparados. Un “Cisne Negro”, tanto para el músico como para la banda, que a partir de este evento sufre un hiato de casi ocho años.

La imagen del cisne negro, introducida en el libro The Black Swan, The Impact of the Highly Improbabble, de Nicholas Taleb,  viene del hecho que por muchos años para los naturalistas europeos todos los cisnes era blancos, hasta que uno fue encontrado en Australia. Este concepto ilustra  la fragilidad de nuestro conocimiento. Una simple observación invalida una afirmación general sostenida durante milenios tras la observación de millones de cisnes blancos.

En su libro, Taleb introduce el concepto del cisne negro como un evento que tiene tres atributos: primero es una cosa aislada de todas las expectativas regulares, porque nada en el pasado puede convincentemente dar indicios de su posibilidad. Segundo genera un impacto extremo, y en tercer lugar, a pesar de su carácter ajeno, nuestra naturaleza nos hace confeccionar explicaciones de su ocurrencia después del hecho, por lo que lo asimilamos como si fuera algo explicable y predecible.

Riff

Why are we here?
Because we’re here
Roll the bones

Taleb se auto define como un empirista escéptico, siguiendo la tradición de Montaigne, y sobretodo de David Hume, este autor nos recuerda la vieja máxima de que el pasado no sirve para explicar el futuro. Algo de lo que hemos hablado en “causas imaginadas”. El libro contiene muchos de los temas que hemos tratado acá, lo que no es de extrañar, pues se suma a una lista de textos que están hablando de los mismo: el manejo de la complejidad, la irracionalidad humana, y nuestras limitaciones cognitivas para lidiar con la realidad.

Lo que vamos a ver ahora es si esto aplica en la gestión de proyectos informáticos, porque al parecer tenemos cisnes negros. Lo que viene es una exploración de esta idea, también una respuesta a un post de mi estimado colega Alejandro Barros, con quien hemos sostenido más de alguna discusión sobre la realidad del concepto “crisis del software”, o la deuda en la eficiencia de la gestión de proyectos TI (ver [1] y [2]).

Estribillo

Why does it happen?
Because it happens
Roll the bones

Fuimos engañados, por gente que no entendía lo que leía, y montones de libros enseñaban a los ingenieros de software como hacer mal las cosas, “la maldición de la cascada”, recién ahora algunos cuestionan a la peor metodología para desarrollar un proyecto de software que haya existido, pero aún hay gente que espera milagros, chocando con la realidad. “Locura es hacer siempre lo mismo y esperar resultados diferentes”.

Soy un convencido que debemos abandonar “la imagen del software como algo que se construye”.  Me resisto a creer que este oficio deba ser asimilado a la construcción civil, o la ingeniería de obras, esa que construye puentes, porque esa visión es la fuente de tanta frustración y confusión.

Puente

Face up! There’s still time to turn the game around
Face up! – Turn it up
Or turn wild card down

Alejandro nos informa de un artículo llamado Why your IT Project may be riskier than you think. El tema del artículo es el de siempre, los proyectos TI están condenados, somos pésimos estimando, y nuestros proyectos siempre terminan mal, bueno, no siempre, pero el promedio de costo de los proyectos está por sobre el 27%. Pero las malas noticias son que el 17% de los proyectos TI se transforman en cisnes negros.  Lo que los autores del artículo definen como cisnes negros son proyectos que sorpresivamente suben sus costos por sobre el 200%.

Break

Shadows on the road behind
Shadows on the road ahead
Nothing can stop you now

Después de su pérdida Neil Peart recorrió 80.000 kilómetros en motocicleta por norteamérica, plasmó sus vivencias en un libro y una canción. El dolor se fue disolviendo en el tiempo, y de repente, mientras visitaba a un amigo en Los Ángeles, éste le presenta a la que terminaría siendo su segunda esposa. Después de esto hace una llamada a sus compañeros para anunciarles que está de vuelta, que quiere volver al estudio a grabar y componer, después de 14 meses Rush vuelve con “Vapor Trails”.

Sólo

Well, I was only a kid — didn’t know enough to be afraid
Played the game, but not the way the big boys played
Nothing to lose — maybe I had something to trade

No me considero una persona optimista, pero parece que lo soy. No me importan tanto los fracasos como la forma en que se superan. El éxito siempre es aburrido, la ingeniería es aburrida si no se presentan desafíos. Para mi la idea de que la metodología correcta llevará al éxito de los proyectos siempre es reconfortante, pero es pura fantasía, voluntarismo, que nace de no reconocer la naturaleza del desarrollo de software. Lo malo es que no puedes decirle eso a los que ponen el dinero, que esperan que el proyecto salga en el tiempo y el presupuesto. Y ahí está el problema.

Los autores del estudio mencionado arriba afirman haber recogido una muestra global de 1.471 proyectos TI, comparando sus presupuestos y beneficios esperados con los costos y resultados reales. El rango de los proyectos era de del tipo de implantación de sistemas de ERP, CRM y administración de información. El costo promedio de los proyectos fue de 167 millones de dólares, y el más grande de 33 mil millones de dólares. Eran proyectos grandes, varios planeados para ser ejecutados en periodos de varios años. El 92% de los proyecto fue en agencias públicas y el 83% estaba basado en USA. Pero como encontraron poca diferencia entre el 92% de los proyectos públicos con el 8% de los proyectos privados en su muestra, los autores estimaron que el comportamiento es el mismo en el sector privado. ¡Ah!, olvidé mencionar, los autores Bent Flyvbjerg es académico en Oxford, y Alexander Budzierno consultor en McKinsey & Co. y candidato a  PhD .

¿Qué puede alegar un (no tan) humilde desarrollador ante tamañas credenciales, y base muestral?

Pues yo creo que mucho. En primer lugar me parece que los autores cometen muchos de los errores que el autor de Black Swan se encarga de destacar en su libro. Sabemos que a fines del 2008, después de la crisis financiera, Taleb era referencia obligada, y muchos han citado su obra sin siquiera hojear la contratapa. Ha habido tantas malas interpretaciones de las ideas de Taleb que el autor decidió escribir un largo apéndice en la segunda edición de su libro:

“El hecho es que muchos investigadores no se dan cuenta inmediatamente de que un Cisne Negro corresponde principalmente a un mapa incompleto del mundo, o que algunos investigadores deben resaltar esta cualidad subjetiva […] lo que nos lleva al problema histórico sobre la definición misma de probabilidad.[…] La noción de que dos personas pueden tener diferentes visiones del mundo, y luego expresarlas como diferentes probabilidades permanece extraña a los investigadores. Así que le ha tomado un tiempo a los científicos aceptar la noción no-Asperguer que diferentes personas pueden, siendo racionales, asignar diferentes probabilidades a diferentes estados futuros del mundo. Esto se llama “probablidad subjetiva” – Nicholas Taleb, “Probability has to be subjective”, Ensayo postscriptum: Sobre la robustez y fragilidad… Segunda Edición de El Cisne Negro.

En ese párrafo está la clave para entender cuál es el problema con estos análisis, como veremos.

Estribillo

Do we have to be forgiving at last?
What else can we do?
Do we have to say goodbye to the past?
Yes I guess we do

No sólo hemos sido engañados, también nos hemos engañados nosotros mismos, hemos sufrido una amnesia imperdonable. Porque sabemos esto desde hace más de 30 años, las falacias de la estimación fueron enunciadas por Brooks en su clásico ensayo The Mythical Man Month. Cometemos errores porque olvidamos el pasado, vivimos como si el desarrollo de  software se hubiera inventado ayer, como si todos estos problemas fueran nuevos. Taleb sonríe desde su escepticismo empirista…

Estrofa

I don’t believe in destiny
Or the guiding hand of fate
But I believe there’s a ghost of a chance

A pesar de las objeciones que yo pudiera tener sobre la elección de la muestra, o la metodología del estudio de Flyvbjerg y Budzier, los números están ahí, cuando un proyecto TI se sale de la escala, el costo es muy alto. ¿Por qué pasa eso?

Al principio de su ensayo Brooks cita el menú del Restaurant Antoine de New Orleans:

“La buena cocina toma tiempo. Si le hacemos esperar, es para servirle mejor, y complacerle”

¡Cómo nos hace falta tener la actitud del Chef Antoine! Si negociaramos plazos y costos con la educada inflexibilidad del Chef, Alejandro Barros perdería tanto material para escribir…

Hace más de 30 años Brooks identificó los problemas con las estimaciones:

• Optimismo injustificado: los programadores son optimistas. Muchas de las estimaciones parten de la premisa de que todo irá bien. El código es un medio tan maleable que crea un sentido de control absoluto por parte del programador que es engañoso, porque confía que todo depende de su propia capacidad intelectual, de sus propias ideas. Pero nuestras ideas evolucionan, en la medida que entendemos mejor el problema, así que nuestro optimismo es inherentemente injustificado. Y este sentido además cae en la actitud aspelgueriana, de que no depende de nadie más, soy yo y el código ante mi. Todas las demás componentes respetarán la interfaz y no habrán problemas de compatibilidad, o en la infraestructura.
• La falacia del hombre-mes: se usa la misma unidad en la estimación y en la programación o calendarización del trabajo: el hombre-mes. El costo es el producto de la cantidad hombres por el número de meses, pero el progreso no debe medirse así. “Usar el concepto de hombre-mes como unidad para medir el tamaño de un trabajo es un mito peligroso y engañoso”.

Dice Brooks: “hombres y meses son productos intercambiables solo cuando el trabajo puede ser particionado entre muchos hombres sin comunicación entre ellos. Esto es verdad cuando cosechamos trigo, o recogemos algodón; no es siquiera aproximadamente verdad cuando hablamos de programación de sistemas.”

En el ensayo Brooks introduce varios gráficos que aclaran este problema. El primero nos muestra el tiempo versus el número de trabajadores en tareas que pueden particionarse en forma perfecta (como la cosecha de trigo):

Si la tarea no se puede dividir (por ejemplo, al depurar) este es el gráfico del tiempo versus trabajadores:

Cuando tenemos interrelaciones complejas (como cuando desarrollamos un sistema) el trabajo y la división de la labor seguirá este comportamiento:

Sabemos esto, Brooks publicó estos ensayos en 1975. No es de extrañar que las estimaciones iniciales estuvieran subvaloradas. El último gráfico sirve para explicar muchas de las observaciones encontradas por Flyvbjerg y Budzier.

Otros  de los problemas que también identificó Brooks es el famoso “efecto del segundo sistema”. Sospecho que muchos de los proyectos que Flyvbjerg y Budzier encontraron sufren de este problema. El “efecto del segundo sistema” es una trampa peligrosa en la cual caen los arquitectos al diseñar la segunda versión o la reimplementación de un proceso o sistema, tenderán a agregar todo aquello que no incorporaron en la primera etapa, debido a las restricciones de tiempo, y esto llevará a una sobrecarga, la curva de complejidad se desplazará de modo de el costo del proyecto aumente (adivinen en que porcentaje, 200% o más, exacto!)[3]

Puente

You just don’t get it
What it is … well, you’re not really sure
You move like you’re walking on thin ice
Talking like you’re still insecure

Los proyectos presentados en el paper de Flybjer no son cisnes negros. No satisfacen la definición de Taleb, pues representan problemas conocidos, el factor sorpresa no está, salvo como excusa. Puede que las empresas que se embarcaron en estos proyectos desconocieran las ideas de Brooks, no me extraña, muchos ingenieros de software aún las desconocen.

<rant>Brooks no se enseña en las universidades, es un viejito, “¡estamos hablando de un libro de 1975, ¿qué podría enseñarnos, que no sepamos?!”. Las universidades han decidido que sólo pueden enseñar en su aulas PhD y académicos de jornada completa, no gente con experiencia real en el desarrollo de software (el catedrático del que hablaba Andrés Bello). Entonces,  ¿que podemos esperar como resultado de los arrogantes nuevos ingenieros que salen a repetir errores de 1960 en el desarrollo de sistemas para el sector público o corporativo?</rant>

History teach us nothing, cantaba Sting…

Colisión

The odds get even
You name the game
The odds get even

Neil Peart reconstruyó su vida, Rush volvió, costó, pero  volvió. Pero no sólo eso, sino que llegó  a ser una banda más grande que antes.

El baterista de Rush dice que un concierto de ellos es como correr una maratón de tres horas mientras resuelves ecuaciones[4]. Bueno, programar es más o menos así . A pesar de la imagen que mucha gente pueda tener, el rock requiere mucha disciplina.  (Hay una relación entre desarrollar software y el rock, tiene que haberla, ¡prometo que he de encontrarla!)

Lo más notable de la historia de Rush es su evolución. Es una banda que experimentó con sintetizadores, que volvió a lo básico, que adoptó elementos modernos del grunge, y el rock alternativo, incluso del hip hop y el jazz, sin perder su base progresiva. Los tres son virtuosos, inteligentes, cultos. Tuvieron fracasos económicos, y excedieron a veces el presupuesto asignado. Hombres brillantes orgullosos de su trabajo, los mejores en lo que hacen, personas sin miedo.

Los ingenieros de software, los desarrolladores de software deben tener esa actitud del músico de rock progresivo, no tener miedo. Yo creo que el desarrollo de software es mejor hoy que en 1975, o que en 1984, cuando Brooks escribió “No Silver Bullets” (otro texto olvidado). Brooks nos cuenta los errores que se cometen, no para darnos miedo, al contrario, para animarnos a enfrentarlos y superarlos.

Las metodologías pesadas, las asesorías, la literatura hasta la estimación de tiempos y esfuerzos está llena de miedo. La idea de que los proyectos de software van a fracasar siempre, o que tendrán un sobre costo.

Los cisnes negros son los nuevos hombres lobos[5].

Coda

The stakes are the same
You bet your life…

El software es desarrollado por gente para la gente. La gente se equivoca, estima mal, es optimista, es ignorante, es inteligente, es brillante, es deficiente. La gente es el factor clave.

La visión aspergueriana (para usar una expresión de Taleb), no considerará el factor humano, y terminará condenada a subestimar el trabajo, a entregar fuera de los plazos, y del presupuesto.

La clave del éxito de cualquier proyecto, y sobretodo de los proyectos TI es la administración de la gente. Olvidamos eso. La gestión del riesgo parte por la gestión del equipo humano.

No hay cisnes negros, hay mala gestión, sobretodo mala gestión de la gente: expectativas, comunicación, coordinación, confianza (desconfianza), actitud, etc.

El software se desarrolla, no se construye. Se desarrolla en un ambiente social, con gente inter conectada. Con eso en mente, hemos de mirar nuestros procesos, y cuestionarlos. Toda metodología es vana, si no va a la esencia de las cosas, pagamos el precio, pero no contamos el costo, así es como administramos nuestros proyectos.

Los cisnes negros son excusas.

Reverencia

Alejandro Barros tiene un blog notable, y que es una referencia obligada todos los que estamos preocupados de las TI, y que leo siempre que puedo, ustedes deberían seguirlo.

Esta pequeña polémica, que no creo que sea tal, sólo es un juego, y un tema de visiones más o menos optimistas sobre nuestra profesión, es estimulante. Le agradezco las horas de diversión que me dio el preparar esta respuesta a su post.

Todos los epígrafes son letras de las canciones del álbum Roll The Bones de Rush, excepto el epígrafe bajo Break, que es del tema Ghost Rider del álbum Vapor Trails. Roll The Bones fue la banda sonora mientras escribía e investigaba para este post. Los títulos son, obviamente, los elementos de un tema rock.

—-

Notas

[1] Comportamiento de proyectos TI: Están en deuda!, en el blog de Alejandro Barros, publicado en enero de 2010, visitado el 14 de enero de 2012.

[2] ¿De qué deuda me hablan?, mi respuesta al artículo en de Alejandro, publicado en este blog el 7 de enero de 2010.

[3] Tengo un ejemplo en mi trabajo, que sufrió del síndrome del segundo sistema, el esfuerzo final es el doble de estimación inicial, precisamente porque se trataron de introducir todas aquellas cosas que no estaban en la primera versión.

[4] Admiro a Peart, uno de los más grandes bateristas del rock. En una entrevista comenta que tocar batería es una manera de estimular a los chicos que odian los deportes, pero aman la música, para que hagan ejercicio. Yo hacía precisamente eso, sorprendiendo a mi profesor de educación física, que nunca entendió como yo, el peor en su ramo, podía tocar batería tan coordinadamente (true story .

[5] La referencia es a los werewolves de los que habla Brooks en No Silver Bullets.

Artículos relacionados

• No se encontraron artículos relacionados

No es un problema tener este sentimiento, el problema no surge del dolor ni de la frustración que vivimos, el problema es nuestra actitud frente a estos sentimientos.

Baja tolerancia a la frustración, el gran problema de nuestro tiempo de búsqueda del “éxito” permanente.

Tolerar la frustración significa enfrentar nuestros problemas y limitaciones, a pesar de las molestias, e incomodidades que nos provocan.

La baja tolerancia a la frustración proviene de que tenemos una percepción equivocada, o exagerada de la situación que estamos viviendo, y de la creencia de que lo que experimentamos es horrible, y no lo queremos vivir ni aguantar.

La frustración es parte de la vida, es imposible evitarla, pero debemos aprender a manejarla y superarla. Hay gente que tolera poco la frustración, y terminan desmotivados, abandonando metas y proyectos.

Lo que corresponde es aprender, entender, y enmendar. Son aquellos que toman su frustración, la manejan, aprenden de sus errores, y realizan las mejoras los que superan esta locura, y logran el éxito. El éxito no es que todo salga bien y a la primera, o en forma perfecta, el éxito es superar los escollos y lograr vivir una vida plena.

Artículos relacionados

• Desde siempre…
• Encuadres
• Un mundo controlado por algoritmos

Vivimos una época en que la gente no medita mucho, y es importante hacer la aclaración. La era digital tiene el problema que ha llevado a la gente a pensar en binario, 0 ó 1. El año es bueno o malo. En parte los informáticos somos culpables de eso, en facebook, las personas son amigas o no, me gusta o no, +1 o nada. Los invito a ver la vida como es en realidad, una realidad continua, no discreta, no digital. Con altos y bajos, con estados, con variables, con contradicciones y pocas certezas.

Es hora de finalizar el año, de iniciar el nuevo, del que ya hablaremos. Es tiempo de re iniciar. Pero este post es de cierre, de recuento. Les dejo con mi selección personal de los artículos que me parecen los mejor logrados este año, y nos seguimos viendo el próximo.

1. El Rey del Azúcar:  dedicado a mis amigos que estudiaron en la Universidad Federico Santa María (por cierto, no me gusta la inicial USM: Universidad Santa María, lleva una connotación que sospecho no sería del agrado de Don Federico, de hecho, si leen esta historia se darán cuenta que las cosas no salieron de acuerdo a su voluntad).
2. Sobre las propiedades del cuerno de unicornio, una reflexión sobre colaboración entre universidad e industria (me gusta mucho ese título).
3. La hora como un parámetro, no sé por qué me di el tiempo de contestar las estupideces dichas por el ministro.
4. Tambores Parlantes: descubrir el secreto de los tambores parlantes fue una epifanía, “Hombre blanco, espíritu en el bosque, ven, ven a la casa de los altos matorrales sobre el espiritu del hombre blanco en el bosque. La mujer con las batatas espera. Ven, ven.”
5. Dos hombres y una máquina universal. No está en este texto, pero descubrí hace poco que Von Neumann fue maestro de Turing y Shannon, y que durante la guerra volvieron a encontrarse, un episodio que deberé contar alguna vez.
6. La paradoja del sentido común: este post es el primero de una serie que fue un agrado de escribir.
7. Causas Imaginadas: la falacia post hoc explicada, me he dado cuenta que esta falacia es bastante usada en nuestro debate nacional, el otro día la detecté en un amigo y se lo dije. Escribir sobre estos sesgos cognitivos fue lo mejor que hice en el blog este año.
8. Razonamiento Circular: otro tipo de error de razonamiento bastante común.
9. Escuchar: recuperemos esta capacidad.
10. El problema con la razón, los progresistas deben aprender ciencias cognitivas.
11. Poesía, Caligramas y la Belleza del Código, programar es un arte…
12. Sobre cómo rascarse una oreja, los informáticos se complican la vida más de lo necesario.
13. Ensaladas y Algoritmos, una rica receta de ensalada fresquita para el verano.
14. Java debe morir, para que viva Java.

Feliz 2012!!

Artículos relacionados

• No se encontraron artículos relacionados

El principal problema reside en la ambigüedad de las declaraciones, la gramática hasta ahora permitía el uso opcional de las palabras reservadas ‘def’, ‘var’ y ‘val’.

De este modo la siguiente declaración

x := 1

era equivalente a esta otra:

val x := 1

y obligaba al uso de var para las variables mutables:

var x:= 1

Por otra parte la declaración de funciones era de la siguiente manera

factorial : Int -> Int

factorial 0 = 1

factorial n = n * factorial (n-1)

El problema es que una de las características de Ogu es que las funciones son first class, de este modo la siguiente declaración

f : Int -> Int

es ambigua, puede ser la variable inmutable f de tipo función Int->Int, o la función f. La gramática actual exige que inmediatamente después de esta declaración debe venir una expresión que corresponde a la definición del cuerpo de la función, esto obliga al uso de var o val si queremos que f sea una variable que almacenará una función.

Ante esto he decidido hacer los siguientes cambios:

• var, val y def son obligatorios al declarar variables o funciones.
• al inferir tipos los dos puntos son opcionales.
• También las palabras class y trait que eran opcionales ahora son obligatorias, y la definición de una clase debe ir precedida con la palabra reservada def
• La consecuencia de esto es que ahora las clases pueden empezar con minúsculas (lo que me simplifica un problema con el runtime de java y los packages)

Con estas consideraciones los ejemplos del primer artículo de esta serie quedan así:

val blog = “La naturaleza del software” // blog es de tipo String

val ogú = Cavernícola(nombre: “ogú”) // ogú es de tipo Cavernícola

val x, y := 1, 2 // x e y son de tipo Int, notar que el ‘:’ es opcional

Las funciones se definen de esta forma:

def factorial : Int –> Int

def factorial 0 = 1

def factorial n = n * factorial (n-1)

La forma abreviada es:

def factorial : (n:Int)–> Int  =if  (n == 0) 1 else  n * factorial(n-1)

Lo interesante es que con este cambio también  se puede escribir de la siguiente manera:

def factorial 0 = 1

def factorial n = n * factorial (n-1)

Potenciando más la inferencia de tipos.

Este cambio permite desambiguar la siguiente declaración

val f : Int -> Int

Permitiendo lo siguiente:

f = factorial

Las clases se declaran de este modo ahora:

def Persona : class (nombre: String, edadInicial: Int) ={

       var _edad = edadInicial

      def saludar : () = println “hola “ + nombre

       def celebrarCumpleaños : () = {
_edad = _edad + 1
println “¡¡ feliz cumpleaños “ + nombre + “!!”
}
}

Los ejemplos del artículo anterior también deben ser re escritos:

def Stack{T}  : class () = {

      var _data : [T] = []

     def push : (x:T) = _data = x :: _data

     def pop : ()->(r:T) = {
r = head _data
_data = tail _data
}
}

Las interfaces en Ogu se llaman traits (rasgos), siguiendo la tradición de Scala:

def Figura : trait = {

      def area : ()->Int
       def perimetro : () –> Int
}

def Circulo : class (radio:Int) ~ Figura = {

         def area = pi * radio ^ 2

         def perimetro = 2 * pi * radio

}

def Cuadrado : class (lado:Int) ~ Figura ={

         def area = lado*lado

         def perimetro = lado*4

}

Además con esto queda más claro que area y perimetro son funciones y no variables.

Este ejercicio me hizo darme cuenta de que estaba cayendo en el vicio que pretendía evitar, el vicio de la simplejización.  En el afán de ahorrarme algunas palabras reservadas estaba haciendo de Ogu un lenguaje con una sintáxis que terminaría siendo oscura e intimidante, que obligaría a pensar mucho para analizar una expresión. Estos cambios van en la linea de la simplicidad, sin perder el minimalismo sintáctico que espero que tenga Ogu.

Artículos relacionados

• El sistema de tipos de Ogu (1)
• Compiladores
• Java debe morir

Ogu es un lenguaje con declaración de tipos estáticos, aunque implementa inferencia de tipos. Veamos algunos ejemplos:

i : Int = 0

j := i // j es de tipo Int

s : String = “un string”

t := s

 

Ogu tiene “sacarina sintáctica” para soportar tuplas

naipe : (Int,String) = (10, “espadas”)  // naipe es una tupla

as := (1,”espadas”)

Naipe = (Int,String) // Introduce el tipo Naipe como alias de la tupla (Int,String)

Tambien hay sacarina para listas y hashes:

vocales : [String] = [“a”, “e”, “i”, “o”, “u”]

ListaDeStrings = [String]

mapa : [String : Int] = [“Chile”:56, “Usa”:1]

Las clases pueden ser genéricas:

Stack{T}  : () = {

var _data : [T] = []

push : (x:T) = _data = x :: _data

pop : ()->(r:T) = {

r = head _data
_data = tail _data
}

}

Las tuplas, listas y mapas se implementan en basa tipos genéricos. En realidad al declarar una variable de tipo [T] es lo mismo que declararla como Sequence{T}, y al declararla como [K:V] es lo mismo que Map{K,V}.  Tanto Sequence y Map son clases definidas en el runtime básico de Ogu.

Para crear un stack de enteros hacemos lo siguiente

stackOfInt := Stack{Int}()

// otra manera

StackOfInt = Stack{Int} // type alias

stackOfInt := StackOfInt()

Ogu soporta herencia de clases

// un troglodita es un cavernicola que vive en una cueva

Troglodita : (nombre,grito,cueva : String) > Cavernicola(nombre,grito)  = {
_cueva := cueva

}

 

Interfaces

Consideremos un paquete que trabaja con figuras geométricas

Circulo : (radio:Int) = {

area : ()->Int  = pi * radio ^ 2

perimetro: ()->Int = 2 * pi * radio

}

Cuadrado : (lado:Int) = {

area : () –> Int = lado * lado

}

 

Supongamos que queremos crear una funcion que imprima el area de una figura geometrica:

imprimeArea : (c:Cuadrado) = println(“el area es “+c.area())

imprimeArea : (c:Circulo) = println(“el area es “+c.area())

el problema es que Ogu no nos permite sobrecargar funciones . Hay tres maneras de solucionar esto, la primera es usando selectores de tipo:

imprimeArea : (c:Cuadrado|Circulo) = println(“el area es “+c.area())

lo que hemos hecho es que el tipo de la función imprimeArea puede ser un Cuadrado o un Circulo (Cuadrado | Circulo ).

Ahora si definimos esta función:

imprimePerimetro : (c : Cuadrado|Circulo) =
println(“el perimetro es “+c.perimetro())

tendremos un error de compilación,  Cuadrado no define la función perímetro.

La otra forma de solucionar este problema es declarando una interfaz:

Figura := {

area : ()->Int

perimetro : () –> Int

}

Una interfaz es como una clase, pero no tiene constructor y el cuerpo de las funciones es opcional.

De este modo puedo redefinir las clases Circulo y Cuadrado de esta manera:

Circulo : (radio:Int) ~ Figura = {

area = pi * radio ^ 2

perimetro = 2 * pi * radio

}

Cuadrado : (lado:Int) ~ Figura ={

area = lado*lado

perimetro = lado*4

}

e implementar nuestras funciones así

imprimeArea : (f:Figura) = println(“el area es “+f.area())

imprimePerimetro : (f:Figura) = println(“el perimetro es”+f.perimetro())

La tercera forma de implementar polimorfismo es mediante herencia y esa queda propuesta al lector.

Consideremos la interfaz Dibujo

Dibujo :=  {

dibujar : () = println (“dibuja un ”+nombre)

nombre : String

}

Podemos ahora extender Circulo y Cuadrado para que sean también dibujos:

Circulo : (radio:Int) ~ Figura & Dibujo = {

area = pi * radio ^ 2

perimetro = 2 * pi * radio

nombre = “circulo”

}

Cuadrado : (lado:Int) ~ Figura & Dibujo ={

area = lado*lado

perimetro = lado*4

nombre = “circulo”

}

Este artículo es solo una introducción, y es un complemento a la primera parte de la presentación de Ogu. Espero sus comentarios.

Artículos relacionados

• Simplejizando…
• Compiladores
• Java debe morir

Ignoro por que la Universidad de Chile decidió hacer este ramo optativo, ignoro también cuanta gente toma esta materia cada semestre,también he escuchado que la matrícula en computación ha bajado, espero que algún académico me confirme esa información.

Como sea, creo que la la no obligatoriedad del curso de compiladores es un error, porque es uno de los ramos que mejor sintetiza todo lo aprendido en la carrera.

Cuando haces un compilador aplicas:

• Estructuras de Datos (AST, Grafos de Colores)
• Algoritmos, Teorías de Autómatas, Teorías de Lenguajes Formales
• Fundamentos de Lenguajes de Programación (en el diseño del lenguaje)
• Optimización
• Programación en código de máquina (real o virtual)
• Modularidad, Integración, bajo acoplamiento (la estructura del analizador léxico, sintáctico, semántico y generación de código ayuda a entender y aplicar por primera vez los conceptos de arquitectura del software
• Ingeniería de software, diseño, análisis

Construir un compilador es el desafío que te forma como verdadero desarrollador de software, todo aquel que se quiera desempeñar como ingeniero de software debería intentar hacer un compilador alguna vez en su vida.

En mi vida profesional he construido 2 compiladores y diseñado 3 lenguajes (uno de los lenguajes usaba el pre procesador de C, así que era en realidad un conjunto de macros).

Estos lenguajes son lo que hoy llamamos DSL, lenguajes de dominio específico, diseñados para resolver un problema específico. El primero fue desarrollado en conjunto con Marco Zúñiga. Tenía un compilador, una máquina virtual propia, y hacíamos capacitaciones y lo licenciábamos, ganamos algunos buenos dólares con SanScript, como lo llamamos. Un DSL para automatizar tareas de comunicación de datos.

El segundo compilador era en realidad un traductor, que traducía de una suerte de markup tipo Haml y generaba páginas JSP. Lo divertido era que además eran resueltas con un filtro implementado con un servlet, que interpretaba los archivos con extensión .edc (mis iniciales) y generaba  las páginas jsp en un caché. Las contrapartes técnicas con que interactué en ese tiempo siempre me preguntaba que eran estas páginas con extensión ‘.edc’

Pero nunca he hecho un compilador de un lenguaje de propósito general, a pesar de que tengo la idea de hacerlo desde hace muchos años. Ahora que todo el mundo tiene ganas de matar Java, se me ocurrió que es momento de mostrar mi propuesta, de modo de que la primera versión de mi lenguaje corra sobra la Java Virtual Machine.

Ogu

El lenguaje se llama Ogu, su nombre es un homenaje al personaje creado por el caricaturista chileno Themo Lobos, es un cavernícola muy simpático amigo de aventuras de Mampato[2].

Este es un sencillo programa en Ogu:

println “Akarrú!!!”

Ninguna novedad dirán ustedes, hasta python hace eso, aunque traten de escribir este programa en Java

En este artículo voy a hacer una breve introducción, espero escribir más en los próximos días, donde iré describiendo las características de este nuevo lenguaje. Estoy aún en proceso de diseño, aunque hay ideas que tengo de hace años. Por cierto hay  influencias de otros lenguajes, como irán notando. Lo importante es que consideren de que es muy probable que las cosas cambien.

Lo primero que hay que notar es que es un lenguaje con tipos estáticos, como Java, como Scala o como Haskell, es decir, toda variable debe tener un tipo, así que toda declaración de un símbolo en Ogu debe tener su tipo.

Acá hay un ejemplo de declaraciones en Ogu:

blog : String

ogú : Cavernícola

x, y : Int

Los dos puntos ‘:’ separan a la variable de su tipo.

La asignación en Ogu es con el signo ‘=’, y sirve para inicializar una variable que ha sido declarada previamente, por ejemplo:

blog = “La naturaleza del software”

ogú = Cavernícola(nombre:”Ogú”, grito: “akarrú!!!)

x = 1

y = 2

Por supuesto las variables pueden tener un valor inicial al declararse:

blog : String = “La naturaleza del software”

ogú : Cavernícola = Cavernícola(nombre : “ogú” )

x, y : Int = 1, 2

Pero Ogu tiene cierta flexibilidad, que permite tranquilizar a los amantes de los lenguajes dinámicas, al inferir tipos:

blog := “La naturaleza del software” // blog es de tipo String

ogú := Cavernícola(nombre: “ogú”) // ogú es de tipo Cavernícola

x, y := 1, 2 // x e y son de tipo Int

Habrán notado que el nombre de las variables lleva acentos, esto porque Ogu acepta(rá) código escrito en Unicode.

Otra cosa importante, en Ogu si algo empieza con mayúsculas es la declaración de una clase, si empieza con minúsculas es una variable.

Pero todas las variables son inmutables, es decir, no puedes cambiarles el valor una vez asignada:

x := 1

x = 2 // error!!!

Si necesitas que las variables sean mutables debes declararlas anteponiendo la palabra reservada ‘var’:

var x := 1

x = 2 // ok, porque x es mutable

Esto es importante porque Ogu privilegia la programación funcional, como veremos más adelante.

Ogu es como el lenguaje Scala, soporta 2 paradigmas de programación: funcional y orientado al objeto. En Ogu la diferencia entre funciones y clases es algo difusa (el uso de mayúsculas para clases ayuda a desambiguarla).

Funciones:

Veamos como declarar una función:

factorial : Int –> Int

factorial 0 = 1

factorial n = n * factorial (n-1)

Este ejemplo muestra que Ogu privilegia el paradigma funcional, y sigue una sintáxis muy parecida a la de Haskell.

El valor de una función está determinado por la expresión a la izquierda del signo ‘=’.

Lo que tenemos son patrones, o casos, que definen a la función. Podemos escribir factorial de esta forma abreviada:

factorial : (n:Int)–> Int  =  (n == 0) 1 else  n * factorial(n-1)

Si hay más de una expresión en una función estas deben ir rodeadas de llaves {}.

En la forma abreviada deben ir los argumentos nombrados entre paréntesis, y es opcional nombrar el resultado.

El valor de la función será el valor de la última expresión, a menos que el resultado haya sido nombrado:

suma : (a,b : Int) –> Int = {
a+b // el valor es a+b
}

suma2 : (a, b : Int) –> (resultado: Int) =  {
resultado = a+b
println “el resultado es “ + resultado // el valor de suma2 es resultado
}

Si la función no recibe argumentos se debe usar la expresión () –> Tipo, esto con el fin de resolver ambiguedades:

uno : () –> Int = 1 // siempre retorna 1, pero es una función

uno := 1 //  es la variable uno

Si la función no retorna valores se debe usar –> Void, o solo colocar los parentesis:

saludar : () –> Void = println(“hola” )

saludar : () = println(“hola” )

Veamos como declarar una clase

Persona : (nombre: String, edadInicial: Int) ={

var _edad = edadInicial

saludar : () = println “hola “ + nombre

celebrarCumpleaños : () = {
_edad = _edad + 1
println “¡¡ feliz cumpleaños “ + nombre + “!!”
}
}

Como verán Ogu es un lenguaje que privilegia la economía sintáctica. Los argumentos nombre y edadInicial son atributos de la clase, y no es necesario declararlos en el cuerpo, _edad también es un atributo, pero privado. Los identificadores que empiezan con _ son privados, como en Python.

Los nombres que empiezan con mayúsculas son tipos o clases, y los nombres que  empiezan con minúsculas son nombres de funciones o variables. Si un nombre empieza con _ y luego viene mayúscula es un tipo privado.

Noten que junto con declarar la clase Persona, hemos definido el constructor de la clase.

Ahora podemos presentar la declaración de Cavernícola:

Cavernícola : (nombre, grito : String)

Cavernícola  : (nombre : String)  = Cavernícola(nombre, “akarrú!!”)

Cavernícola = {

pelear : () = {
println “yiko pelea!”
println grito
}
}

 

Fíjense como hemos declarado Cavernícola con dos constructores.

Hay más cosas que contar, pero esto es un anticipo de Ogu, que espero les guste. El proyecto será opensource y se publicará en github. Por ahora sólo existe un parser, el que aún tiene algunos problemas con ciertas ambigüedades. Espero tener pronto una primera versión para que empiecen a probarlo.

Este es el primer artículo sobre Ogu, en la medida que vaya resolviendo problemas de diseño iré publicando más.Espero sus opiniones, preguntas y sugerencias.

Notas

[1] Malla de Ingeniería Civil en Computación impartido por el DCC (para los que ingresaron antes de 2007, y los que ingresaron después de 2007).

[2] En realidad el personaje se llama Ogú (con acento en la u), y su grito de guerra es Akarrú, sí, Akarrú.

Artículos relacionados

• Simplejizando…
• El sistema de tipos de Ogu (1)
• Java debe morir

“De todas las formas de adquirir libros se considera la más gloriosa el escribirlos uno mismo” – Walter Benjamin

“’Ta muy malo el corralero, y allá en el potrero como viejo está. Hay que ayudarlo a que muera para que no sufra más.” – Sergio Sauvalle

Esa pareces ser la consigna desde hace unos dos o tres años, java, como lenguaje de programación, debe dar el paso a lenguajes más modernos.

Cuando uno ocupa durante mucho tiempo una herramienta empieza a descubrir sus limitaciones, y trata de hacer cambios para mejorarla, adaptaciones, o derechamente vas a adquirir otra.

Es natural, somos seres tecnológicos, y uno de los elementos que nos diferencia es nuestro uso de las herramientas. Somos expertos en la mejora continua de nuestras herramientas, nuestra historia es, en cierto sentido, la historia de nuestras herramientas.

De todas las herramientas disponibles para un programador el lenguaje es la más importante. Y vaya que ha evolucionado, aunque no siempre para mejor

En 1973 el lenguaje C ya estaba establecido, en 1983 C++ aparece en escena. Para  1995 la introducción de Java supuso un hito importante en la historia de la programación. Ya en ese tiempo C++, tenía unos 12 años y era tiempo de cambiarlo, parece que tenemos este ciclo de 10 a 12 años para empezar a cambiar lenguajes. ¿Por qué Java sigue con nosotros? (C# es una copia, como dijo Gosling[1], así que no vale[2].  ¿Y Scala?, bueno, hablemos de eso más adelante).

La verdad es que Gosling tampoco lo entendió muy bien. Puede ser que C# sea una copia, y es porque los negocios lo forzaron a ir en esa dirección. El diseñador principal de C# es Anders Helsjberg, famoso por turbo Pascal, y por Delphi (Object Pascal). Puede que Hejlsberg nunca haya creado un lenguaje desde cero, pero ha tenido siempre la habilidad de llevar un lenguaje existente en direcciones muy interesantes e innovadoras.

Una cosa que hay que entender de la evolución es que no significa necesariamente progreso. Evolución es adaptación al cambio. En la evolución se prueban diversas alternativas ante condiciones nuevas, si funcionan se mantienen, si fracasan se desechan.

La figura de arriba es errada, porque la evolución no es lineal. La evolución se mueve a través de un árbol, de una estructura mucho más intrincada, con entrecruzamientos, atavismos, mutaciones, etc.

Cuando algo funciona bien en un nicho puede permanecer sin cambiar por mucho tiempo. Piensen en el cocodrilo, ¡básicamente es la misma especie desde hace 84 millones de años!

Entonces hay cosas de Java que han funcionado muy bien, es lo que llamamos la plataforma Java. Una plataforma que ha permitido crear un rico ecosistema. En este nicho Java, el lenguaje, se desplaza como un pesado saurópodo.

Quizás la mayor fuente de las críticas a Java tienen su origen en el concepto de “simplejidad”, que identificó muy bien Andres Hejlsberg, en esta entrevista que le hizo hace años Bill Venners:

Bill Venners: Una manera en que C# difiere de Java es en como propaga eventos a los objetos interesados. Java usa clases, a menod clases internas, que implementan interfaces listeners. C# usa delegates, que son un poco más como punteros a funciones. ¿Por qué delegates?

Anders Hejlsberg: Déjame hablar primero un poco sobre como veo la simplicidad en general. Nadie aragumenta que la simplicidad no sea buena, pero la gente define simplicidad de muchas maneras. Hay un tipo de simplicidad que me gusta llamar simplejidad. Cuando tomas algo increiblemente complejo y tratas de envolverlo en algo más simple, a menudo terminas ocultando con un velo la complejidad. No diseñas realmente un sistema más simple. En cierto modo lo haces aún más complejo, porque ahora el usuario tiene que entender por qué fue omitido aquello que ellos necesitarán a veces. Eso es simplejidad. Así que para mi, la simplicidad debe ser verdadera, en el sentido de que cuando más abajo te internas más simple se vuelve. No debe volverse más complicado en la medida que  profundizas.
Los delegates agregan un grado de expresividad que no obtienes con clases o interfaces, por lo cual pienso que son importantes. Los lenguajes de programación que han estado antes que nosotros han reconocido su importancia. Tienen muchos nombres: punteros a funciones, punteros a funciones miembras. En LISP tienes closures (clausuras). Eso es de lo que se trata la programación funcional cuando se hace bien. Son tremendamente útiles.

La simplejidad es otra forma de rascarse la oreja mal. Veamos un ejemplo, supongamos que queremos enseñar a programar, lo natural sería partir con el clásico programa hola mundo.

Consideren la primera clase de Python:

Para crear un programa muy simple que imprima en pantalla la frase “hola mundo”, ustedes deben escribir la siguiente sentencia:

print(“hola mundo”)

print es una sentencia que toma este texto entre comillas y lo despliega en la consola (pantalla), etc.

Ahora piensen el esfuerzo del entrenador de Java:

Para crear un programa muy simple que imprima en pantalla la frase “hola mundo”, ustedes deben escribir el siguiente código:

class HolaMundo {

public static void main(String args[]) {

    System.out.println(“hola mundo”);

}

Por favor ignoren la sentencia class, ya lo vamos a explicar cuando veamos los conceptos de orientacíón a objetos.

Por ahora ignoren que significa public static.

void significa que esta es una función que no retorna ningún valor (wait, todavía no les enseño que es una función verdad?)

System.out.println es una llamada a la clase System (ya vamos a aprender que es una clase, no se apuren), que tiene una variable pública llamada out que ha sido inicializada con la salida estandar (la consola, o pantalla).

etc, etc.

Puedo imaginar la confusión de los alumnos, por eso que Java no debe ser enseñado en los primeros años!

Y que hay de cosas más interesantes, ¿como delegates, o clausuras? ¿funciones de primer orden? Java 7 recién empieza a explorar estos temas, pero con sintaxis horribles.

OK, pero hay que reconocer que esas cosas vienen de un paradigma distinto, el paradigma funcional es distinto al paradigma orientado al objeto sobre el que se basa Java, así que hay que ser justos.

Lo que pasa es que necesitamos incorporar el paradigma funcional, porque, entre otras razones, porque debemos desarrollar más la computación paralela. Los procesadores multicore son cada vez más comunes, y los conceptos de la programación funcional son muy útiles en este nuevo mundo.

Los nuevos lenguajes serán un híbrido entre los paradigmas funcionales y orientados al objeto, porque ambos paradigmas tienen características que deben sobrevivir en las nuevas condiciones y en los nuevos nichos ecológicos que se abren.

La tendencia actual en el ecosistema de Java (la plataforma) es crear nuevos lenguajes (Scala, Groovy, Clojure), o adaptar otros (Jython, JRuby) para la JVM.

Es curioso, cuando .Net nació se decidió diseñarla para que aceptara una gran variedad de lenguajes. El mismo Microsoft decidió iniciar la CLI con tres lenguajes: Visual Basic, C# y un dialecto de C++. La idea era crear una gran cantidad de lenguajes que se adaptaran a esta plataforma. A pesar  de esto C# es el lenguaje más usado, y probablemente termine siendo el que se coma la mayor parte del pastel .Net.

Pero sobre la JVM en el último tiempo ha empezado una verdadera carrera por crear el sucesor de Java.

Scala es el asalto a los cielos más rimbombante hasta ahora, seguido por un modesto y más efectivo Groovy. Otro candidato notablemente es JRuby, impulsado por la popularidad de Ruby. Pero no hay un ganador claro.

Aún así el empeño persiste, tenemos Clojure, y Kotlin, y Gosu!

Pero hay dos adiciones interesantes del último tiempo: Xtend, que tiene el respaldo de Eclipse y Ceylon auspiciado por RedHat.

¡Matemos a Java, para que Java viva! Yo creo que es interesante que se desarrollen estos lenguajes, veamos que pasa con esta explosión cámbrica, exploremos estos lenguajes.

Al menos yo voy a ir un paso más allá, y seguir los consejos de Walter Benjamin, aplicados a los lenguajes de programación, voy a escribir uno, y espero que ustedes me ayuden, así que atentos.

NOTAS:
[1] La frase de Gosling, el creador de Java, es: "The trite answer is, ‘imitation is the sincerest form of flattery–thank you very much, but the other answer is, ‘You guys (at Microsoft) still don’t get it,’ because it’s sort of Java with reliability, productivity and security deleted." (La respuesta trillada es ‘la imitación es la forma más sincera de adulación’, muchas gracias, pero la otra respuesta es ‘ustedes chicos (en Microsoft) todavía no lo entienden’, porque es una especie de Java sin confiabilidad, productividad y la seguridad eliminada” (fuente: http://news.cnet.com/2008-1082-817522.html)

[2] Aunque a partir de  C# 2.0 las cosas empezaron a cambiar, y C# 2.0 salió en 2005!, quizás deberían haberle cambiado el nombre.

Artículos relacionados

• Bárbaros y Caballeros
• Compiladores
• Simplejizando…

Por cierto, esta carta no ha tenido mucha difusión, que yo sepa, pero es interesante, e importante. Creo que los usuarios de redes sociales deberíamos fomentar la creación de un documento como este, que tenga un real peso legal, ¿no les parece?, les dejo la traducción de este documento y espero sus opiniones.

Nosotros los usuarios esperamos que los sitios de redes sociales nos provean de los siguientes derecho en sus Términos de Servicio, Políticas de Privacidad, y en la implementación de sus sistemas:

1. Honestidad: Honren su política de privacidad y términos de servicio.
2. Claridad: Aseguren que sus políticas, términos de servicio, y configuraciones sean fáciles de encontrar y entender.
3. Libertad de Expresión: No borren o modifiquen mis datos sin una política clara y una justificación.
4. Empoderamiento: Soporten las tecnologías asistenciales y la accesibilidad  universal.
5. Auto protección: Soporten tecnologías que mejoren la privacidad.
6. Minimización de Datos: Minimicen la información que se requiere que entregue y comparta con otros.
7. Control: Permítanme controlar mis datos, y no faciliten la divulgación a menos que lo autorice primero.
8. Previsibilidad: Obtener mi consentimiento previo antes de cambiar significativamente quien puede ver mis datos.
9. Portabilidad de Datos: Facilitarme la obtención de una copia de mis datos.
10. Protección: Traten mis datos de forma tan segura como lo hacen con su propia información confidencial, a menos que yo escoja compartirlos, y notifíquenme si han sido comprometidos.
11. Derecho a conocer: Muéstreme como están usando mis datos y permítame ver quien y qué tiene acceso a estos.
12. Derecho a autodefinición: Déjeme crear más de una identidad y usar seudónimos. No los enlacen sin mi permiso.
13. Derecho a Apelar: Permítanme apelar a las acciones punitivas.
14. Derecho a Retiro: Permítanme borrar mi cuenta, y remover mis datos.

Vía Identity Blog.

Artículos relacionados

• Personas especiales
• Sobre la protección de nuestros datos personales
• Diálogos anacrónicos

Gödel from Igor Kramer on Vimeo.

Artículos relacionados

• La respuesta
• La Paradoja de Pinocho y el Origen de la Computación
• Prioridades

Se llama Internet, porque es una red de redes: inter-net, “entre redes”. Alrededor de 1973 habían varias redes que se estaban interconectando entre ellas y con ARPANET. En ese tiempo se hizo evidente que se necesitaba un mecanismo que permitiera unificar las redes. Para resolver este problema Robert E. Khan reclutó a Vinton Cerf, un joven estudiante de doctorado, para trabajar en la especificación de un nuevo protocolo. El fruto de ese primer trabajo fue el RFC 675, que describe TCP/IP, el protocolo básico de la red. Este documento también contiene el primer uso de la palabra internet, para quienes les interese ese tipo de cosas.

Vint Cerf estuvo hoy acá en Santiago, y tuve la oportunidad, el honor, de estrechar su mano y saludarle, pero sobretodo escuchar sus palabras en una charla que dictó hoy en la Escuela de InJeniería.

Habló de la importancia de la innovación, compartió con nosotros sobre las características de un ambiente innovador como Sillicon Valley, y qué se requiere y quizás falta en Chile para lograr esto, comop no castigar el fracaso del emprendedor y tener gente educada y bien capacitada. Habló sobre el futuro, sobre como vamos a tener mucha más información a nuestro alcance. De la internet de las cosas, por que debemos promover, e incluso exigir el soporte de IPv6 de nuestros ISPs. Sobre privacidad y seguridad en la red, sobre participación ciudadana en la red, sobre infraestructura de la red, e incluso sobre energía (con algunas propuestas interesantes, como su analogía de packet switching y la necesidad de desarrollar el concepto de “buffering”, pero con la energía).

Felicito a los organizadores de la charla, a Patricio Poblete y el equipo de NIC Chile, fue una gran oportunidad, un evento memorable.

Artículos relacionados

• Desde siempre…
• Tambores parlantes
• Galeano sobre Alan Turing