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

“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…

Eso se da mucho en las etapas de diseño y modelamiento de datos. Un problema simple después de pasar por la etapa de análisis y diseño puede quedar así:

¡Ah!, que hermosos son estos modelos genéricos, con trazabilidad, controles de accesos, y perfiles, una orgía de tablas y relaciones (¿será que eso de las “relaciones foráneas” despierta alguna inconfesable fantasía en los analistas de sistemas?)

A veces esto se convierte en puro onanismo, originado por un axioma que fue imbuido en nuestros cerebros por un grupo de investigadores de IBM en 1969[1], la idea de que todo debe ser modelado en una base de datos relacional hasta la “vigésima quinta forma normal” [2].

No hay que desconocer que el modelo relacional tiene sus ventajas, después de todo es el corazón de la mayoría de los sistemas transaccionales en la actualidad. A saber las bases de datos relacionales, cuando se usan adecuadamente, tienen muchas ventajas.

1. La teoría que las sustenta está basada en la lógica de primer orden y la teoría de conjuntos, por lo que es fácil de entender y explicar desde un punto de vista teórico.

2. Como las bases de datos relacionales permiten operar con conjuntos se pueden definir operaciones muy eficientes que permiten “cruzar” los datos, esto es conocido como “algebra relacional”. Un lenguaje equivalente es el “cálculo relacional” [3], ambos lenguajes teóricos permitieron crear el lenguaje de consulta estructurado SQL, un lenguaje sencillo y muy poderoso que permite extraer información desde el modelo relacional.

3. Cuando las bases de datos relacionales están bien modeladas usan eficientemente el espacio.

4. Un buen modelo permite realizar consultas que no estaban previstas, hacer nuevos cruces de información, claro que a un costo. Si los índices no existen las consultas pueden tomar tiempos cuadráticos, o peores.

Todo estos beneficios vienen de que las bases de datos relacionales promueven una estructura, sólida, tolerante a fallas, que permite validar errores semánticos o de estructura dento del mismo motor. Dadas estas ventajas posteriormente los sistemas administradores de bases de datos incorporaron otros conceptos, como la transaccionalidad, el famoso ACID (Atomicity, Consistency, Isolation, Durability), que permiten que estas bases sean tan usadas en aplicaciones empresariales (contabilidad, bancos, retail, etc.).

El otro día escuché a un importante ejecutivo decir que todo el mundo usa Oracle, o SQL Server porque sirven para resolver problemas grandes a nivel empresarial. Le comenté que Facebook almacena 135 mil millones de mensajes al mes en una base de datos no relacional, pero ni aún así entendió. Es el típico caso de razonamiento motivado.

Si bien casi todo problema se puede modelar con una base de datos relacional, no siempre conviene resolver un problema con una base de relacional. Ya les mostré un ejemplo en que un programa en C puede ser más eficiente que procesar una simple sentencia SQL, claro requiere más trabajo de desarrollo, pero ahí viene el arte y la ciencia, conocer y usar la herramienta adecuada para cada tipo de problema.

Consideren este modelo:

class Book {
    String title
    String author
    Integer year
    Integer pages
    Set keywords
    Set ratings
}

Versus este otro

class Book {
    Integer id
    String title
    String author
    Integer year
    Integer pages
}

class Keyword {
   Integer id
   String keyword
   Integer bookId
}

class Ratings {
   Integer id
   String rating
   Integer bookId
}

Si tienes un sistema de ventas de libros por internet es mucho más conveniente desde un punto de vista semántico usar el primer modelo, con una sola clase Book, que contiene toda la información relevante en un sólo lugar. Como normalmente el usuario va a interactuar con un libro a la vez este modelo es más simple y directo.

Si vas a hacer estadísticas u operaciones agrupadas sobre los libros, el segundo modelo te conviene más. Pero considera que esas operaciones también las puedes ejecutar mediante algún mecanismos tipo Map Reduce en otro horario, o en una base offline.

Las bases de datos no relacionales permiten abordar el mismo problema, pero a veces desde una perspectiva más simple, y muchas veces más ágil. Pronto veremos algunos ejemplos. Lo importante es tener una mente abierta y considerar que hay formas más simples de rascarse una oreja.

Notas:

[1] Edgar F. Codd, investigador británico trabajando en IBM en 1969 propuso la teoría de las bases de datos relacionales en una serie de papers a comienzos de la década de 1979, recibió el premio Turing en 1981.

[2] Hasta la fecha se conocen 6 formas normales, pero la imaginación de un académico no tiene límites.

[3] El teorema de Codd, que en realidad es un resultado de la lógica de primer orden, garantiza que una expresión en álgebra relacional puede ser expresada en cálculo relacional.

Artículos relacionados

• DMR
• Creadores de Universos
• Datos, datos, datos…

via

Artículos relacionados

• Educación libre
• Transformando un País con un Pequeño Laptop
• Protección y Empoderamiento

(En este enlace pueden ver el video con subtítulos)

Progreso creo que le llamaban…

Artículos relacionados

• Lo legítimo
• Responsable
• La hora como un parámetro

Sucede que decidí optimizar cierto programita que estaba tomando unos 10 minutos para cargar un archivo de unos 50.000 registros, eso es bastante para el tipo de operación que se realizaba (solo había que ingresar los datos a dos tablas). Decidí modificar el código para usar un patrón típico de procesamiento de archivos en modo batch, pero como estaba apurado fui poco cuidadoso y el proceso terminó con un tiempo horrible (iba por la hora cuando lo detuve). Y aunque miraba el código no podía percibir el problema. Así que lo dejé para después y en la noche recién lo pude  revisar. La solución era tan simple como correr una inserción a una lista al interior de un if, y con esto el tiempo del proceso se redujo a 26 segundos (!).

No es el primer error de este tipo que un programador ha enfrentado. En enero de 1990 los sistemas de telefónicos en Nueva York  de AT&T tuvieron un fallo que provocó que la red telefónica completa de Estados Unidos colapsara.

El error tiene un cierto parecido al bug en mi código.

     do {
	switch expression {
          	...
                case (value):

                    if (logical) {
                       sequence of statements
                       break
                   }
                  else  {
                     another sequence of statements
                  }

                 statements after if...else statement

        }
        statements after case statement
   } while (expression)

El código está tomado de acá.

El programador tenía poca experiencia programando en C, asumió que la instrucción break (que puse en rojo)  aplicaba a la sentencia if y esperaba que la secuencia de instrucciones después del if..else se ejecutara, lo que nunca sucedió.

En mi caso es un programa que por ahora sólo estoy ocupando yo, pero en el caso de AT&T el costo fue millonario, y el problema de imagen bastante grave.

Hay que tomarse el tiempo para leer el código, y estar en un estado de concentración para evitar errores de este tipo, y por supuesto desarrollar un buen hábito de probar el código antes de pasar a producción.

El error de AT&T pudo haberse evitado con el uso de herramientas automatizadas de análisis de código. Si les interesa el tema los dejo con este video con una charla de Ira Baxter, de Semantics Design sobre herramientas de este tipo:

Artículos relacionados

• Hazlo
• Zig Zag
• Un Test Más Dificil

Por razones totalmente accidentales, estoy en medio de un proceso de anarquía con uno de mis equipos. No hay un “jefe de proyectos” a cargo de este equipo de 4 desarrolladores. En estos momentos dependen directamente de mí, pero están trabajando literalmente sin un administrador.

Cometemos muchas de las herejías que propone Fred George, y no porque seamos super modernos y estemos experimentando con lean o metodologías post ágiles, simplemente tenemos que sacar las tareas adelante. Y lo interesante, que he observado que la confianza en la capacidad de este equipo ha aumentado, principalmente de nuestros clientes internos.

La siguiente es una descripción resumida de lo que estamos haciendo:

• No hay sprints, ni kanban board, pero  usamos Jira para registrar lo que debemos hacer y saber quien está en qué. No hay standup meetings, ni historias de usuario, ni estimaciones, ni siquiera reuniones de coordinación.
• Ellos toman sus decisiones, son autónomos, me mantienen informado, pero no hay barreras burocráticas. Acuden a mi para que destrabe alguna situación que impide realizar el trabajo. Mi rol es de facilitar y comprometer a las otras áreas para cumplir con las entregas.
• La única barrera burocrática importante está con los pasos a producción.
• El concepto de QA es difuso, no hay un equipo de QA, el usuario final está probando sobre el ambiente de desarrollo las nuevas características y entrega un feed back inmediato. El paso por el ambiente de QA es casi un trámite formal, un paso para homologar ambiente  (lo que cuestiona mucho de los procedimientos internos, pero esa pelea he decidido postergarla).
• Aumentamos la interacción usuario final con el desarrollador, los desarrolladores pasan mucho tiempo sentado con el usuario estudiando el problema, y proponiendo soluciones que incluso el mismo usuario no visualizaba.
• El desarrollador es:  analista funcional, arquitecto, diseñador y programador.
• Compromisos de fechas, entregamos cuando nos comprometemos.
• Peor es mejor, lo entregado normalmente es menos del 100% pero es usable.

Hemos logrado aumentar la confianza, eso es lo que más me ha sorprendido. Los usuarios sienten que están obteniendo por fin aplicaciones que se ajustan más a lo que necesitaban.

Un ejemplo, una aplicación tenía especificado que se debía “cargar archivos mediante un botón”, la implementación que llevaba más de un año en producción, hacía eso, pero sólo permitía cargar un archivo a la vez, y mientras se cargaba el archivo el usuario quedaba imposibilitado de hacer otras cosas. En realidad lo que los usuarios necesitaban era programar una serie de múltiples cargas, el desarrollador al sentarse con el usuario y ver lo que hacían comprendió el grave problema de usabilidad de la aplicación tal como estaba, el resultado fue que en el siguiente release, le llevaron, como sorpresa, una interfaz mejorada, que dejaba libre al usuario para poder realizar otras cosas con su computador (el usuario nunca pidió esa mejora, fue ofrecida “gratuitamente” por el desarrollador).

El gran problema de las metodologías más pesadas es que entre usuario y desarrollador hay muchas barreras: Usuario Final -> Jefe -> StakeHolder -> Sponser -> Jefe de Proyecto -> Analista Funcional -> Diseñador -> Arquitecto -> Programador.

Cambio en las decisiones de negocios según Fred George (click para agrandar)

La interacción debe ser Usuario Final <-> Desarrollador, eso aumenta el entendimiento, la comunicación del problema y la confianza. Finalmente, emerge esta interacción: Usuario Final <- Desarrollador, es el desarrollador quien termina ofreciendo nuevas características al usuario final.

Cosas que me gustan de la presentación de Fred George, y que en cierto modo he transmitido en este blog:

1. Se necesitan resultados, no explicaciones, ni buscar culpables. Este pensamiento elimina las estimaciones, retrospectivas, iteraciones, y todo ese “waste” que terminan generando las metodologías ágiles.

2. Los standups meeting y las historias se pueden reemplazar con una mayor interacción con el usuario.

3. Menos roles, colapsar todas esas funciones en una sola: desarrollador, hasta el administrador desaparece. Finalmente lo que necesitamos es contratar buenos programadores.

Buenas Prácticas Agiles no usadas (click para agrandar)

El valor de generar confianza entre el desarrollador y el usuario es, finalmente, la gran enseñanza de esta experiencia, y lo que transmite Fred George en su charla. Les reitero la invitación a verla, y ha estudiar sus herejías, y ponerlas en práctica.

Un lector cínico podrá criticarme y decir que en realidad no estoy haciendo gestión y esta anarquía terminará pasándome la cuenta, la verdad es que nunca he planeado seguir esta estrategia, siempre he trabajado así , soy un anarquista convencido, y mi experiencia me ha mostrado que se pueden sacar adelante muchos proyectos de este modo. Lo que pasa es que la gente se pone nerviosa cuando no hay  estructura, planificación y todo eso, sobretodo los ingenieros, que son los más nerviosos. No se preocupen tanto y confíen.

Artículos relacionados

• Hazlo
• Lo que sabemos
• Comprensión de lectura

Artículos relacionados

• ¿Qué es la Energía?
• Que cosas suceden con el apagón
• Qué es Cloud Computing

Pero el consejo que Ricardo Baeza considera más importante es: “no piensen en lo que tienen que hacer, ¡háganlo!”. ¿Cuánto tiempo hemos perdido en pensar lo que tenemos que hacer, en cómo hacerlo, cuando todo ese tiempo lo podríamos haber aprovechado en hacer lo que debíamos? Hazlo.

Cuando uno desarrolla software el “hazlo” corresponde a entregar el producto, o servicio, en la fecha comprometida. En inglés dicen Ship It, ¡entrega la maldita aplicación!

En palabras de Jeff Attwood: “Version 1 Sucks, But Ship It Anyway” (“La versión 1 apesta, pero entrégala de todas maneras”).

Todo proyecto está plagado de dificultades:

• La planificación era muy agresiva y demasiado corta. ¡Necesitamos más tiempo!
• Encontramos problemas técnicos no previstos que nos forzaron a hacer compromisos con los que no estamos conformes.
• Teníamos un diseño erróneo, y necesitamos cambiarlo en medio del desarrollo.
• Nuestro equipo experimento fricciones internas entre sus miembros que no anticipamos.
• Los mejores programadores abandonan el equipo porque encontraron una mejor oferta económica
• Los clientes no respondían a nuestras solicitudes de información a tiempo.
• La gente de infraestructura y de desarrollo no se comunicaban adecuadamente.
• El tiempo de respuesta de los proveedores no era el que ofrecieron inicialmente.
• Usamos una tecnología que fue descontinuada en la mitad del proyecto.

Los problemas son miles. Los registros en correo electrónico dejan una traza de cientos de mensajes diarios, y varios gigabytes de discusiones, aclaraciones, documentos, pantallas, informes, cientos de revisiones a la carta gantt, una larga lista de bugs y correcciones.

“Al final del ciclo de desarrollo finalizas con un software que es una pálida sombra del brillante, glorioso monumento a la ingeniería de software que visualizaste al empezar.”

Y la tentación de tirar la toalla, como dice Attwood, es grande, y pedir más tiempo para poder completar lo que falta es el mayor error que se podría cometer, ¡porque los verdaderos desarrolladores entregan!

Hay muchos errores de los que todavía no sabes nada, pero ¿cómo vas a enfrentarlos si aún no entregas el software? No es el mejor producto, puede que consideres que es el peor servicio que has entregado,  pero a veces peor es mejor.

Un software, un servicio que se usa, que es entregado, que ha sido liberado a sus usuarios es mejor que aquel que sufre la enésima reprogramación para entregar un “producto de calidad”.

Todo esto a propósito de un hito que cumplimos con mi equipo, precisamente hoy. Porque se trata de un servicio que entró en operaciones en la fecha comprometida, lo entregamos, lo hicimos. Aún faltan cosas, tenemos nuestra lista de bugs y pendientes, seguiremos trabajando por meses, pero lo esencial está allí.

We shiped it! Los usuarios ya lo están usando, el servicio está en el aire. Entregamos, ¡lo hicimos!, un sistema funcionando, lo logramos  y se siente bien

Artículos relacionados

• Lo que sabemos
• Peor es mejor
• Confianza y Anarquía

Knuth responde a todas las preguntas

Todos tenemos nuestros heroes personales, hombres representativos, sobretodo del campo en que nos desarrollamos.

Uno de mis más antiguos héroes personales es el profesor y programador Donald Knuth.

Autor del famoso Art of Computer Programming, y un gran programador. Creador de Metafont y TeX, usados por miles de científicos hoy en día para publicar sus artículos.

Donald Knuth es profesor emérito en la Universidad de Stanford, y probablemente el geek más antiguo que existe. Por ejemplo, las versiones de Tex se aproximan al número trascendente Pi, por ejemplo, la primera versión era la 3, la segunda 3.1, la tercera 3.14, y así sucesivamente. Además tiene la costumbre de pagar 2.56 dólares por cada error encontrado en sus libros (porque “256 centavos es un dolar hexadecimal”).

Imitando al famoso físico Richard Feynman tiene la costumbre de que la última clase en cada curso que dicta está abierta para contestar cualquier pregunta sobre cualquier tema, excepto las relacionadas con política, religión, o el examen final.

Una de estas sesiones de preguntas y respuestas se realizó como una conferencia el 5 de octubre de 2001 en la Technische Universität. Esta sesión fue transcrita en en Notices of AMS (American Mathematical Society). Ustedes pueden descargarla desde ese sitio, pero quiero compartir con ustedes una traducción de algunas de las preguntas que me parecieron más interesantes, los invito a conocer a uno de los grandes pensadores de las ciencias de la computación (los títulos son mi culpa).

Las ciencias de la computación

Knuth: En todos los cursos que doy en Stanford, el último día se dedica a una sesión de “todas las preguntas son contestadas”. Los estudiantes no están obligados a vernir a esta clase, pero si vienen puede preguntar sobre cualquier asunto excepto religión o política o sobre el examen final. Yo copié la idea de Richard Feynman, quien hacía lo mismo en sus clases en Caltech, y siempre era interesante ver que querían saber realmente los estudiantes. Hoy día contestaré cualquier pregunta sobre cualquier asunto. ¿Permitiremos religión o política? No lo sé. Pero no hay un examen final de que preocuparse. Trataré de contestar sin tomar mucho tiempo de modo que tengamos muchas preguntas. Así que ¿quién quiere preguntar primero? … Bueno, si no hay preguntas [Knuth hace el gesto de retirarse]

Pregunta: Había un reporte especial para el presidente norteamericano, el reporte PITAC, conteniendo algunas recomendaciones. Me preguntaba si usted quiere comentar sobre las prioridades delineadas en esas recomendaciones: mejor ingeniería de software, construir un computador teraflop, mejoras en la Internet incluyendo una mayor seguridad y más ancho de banda, y los impactos socio económicos de manejar información disponible a través de las redes de computadores.

Knuth: Pienso que esa es una solución brillante del problema de que presentarle a un presidente. Pero de hecho lo que me gustaría ver es que a miles de cientificos en computadoras se les permita hacer lo que ellos quieran. Eso lo que realmente permite avances en el campo. De mi experiencia escribiendo The Art of Computer Programming, si me preguntabas en ese tiempo de qué era lo más importante que pasaba en ciencias de la computacion en ese año probablemente no tendría respuesta para la pregunta, pero en cinco años todo el campo cambió. Las ciencias de la computación son el producto de una tremenda colaboración de gente de todo el mundo añadiendo pequeños ladrillos a una enorme pared. Los ladrillos individuales son los que la hacen funcionar, y no los hitos individuales (milestones).

Pregunta: ¿Qué piensa de la investigación en algoritmos criptográficos? Y que piensa de los esfuerzos de los políticos de hoy para poner límites a la investigación en criptografía?

Knuth: Ciertamente toda el área de algoritmos criptográficos es una de las más activa y excitantes áreas en ciencias de la computación en los últimos diez años, y muchos de sus resultado son espectaculares y hermosos. No puedo decir que soy particularmente buen en este tema, debido a que no puedo pensar en buenos ataques por mi mismo. Pero el problema clave es ¿qué pasa con el abuso de los métodos seguros de comunicación? No quiero que los criminales usen esos métodos para ser mejores criminales. Soy un hombre religioso, y pienso que Dios sabe todos mis secretos, así que siempre siento que cualquier cosa que pienso es conocimiento público en cierta forma. Vengo con este bagaje. No siento que tenga que encriptar todo lo que hago. Por otra parte, me sentiría bastante diferente si alguien comenzara a usar tal apertura en contra mía, robando mi cuenta bancaria o cualquier cosa. Así que yo apoyo un alto nivel de secretismo. Pero sobre si debería ser imposible para las autoridades decodificar cosas aún en investigaciones criminales, en casos extremos, allí yo tiendo a irme al lado que quiere que se disponga de alguna manera de quebrar algunas claves a veces.

Dios y la computación

Pregunta: Los matemáticos dicen que Dios tiene el “Libro de las Demostraciones”, donde todas las demostraciones más bellas están escritas. Puede recomendar algunos algoritmos del “Libro de los Algoritmos”.

Knuth: Esa es una buena pregunta. Fue Paul Erdo˝s quien promulgó la ide de que Dios tiene un libro conteniendo las mejores demostraciones matemáticas, y creo que mi amigo Günter Ziegler en Berlin ha recientemente escrito sobre esto. Recuerdo que los matemáticos me decían en los años 1960′s que considerarían las ciencas de la computación una disciplina madura cuando esta tuviera 1.000 algoritmos profundos. Pienso que probablemente hemos alcanzado los 500. Ciertamente hay muchos algoritmos que pienso deben ser considerados absolutamente hermosos e inmortales, en algún sentido. Dos ejemplos son el algoritmo de Euclides y el correspondiente que trabaja en notación binaria y que puede haber sido desarrollado en forma independiente en China, casi tan tempanamente como el algoritmo de Euclides fue inventado en Grecia. En mis libros me preocupo con los algoritmos clásicos y que han estado con nosotros por un largo tiempo. Pero todos los años encontramos nuevas ideas brillantes que pienso van a permanecer para siempre.

Pregunta: ¿Cuál es la relación entre Dios y los computadores?

Knuth: En uno de mis libros, 3:16 Bible Texts Illuminated [BTI], uso muestras aleatorias para estudiar sesenta diferentes versículos de la Biblia y lo que la gente diversas percepciones y de diferentes siglos and dicho sobre estos versículos. Hice el estudio primero por mi mismo, y entonces encontré que era los suficientemente interesante como para hacer un libro sobre esto. Obtuve a sesenta de los mejores artistas en el mundo para ilustrar mi libro, muchos de ellos en Alemania. El trabajo artístico fue exhibido dos veces en Alemania, y en otros paises alrededor del mundo. Fue mostrado también en la Catedral Nacional en Washington,
DC. En ese libro usé metodologías que los cientificos de la computación usan a menudo para entender un asunto complicado, para ver si este método podría dar alguna luz en la Biblia, la que es en si misma un asunto complicado.
En el libro no doy respuestas. Sólo digo que pienso que es bueno que la vida sea una búsqueda constante. El viaje es más importante que el destino

El futuro de la computación

Pregunta: ¿Cuáles son los cinco problemas más importantes en las ciencias de la computación?

Knuth: No me gusta este negocio de los “primeros diez” . So los úItimos diez lo que me gustan. Pienso que usted debe ir por las cosas pequeñas, las piedras que construyen la pared.

Pregunta: ¿Tiene algunas ideas sobre la computación cuántica?

Knuth: Si, pero no sé mucho al respecto. Es un paradigma muy diferente del que estoy acostumbrado. Tiene en común un montón de cosas con el tipo de computación que conozco, pero tambien es bastante misteriosa en que tienes todas las preguntas al final; no puedes hacer un test y entonces determinar que hacer a continuación. Muchos de ustedes han visto la película “Lola rennt” (llamada “Run Lola Run” en Estados Unidos), en la cual el argumente ocurre en tres tiempos diferentes, con el resultado de tres diferentes ramas. La computación cuántica es algo como eso: el mundo va por muchas ramas, y estamos interesados en la única en donde el resultado es el más aceptable. Soy bueno en computación no cuántica, peroo es muy posible que si la computación cuántica prende, yo no sea capaz de hacer nada nuevo. El trabajo de mi vida en con computadores no porque esté interesado tanto en computación, sino porque suced que yo soy bueno en este tipo de computación. Afortunadamente para mí, encontré que lo que puede hacer bien era interesante para otra gente. No desarrollé una habilidad para pensar sobre algoritmos porque quisiera ayudar a la gente a resolver problemas. De algún modo en ese tiempo cuando era adolescente, tenía una manera peculiar de pensar que me hizo buen programando. Pero puede que no sea bueno en programación cuántica. Parece un mundo diferente del mío.

Pregunta: ¿Tendremos máquinas inteligentes alguna vez? ¿Deberíamos tenerlas?

Knuth: Han habido siempre estimaciones exageradas sobre cuan pronto tendremos una máquina que sea inteligente. Yo todavía no veo señales de acercarnos al problema centra de entender lo que es la cognición, lo que significa pensar. Los neurologistas están haciendo mejores medidas que antes, pero están lejos de encontrar la respuesta de modo que no puedo clasificar a la neurociencia como uno de los campos más activos del trabajo actual. La biología ha estado obteniendo respuestas, con el ADN y las células madres, y todo eso. Pero con la cognición todabía están buscando el secreto.Algunos libros muy provocadores para el pensamiento han salido hace uno o dos años atrás, uno escrito por Hans Moravec [Mo], y otro por Ray Kurzweil [Ku]. Ambos están diciendo que en veinte o treinta años tendremos máquinas más inteligentes que os humanos. Algunos se preocupan por esto. Mi actitud es, si es es verdad, mas poder para ellos. Si son más inteligentes que nosotros ¿cual es el problema? Entonces podremos aprender de ellas. Pero no veo señales de ningún adelanto a la vuelta de la esquina.

Dos semanas atrás estaba en Grecia en el lanzamiento de un nuevo libro de Christos Papadimitriou, quien es presideente (chairman) de ciencias de la computación en Berkeley. El publicó una novela en griego llamada “La Sonrisa de Turing” [Pa]. No quiero contar la histora, pero cuando se publique en alemán o inglés encontrarán una buena discusión de la inteligencia artificial y el test de Turing para la inteligencia.

El modelo más prometedos de como trabaja el cerebro que he visto ve al cerebro como un algoritmo genético dinámico que opera todo el tiempo. Mientras les hablo, sus cerebros tienen un monto de teorías compitiendo sobre lo que voy a decir. Es la sobrevivencia de la más adaptada, una batalla continua entre teorías compitiendo. Algunas llegan a la superficie y realmente entran en la conciencia, pero las otras están todas allí. Algún tipo de apareamiento de conceptos debe estar ocurriendo en nuestras cabezas todo el tiempo. Este modelo parece tener las propiedades correctas para contar sobre como hacemos lo que hacemos con el relativamente bajo tiempo de respuesta que tienen las neuronas. Pero no soy un experto en esto.

Sobre las patentes de software

Pregunta: ¿Cual es su pensamiento sobre las patentes de software? Hay una gran discusión en Europa sobre si el software debería ser patentable.

Knuth: Estoy en contra de patentar cosas que cualquier estudiante se esperaría que descubriera. Han habido muchas desagradables patentes de software en Estados Unidos por ideas que son completamente triviales, y eso me preocupa mucho. Hay una organización que ha trabajado por muchos años para patentar todas las ideas triviales remanentes y hacerlas disponibles a todo el mundo. La manera en que el patentamiento ha avanzado está amenazando con la paralización de la industria del software
Los algoritmos son cosas inherentementes matemáticas que deberías ser tan inpatenteables como el valor de π (pi). Pero para algo no trivial, algo como el metodo del punto interior de la programación lineal, hay mas justificacón por que alguien pida un derecho a licenciar el método por un corto tiempo, en vez de mantenerlo como un secreto comercial. Esa es la idea original de las patentes; la palabra patente significa “hacer público”.Fui entrenado en el cultura de las matemáticas, así que no acostumbro cobrarle un centavo cada vez que una persona us un teorema que he demostrado. Pero le cobro a alguien por el tiempo que paso explicándoles cual teorema aplicar. Está bien cobrar por servicios, personalización y mejoras, pero no hagan a los algoritmos en si mismo algo propietario.

Hay un asunto interesante de todas maneras. ¿Podría usted tener la patente sobre un número entero positivo? No es concebible que si tomamos un millón de los más grandes supercomputadores de hoy día y las dejamos correr, ellos puedan calcular una cierta constante de 300 dígitos que pueda resolver un problema NP completo tomando el mcd de la constante como un número de entrad, o por otra combinación entretenida. Este número entero requeriría na cantidad masiva de tiempo de computación para ser encontrado, y si usted conoce ese entero, entonces usted podría hacer todo tipo de cosas útiles. Ahora, ¿es ese número entero realmente descubierto por el ser humano?
¿O es algo que está dado por Dios? Cuando empezamos a pensar en asuntos de complejidad, debemos cambiar nuestro punto de vista sobre lo que es natural y lo que es inventado.

El arte de programar

Pregunta: ¿Cuál es la conexión entre matemáticas y la programación de computadores vistos como arte?

Knuth Arte es Kunst. La película “Inteligencia Artificial” se llama “Kunstlicher Intelligenz” en Alemania, esto es artificial también como artítica. Yo pienso en programar con la belleza en mente, como algo que sea elegante, algo de los que puedas estar orgulloso por la manera en que las cosas encajan juntas. Las matemáticas del mismo modo tienen elegancia. Ambos campos, la computación y las matemáticas, son diferentes de otras ciencias porque son artificiales; no están en la naturaleza. Están totalmente bajo nuestro control. Nosotros creamos los axiomas y cuando resolvemos un problema, podemos probar que lo hemos resuelto. Ningún astrónomo sabrá nunca si sus teorías en astronomía son correctas. No puedes ir al sol a medirlo. ASí que estos son mis primeros pensamientos sobre esa conexión. Pero hay una diferencia entre matemáticas y la programación de computadores, y a veces puedo sentir cuando me pongo un sombrero o el otro. Algunas partes de mi le gustan las matemáticas, y a algunas partes de mi le gusta hackear emacs. Pueden ir juntas okay, pero no las veo en el mismo paradigma

Pregunta: Usted ha estado emitiendo cheques a la gente que le informa sobre errores en sus libros. Nunca he escuchado de alguien cobrando esos cheques. Sabe cuanto dinero tendría que depositar, si repentitnamente se cobraran todos los cheques?

Knuth: Hay un hombre que vive cerca de Frankfurt quien probablemente tiene más de $1,000 (mil dolares) si ha cobrado todos los cheques que le he enviado. Hay un hombre en Los Gatos, California, a quien nunca he conocido que cobra un cheque por $2.56 una vez al mes, y lo ha estado haciendo por varios años. Con todo he girado más de 2.000 cheques en estos años, y el monto promedio excede los $8 dolares por cheque. Aun si todos cobraran su cheque sería más que valioso para mi saber que mis libros van siendo cada vez mejores.

Artículos relacionados

• La programación como un Arte (Parte V y final)
• La programación como un Arte (Parte IV)
• La programación como un Arte (Parte III)