Strong Typed

My OOP Oh! moment.

2010-06-09T14:10:00.000-07:00

Inheritance as the natural control structure in OOL

A few days ago I had my Object Oriented Programming "Oh! moment". I retook my studies of smalltalk reading Ragnar Hojland's LDAPlayer package. I didn't understood its design. Its LDAP-filter category seem to have a class for each possible variation of LDAP filter. A class for each variation of LDAP filter, for god's sake!. The same thing with the LDAP messages or the BER elements. A lot of classes were empty but for a single overloaded method. What a waste!

If I hadn't found Kent Beck's Smalltalk Best Practice Patterns I would remain in ignorance for more time. In the Choosing Message Pattern he says:

Procedural programs implement variations with conditional logic, either if-then-else or case statements. Two problems arise from such hard-coded logic. First, you cannot add a new variation without modifying the logic. This can be a ticklish operation, getting the new variation is without disturbing the existing variations. Second, such logic tends to propagate. You do not have to account for the variation in one place, you have to account for it in several. Adding a new variation means tickling all of the places where the logic lives.

Messages provide a disciplined way to handle theme-and-variation programming. Because the variations live in different objects, they have much less opportunity to interfere with each other than just putting the variations in different parts of the same routine. The client, the object invoking the variations, is also isolated from what variation is currently active.

Adding a new variation is as simple as adding a new object that provides the same set of messages the other variations provide and introducing it to the object that wants to invoke the variations.

If you are choosing between several action according to the parameter's class, then you should convert those actions in a new methods in each one of the respective classes and make an unconditional invocation to the new method. In this way you remove a case statement.

In the same way, if you are choosing between action according to the parameter's value, it is an indication that you should subclass the parameter's class. In this way, an LDAPFilterSingle becomes LDAPFilterWIthNot, LDAPFilterWithAnd and so many others.

The problem with OO teaching is that it makes emphasis in subclases as subtypes and the Liskov substitution principle. With this point of view, your most important work as a designer is to define the correct taxonomy of your objects, and that's one of the most difficult problems that exists. If you are forced to classify all the future types of your system today, you're screwed. Subclasses as subtypes is not the way inheritance was intended to be used. You make a subclass to share common code. You make a subclass to overload a method, so you can avoid an if..then or a case. A subclass is not an ontologic statement about the nature of the instances.

Open Classes goodies

So, subclassing and overloading allows you to reduce the control structures in your methods. But the goodies don't end there. Since in smalltalk all the classes are open (you can add your own methods), this pattern is valid even for classes outside your project. So, the base classes of the system become more powerful with the time.

That's being in another league regards flexibility.

Side note: Ruby has open classes too. As a python programmer I've always seen Ruby as a language too similar to python to be worth to learn it. Now, I feel a little Ruby envy.

Language's culture

2010-01-29T17:14:00.000-08:00

I don't remember how I get interested in Haskell, but I remember that Why Haskell matters sealed the deal. There was a comparison of QuickSort implementations in C++ and Haskell. The Haskell version was so beautiful, so concise, that I had to learn it.

Even the first time I saw the comparison, I knew that it wasn't all fair. The algorithms weren't the same. The C++ version sorted an array in place. The Haskell acted upon lists. Of course, you can write a Haskell version that use mutable arrays. And you can, with some modification, implement the C++ version using lists, list concatenation and filter.

But why a C++ programmer would use a list structure when an array can do the work? Why a programmer would spend his time learning Haskell to then solve a problem imperatively?

Each language impose a culture, not only by forbidding thing, but by making other easy. Haskell not only gives you functions as firt-class citizens, but it makes so easy to compose, curry and uncurry them, that it is only natural to do it.

This composability is the real reason why to program in Haskell is a pleasure.

Desarrollando con zc.buildout

2010-01-28T16:33:00.000-08:00

En un post anterior comentaba que es zc.buildout, por qué puede necesitarlo un desarrollador y como instalarlo. Ahora hablaré sobre como desarrollar un proyecto usandolo.

buildout.cfg

buildout.cfg es el archivo que determina como se construirá el proyecto, cuales son sus partes y como generarlas. El formato del archivo es el tradicional .INI de windows, dividido en secciones (nombres encerrados entre corchetes) formadas por lineas con el formato clave=valor.

[buildout]
develop = .
parts = dependencias

[dependencias]
recipe = zc.recipe.egg:eggs
eggs = python-ldap
      docutils

La sección buildout es la única requerida en el archivo buildout.cfg. La primera linea

develop = .

indica cuales son los directorios con los paquetes de desarrollo (los paquetes o huevos en los que estamos trabajando y que todavía no hemos instalado). Cada uno de esos directorios debe tener un archivo setup.py que defina el huevo de python.

parts = dependencias

dice que este proyecto esta formado por una única parte, llamada "dependencias". Cada parte deberá tener su propia sección donde se indique como construirla. En nuestro ejemplo

[buildout]
develop = .
parts = dependencias

[dependencias]
recipe = zc.recipe.egg:eggs
eggs = python-ldap
docutils

zc.recipe.egg es un paquete que define un récipe con nombre eggs . Este recipe es un programa encargado de construir la parte dependencias. Lo que hace este recipe en particular es descargar los paquetes python-ldap y docutils. Nota que una linea que comienza con espacios significa que es la continuación de la linea anterior.

Así como hay récipes para instalar los paquetes o huevos de python, hay otros que instalan aplicaciones en C, como openldap o postgresql o para descargar proyectos vía CVS o git. El python package index tiene una larga lista de paquetes con récipes para zc.buildout.

Cuando hayas terminado con buildout.cfg puedes construir todas las dependencias de tu sistema con un simple comando:

{ ubicado en la raiz de tu proyecto}
$ bin/buildout

Deberas ejecutar buildout cada vez que agregues una nueva dependencia y hayas editado buildout.cfg. Pero lo más importante es que tus usuarios también podrán instalar todas las dependencias de tu aplicación ejecutando buildout.

Esto es todo lo que hay que saber de zc.buildout para usarlo en tus desarrollos. El resto es buscar las recetas que generen las partes que necesites. En última instancia, un récipe es simplemente un script en python, por lo que puedes crear uno nuevo si no consigues ninguno que satisfaga tus necesidades.

A monad non-tutorial

2010-01-22T04:03:00.000-08:00

...or why you shouldn't ask what a monad is

"What is a monad?" is one of the most common question when you're learning Haskell. And it's there when troubles start, because it is the wrong question. Ask a wrong question, and you'll get the wrong answer. The only right answer to this question is a mathematic definition:

[...] A monad is a triple (M, unitM, bindM) consisting in a type constructor M and a pair of polymorphic functions {unitM :: a -> M a} and {bindM :: M a -> (a -> M b) -> M b}

These functions must satisfy three laws [...]

(unitM a) `bindM` k = k a
m `bindM` unitM = m
m `bindM` (\a -> (k a) `bindM` (\b -> h b)) =
(m `bindM` \a -> (k a)) `bindM` (\b -> h b)

After a reverential minute of silence, you start to figure it out that maybe you shouldn't be asking that. Your mind is working fast to come out with a phrase to fool your interlocutor into thinking that you have understood. But there's nothing to understand.

You'll see, that's the way definitions work. They are use to label objects, that's the only thing they are good for. So if the definition of homo sapiens is "an animal, mammal, of the order of primates, family hominidae and genus homo" and if you know what is an animal, a mammal, a primate... etc. then you can put objects into classes: "my friend Ed, homo sapiens; mi dog Buch, no".

It is why, not what

The least interesting thing about monads is its definition. The real question is "why?". You only make a definition if it is useful, if you use it frequently. So, let's see how this definition is implemented in Haskell:

class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
return a :: m a

So, a monad is an Haskell class. Or, if you are a Java guy (and let's confess it, who isn't?), then you can think in a monad as an interface. But, again, why? When you see FileishInterface with its methods open, close, read, write and seek, you say: "Oh, so FileishInterface represents objects that behave like a file, I get it". You can think in a FileishInterface instance using a TCP connection or a byte array. With monads, there is nothing in its interface that make you think in a concrete example.

An that is a good thing. After all, FileishInterface is so concrete that it could be used only in a very few cases. The interface of Monad is so generic that it could be used in a wide range of objects. Paradoxically, that make it hard to think in a use when you are learning the concept.

When

The other problem when you are learning monad is that you want to use them. You open your editor and say "I'll make a program and I'm gonna create my own monads and I'll show it in the Haskell Café and I'll become a member of the Secret Category Cabal and I'm gonna spend my evenings talking about Kleili arrows and functors and maybe Paul Hudak will friend me in facebook". Curiously, you have never say "Mmm, today I feel like I'm gonna make a program that uses hashtables". You don't try to impose data structures to your imperative programming, so why are you trying to force monads in your haskell programs? Don't go after monads, let the monads find you.

You'll know when you need them. One day you will make a program and you'll write a type constructor:

type M a = ....

(did you notice how your type constructor's name is "M" as in "Monad"? This is a clever, subtle way in which the author -- me -- hints that you've started to write a monad).

If you use your type constructor M to create only one type, say M Integer, then you don't need monads. But, after a few hours of programming, types start to appear and you have M Char, M String, M Bool and others. After a few coups of coffee you have functions all over the place with types like Integer -> M Integer, Integer -> M Bool, Bool -> M Char.

Then you need to chain these function together, but it's a pain in the functional ass. Each time you need to connect two functions, say Integer -> M Bool and Bool -> M Char, you need to invoke the first function, extract the value inside M and invoke the second one. And it is then --I hope-- that the "aha! moment" comes to you. You can write a function that extract the a from M a and use it to invoke a function with type a -> M b. You have invented >>=, the bind function!

Since you wrote the type constructor M, you are the one who know how to extract a from M a. And you know how to chain that value to a -> M b. Each monad has its own definition of >>=, adapted to its structure.

When is return used? If you see the >>= definition, it needs a M a to start. If you have a value of type a instead, you'll need a way to transform it into M a. That's what return does.

Now what?

Hopefully you know by now that the definition of monads is not the important part for a programmer. You only need to focus in the type constructor and the bind function. What does the type constructor represent? What is it used for? How they defined bind: how it extract the value inside one of those new types and how it chain it to the a -> m b function?

So, now you can go back to those tutorials that explain what are monads and give them a second look. You can review the do notation that help you to write your long chain of >>= expression in a clear way. Good luck.

The IO Monad

But wait! I can't end this post without talking about IO monads, can I? A monad is a monad is a monad. IO monads are not the exception. Since your understanding of monad is better now and my hands are tired, I'll cheat a little.

The IO a data constructor can be seen as a function that takes a value of type a and returns a C program. When that program is compiled and executed, it will return that value. That's the work of the IO bind. It compiles and executes the first argument (IO a), gets the a values and feed it to its second argument (a -> IO b) which returns a new C program that will return a value of type b. That's why the haskellers can see you right into the eyes and say that Haskell is a pure language: "Of course that putChar is a pure function. Giving the same input, it will always return the same C program!".

Thinking in this way is useful to understand why IO is a monad, but it is a waste of your attention. In your daily programming, you'll be better thinking that the IO values are an imperative language embedded in haskell and >>= is its interpreter.

zc.buildout

2010-01-21T11:30:00.000-08:00

Comienzo hoy una serie de artículos sobre desarrollo de aplicaciones en python, particularmente, desarrollo web. Y nuestro invitado del día es zc.buildout. O simplemente buildout, para los amigos.

A buildout lo había mencionado de pasada en otras oportunidades. Ahora es el momento de tratarlo con exclusividad, como se merece.

Que problema soluciona buildout?

Desarrollar una aplicación para distribuirla tiene una serie particular de problemas. Los equipos donde se instale pueden no tener todas las aplicaciones de las que esta depende. O pueden tener versiones viejas o incompatibles. Este problemas se agrava cuando desarrollamos en un lenguaje de scripts. Aquí las dependencias suelen ser librerías desarrolladas con ese mismo lenguaje. Tristemente, ninguna distribución puede ofrecer una versión actualizada de todos los proyectos hechos en python, perl o ruby.

Esta situación le deja al programador (es decir a ti) la necesidad de hacer que el instalador de su aplicación busque e instale todas las dependencias, en sus versiones correctas. Esto distrae al programador de su tarea real: desarrollar la mejor aplicación posible.

Y precisamente este es el trabajo de buildout: asegurarse de conseguir e instalar todas las piezas de software que tu aplicación necesita.

Como funciona

Buildout se encarga de ensamblar todas las partes que necesita tu aplicación. Esto lo logra esto a traves de un lenguaje declarativo y extensible. Una serie de "recetas" pre-establecidas resuelven los problemas típicos del manejo de dependencias. Así que en la mayoría de los casos basta con indicarle tus necesidades y buildout se encargará en resolverlas.

La parte extensible entra en juego cuando tu aplicación necesita algo inusual. Entonces programas una nueva receta (en python) que resuelva esa dependencia y listo. El mundo tiene una nueva receta de buildout que puede ser usada por otros desarrolladores y cada día el trabajo con buildout se facilita.

Ejemplo práctico

El primer paso es, desde luego instalar buildout:

$ sudo easy_install zc-buildout

En otro post comenté como instalar easy_install. Buildout depende exclusivamente de easy_install y es todo lo que el desarrollador necesita para manejar el problema de las dependencias. Sin embargo, el usuario final podría no tener instalado zc-buildout, por lo cual el recomendable agregar a tu proyecto un pequeño script que se encargue de conseguirlo:

# Bajamos bootstrap
$ wget 'http://svn.zope.org/*checkout*/buildout-website/trunk/bootstrap.py'

# Y lo guardamos en un lugar seguro para
#agregarlo a cada poyecto que use buildout
$ mv bootstrap.py ~/bin

Ok, ya tenemos instalado buildout y bootstrap, ahora solo necesitamos un proyecto en python:

# Creamos nuestro nuevo proyecto
$ mkdir miproyecto
$ cd miproyecto

# Inicializamos buildout
$ buildout init

# ...y copiamos bootstap.py para
# beneficio de nuestros usuarios
$ cp ~/bin/bootstrap.py .

Esto creará los siguientes objetos en nuestro directorio:

bin/
develop-eggs/
eggs/
parts/
buildout.cfg

En bin/ esta una copia de buildout. Aquí se instalarán los comandos de todos los huevos (paquetes en python) que instalemos.

develop-eggs/ es un directorio manejado por buildout y que no necesitamos tocar directamente. Aquí habrá un enlace simbólico a cada paquete en desarrollo que necesitemos. Un paquete en desarrollo es, como su nombre lo indica, un paquete sobre el cual estamos trabajando todavía. Los paquetes en desarrollo no están instalados en el sistema y normalmente son inaccesibles a otros paquetes. Es por eso que buildout les ha dedicado todo un directorio: para poder acceder a ellos sin necesidad de instalarlos.

En eggs/ irán todos los paquetes o huevos de los que nuestra aplicación necesite. De nuevo, buildout los bajará por nosotros y verificará en cada ocasión, de ser necesario, que estén en su última versión.

parts/ es usado por los récipes. Aquí es donde se compilará, por ejemplo, una aplicación en C, que necesite nuestra aplicación.

Cuando empaquetemos nuestra aplicación, el programa empaquetador de python (setuptools) creará otros directorios, no relacionados con buildout.

Finalmente, está el archivo buildout.cfg. Para nosotros como desarrolladores, este es el corazón de buildout. Aquí indicaremos todas las instrucciones necesarias para que nuestra aplicación encuentre un entorno donde pueda correr sin problemas. Indicaremos cuales librerías en python necesita, y si estas son estables o no. Le diremos que aplicaciones en C, C++ u otro lenguaje tendrá que descargar, compilar e instalar, si ese fuera el caso. Le diremos si necesitamos crear una base de datos y cual debe ser su contenido. En fin, buildout.cfg nos dice todo lo que necesitamos saber de las dependencias de nuestra aplicación.

El contenido de buildout.cfg lo trataré en la próxima entrega.

Por qué git

2010-01-20T07:16:00.000-08:00

Lo confieso: como desarrollador solitario, nunca había sido amigo del control de versiones. Como serlo, si requería tener corriendo un servicio, con las configuraciones y reconfiguraciones que ello conlleva (por mi manía de siempre probar la última distro)? Jamás me sentí a gusto con CVS, sin poder saber a ciencia cierta por qué.

Hasta que conocí git. Primero que nada, git es una aplicación. No requiere tener un servidor corriendo. Tu repositorio esta en el mismo directorio que tu proyecto, por lo que el respaldo es mas sencillo. Solo tipeas los comandos y ya!

En segundo lugar, es distribuido. Trabajo al menos en un par de computadores, sin contar una que otra laptop que uso de vez en vez contra mi voluntad. Puedo tener en cada equipo mi proyecto con toda su historia, trabajar independientemente y luego sincronizar con los demás. Cada PC es un equipo de desarrollo tan igual como los demás.

En tercer lugar, puedo elegir la estructura de mis repositorios, como se organizan jerarquicamente. En mi ciclo de trabajo personal elegí no tener un repositorio central, pero en el trabajo, donde más de una persona puede hacer cambios en un proyecto, usamos un maestro.

Pero la característica matadora de git son definitivamente sus branches. Hacer una rama de un proyecto es tan natural, tan barata, que forma parte integral de la forma de desarrollo en git. No puedo resaltar suficientemente este hecho: git me ha hecho un mejor usuario de los sistemas de versiones.

Como es esto? Dado que en mis experiencias previas, ramificar el proyecto era doloroso, tenía una única rama, donde aplicaba todos los cambios. Si trabajaba en tres aspectos distintos de una aplicación, todos los cambios iban al directorio de trabajo. De esta manera, los commits contenían cambios no relacionados. Hacer un commit era básicamente, hacer un respaldo del proyecto.

Fue usando las ramas de git que obtuve la iluminación: un aspecto, una rama. Aspecto culminado, commit. Apareció un bug que debo atender? Pues creo una nueva rama, corrijo el bug, pruebo y hago el commit y merge o rebase. Regreso a la rama inicial y sigo trabajando con el aspecto original.

Cada commit debe ser un milestone, un hito significativo en el desarrollo del programa "Agregue la caracteristica X", "Corregí el bug Y", "Cambié el algoritmo Z". Y no como antes "Toqué los archivos A, B, C, D y E porque estoy trabajando en X, Y y Z", repetido día tras día..

Ya salió el libro de repoze.bfg

2010-01-18T12:03:00.000-08:00

Ya salió el libro de repoze.bfg, el interesante entorno de desarrollo en python+WSGI. repoze.bfg es un framework minimalista inspirado en zope. Comparativamente ofrece las siguientes ventajas:

Fácil de entender: Al ser un framework pequeño, puede ser entendido con menor esfuerzo.
Familiaridad: Si ya has programado en zope, repoze.bfg es el paraíso: es zope2 bien hecho.
Usa WSGI: Lo cual le permite interoperar más fácilmente con otras aplicaciones (aunque la última versión de zope parece que vendrá por defecto para usar WSGI).
Pagas solo por lo que comes: Viene sin soporte para base de datos, autenticación, autorización o manejo de sesión. Toda esta funcionalidad esta soportada por proyectos independientes.
Rápido: Dado que las aplicaciones desarrolladas en bfg no contienen componentes innecesarios, su velocidad de respuesta aumenta.

Desde luego, bfg también tiene sus inconvenientes respecto a zope. Y como suele suceder, algunas de sus características positivas tienen su lado negativo:

No TTW: Zope2 ganó una inmensa popularidad al permitir el desarrollo de aplicaciones a través del web. bfg es un framework para programadores exclusivamente.
Pocos componentes integrados: Fiel a su idea original de minimalismo, es responsabilidad del programador decidir sobre los componentes básicos de su aplicación. Cada vez. Por cada componente. Incluso en las pruebas más triviales.

En definitiva, repoze.bfg dará que hablar. Este framework tiene el potencial para desarrollar el sucesor de Plone.

Más diversión con tipos algebraicos

2010-01-18T06:18:00.000-08:00

En otra entrada comenté la elegancia de los tipos de datos algebraicos (ADT) y como este simple concepto reemplaza a las enumeraciones, estructuras y uniones de otros lenguajes. Adicionalmente, los ADT ofrecen otra característica interesante: el emparejamiento de patrones (pattern matching).

En principio, los elementos de un ADT solo pueden ser accedidos por medio del emparejamiento de patrones. Veamos un ejemplo con un tipo de datos lista:

data Lista a = Nulo | Cons a (Lista a)

lista1 = Nulo
lista2 = Cons 3 Nulo
lista3 = Cons 7.3 (Cons 4.0 Nulo)

Nota como el tipo de datos Lista es polimórfica (define listas de enteros, reales o cualquier otro tipo) y recursiva (una lista de tipo a esta formada por un valor de tipo a unida a una lista de tipo a).

Los valores de tipo Lista están compuestos, o bien por el valor Nulo, o bien por un par ordenado "marcado" por Cons, cuyo primer elemento es de tipo a y su segundo es de tipo Lista a. Estos dos "marcadores" forman la base para el emparejamiento de patrones. Por ejemplo, para calcular la longitud de una lista:

longitud Nulo = 0
longitud Cons a b = 1 + longitud b

Estas dos lineas combinadas, forman la definición de la función longitud. Utilizamos la primera solamente cuando se invoca longitud con la lista vacia (valor Nulo) y la segunda en los otros casos (valor Cons).

Una ventaja del emparejamiento de patrones, es que podemos ver con claridad cuando nuestras funciones manejan todos los casos posibles. El compilador puede advertirnos cuando obviemos alguno.

Adicionalmente, como dividimos nuestra función longitud en dos expresiones, resulta más fácil de leer. Podemos concentrarnos en las peculiaridades de cada patrón por separado.

Cabe destacar que el emparejamiento de patrones se puede usar también para separar casos de acuerdo a los valores dentro de los ADT, no solo por sus "marcadores". Por ejemplo, la función elem que devuelve el i-simo elemento de una lista:

elem 0 (Cons a b) = a
elem i (Cons a b) = elem (i-1) b

En este caso, solo aplicamos la primera expresión cuando pidamos el elemento cero de una lista.

Diversión con tipos de datos algebraícos

2010-01-14T12:30:00.000-08:00

Los tipos de datos algebraicos o ADT (por sus siglas en inglés: Algebraic Data Types) son una de las características más interesante de los "nuevos" lenguajes funcionales, y por nuevos quiero decir de la época de SML. Lo simpático de los ADTs es que reunen en un solo concepto lo que en otros lenguajes serían enumeraciones, estructuras y uniones.

Por ejemplo, las enumeraciones. Una enumeración es básicamente un conjunto de constantes utilizados para representar los posibles valores de un tipo dado. Para representar los días de la semana en C, utilizaríamos:

enum diasemana {
DOMINGO, LUNES, MARTES, MIERCOLES,
JUEVES, VIERNES, SABADO
};

Solo que en C, los enums son azúcar sintáctica, es una forma abreviada de definir un grupo de constantes. diasemana no es de ninguna forma un tipo de datos, son simplemente enteros.

En Haskell, el código anterior sería:

data Diasemana = Domingo | Lunes | Martes | Miercoles
| Jueves | Viernes | Sabado

la diferencia está en que, Diasemana si es un tipo de datos. Los valores de tipo Diasemana no son equivalentes a los enteros y no pueden mezclarse.

Otro tipo de datos popular son las estructuras, que no son mas que un conjunto ordenado de valores de (posiblemente) diferentes tipos. En C una estructura se define del siguiente modo:

typedef struct student_type {
    char nombre[20];
    char apellido[20];
    int edad; } persona;

en Haskell sería:

data Persona = Persona String String Int

En Haskell, el tipo Persona esta formado por la etiqueta 'Persona' (llamado constructor de datos) y seguido por tres valores: dos strings y un entero.

Finalmente están las uniones. Una unión es una estructura de datos cuyos valores pueden pertenecer a dos o más tipos diferentes. Por ejemplo, en C:

typedef struct {float real, imaginario; } cartesiano;
typedef struct {float modulo, angulo; } polar;
union {
cartesiano c;
polar p;
} complejo;

En Haskell:

data Complejo = Cartesiano Float Float | Polar Float Float

Como se ve, usando solo los ADT se logra lo que en otros lenguajes requiere tres tipos diferentes de estructura de datos. Y no solo eso, sino que el resultado es más compacto.

Otra ventaja de los ADT viene, al menos para mí, del aspecto sicológico. Mientras que en C, fiel a su tradición de eficiencia y cercanía a la "maquina desnuda", estas estructuras de datos definen alineamientos en memoria, los ADTs ofrecen una definición más abstracta. Leer un ADT es leer las estructuras de datos del problema en su propio lenguaje. Leer un enum, union o struct de C, es leer la traducción de las estructuras de datos al lenguaje del computador.

Tipos polimorficos en Haskell

2009-12-30T17:27:00.000-08:00

Una vez pasado el shock inicial, la información sobre los tipos de las expresiones en haskell pueden ser realmente útiles. Si revisas una librería en haskell y ves la firma de las funciones, prácticamente sabrás todo lo que necesitas conocer sobre las mismas.

Este hecho siempre me sorprendió. Ver la firma de una función en C no ofrece la misma cantidad de información, incluso para alguien como yo, más familiarizado con C que con Haskell. Y desde luego, los lenguajes de script no ofrecen ninguna garantía sobre los parametros que reciben sus funciones.

Pero, por que? Como es que la firma de una función en Haskell ofrece tanta información? No entendía la respuesta hasta leer Real World Haskell. Por ejemplo, la siguiente declaración:

qsort :: Ord a => [a] -> [a]

Nos dice que qsort es una función polimorfica que toma una lista de elementos del tipo a y devuelve una lista del mismo tipo. El único dato que conocemos sobre el tipo a es que es de la clase Ord, es decir que sobre él están definidas las comparaciones de igualdad, mayor que, menor que, etc.

Lo interesante del caso, es que cuando digo conocemos, me refiero no solo a las personas que leen el código, sino también a la función. La función qsort no sabe algo sobre a que nosotros ignoremos. Cualquier función definida sobre a distinta de la clase Ord es inaccesible a qsort. Es decir, sea lo que sea que qsort haga, solo puede comparar los elementos de [a]. Y dado que las funciones en Haskell son puras, no tiene acceso a variables externas, por lo que la lista resultante depende solo de la lista de entrada.

Esto reduce enormemente las posibilidades de qsort. Sentido común en la elección del nombre por parte del autor y una linea de documentación nos dirá el resto de lo que necesitamos saber: qsort devuelve una lista con los elementos de su argumento ordenados.

Otro ejemplo es el siguiente:

mistery :: (a -> b) -> [a] -> [b]

El nombre de la función ha sido ofuscado deliberadamente. Para quienes no conocen Haskell, el primer argumento (a -> b) es una función que toma argumentos de tipo a y devuelve elementos del tipo b. De nuevo, como no sabemos absolutamente nada sobre los tipos a y b, mistery no puede usar otra información más que la dada para llevar a cabo su cometido.

Puedes adivinar que hace mistery?

Autenticacion LDAP en zope2

2008-08-05T12:53:00.000-07:00

La autenticación LDAP en zope2 se ha hecho mas fácil con los eggs. Basta con agregar al listado de eggs necesarios en buildout el nombre Products.PloneLDAP.
Este producto depende a su vez de

python-ldap
LDAPUserFolder
LDAPMultiPlugins

todos ellos descargados automáticamente durante el buildout.

Ahora, Centos 4 viene con una versión antigua de LDAP que no es compatible con python-ldap. Para compilar este paquete hay que instalar ldap-2.3 en paralelo con la versión de la distro. Una vez hecho esto hay que bajar y generar una versión local del egg python-ldap, que se enlace las nuevas librerías:

# Bajar solamente el egg
$ easy_install -b downloads/ python-ldap
$ cd downloads/python-ldap

Luego se edita el archivo setup.cfg cambiando las variables library_dirs e include_dirs para que apunten al directorio de librerías e includes de la nueva versión de LDAP. Una vez hecho esto, se genera el egg

$ ./setup.py bdist_egg

Este egg puede luego ser copiado en el directorio egg de la instancia a desarrollar.

Para activar la autenticación LDAP, desde la interface ZMI del zope se visita la carpeta acl_user del sitio plone. En ella se cre un 'Plone LDAP Plugin', digamos con el nombre ldapmaster. Luego todas sus funcionalidades deben ser activadas (site/acl_users/ldapmaster lengüeta "activate"). Finalmente hay que prioritizar el uso de la autenticación ldap, visitando site/acl_users/plugins, seleccionando primero el Plugin Type "Properties Plugins" y poniendo de primero a ldapmaster. Luego se hace lo propio "UserManagement Plugins".

Desarrollo y Despliegue en zope2+Plone3

2008-08-05T12:34:00.000-07:00

A continuación sigue como desarrollar y desplegar un sitio basado en zope 2 y Plone 3 usando egg.

Instalar el entorno virtual

Como siempre comenzamos instalando un entorno virtual para trabajar con comodidad

# con una version previa de easy_install, instalar virtualenv
$ wget http://peak.telecommunity.com/dist/ez_setup.py
$ sudo python2.4 ez_setup
$ sudo easy_install-2.4 virtualenv

# crear el entorno virtual de python
# y comenzar a trabajar en el
$ virtualenv ~/entorno
$ cd ~/entorno
$ source bin/activate

Instalación del Zope 2 y Plone 3

Luego instalamos ZopeSkel, que nos generará un buildout.cfg que se adaptará al tipo de proyecto de zope2 que querramos:

$ easy_install ZopeSkel

Podemos ver que clase de proyectos podemos crear con ZopeSkel del siguiente modo:

$ paster create --list-templates

Luego creamos el proyecto zope2+plone3 propiamente, hacemos el bootstrap y el buildout:

$ paster create -t plone3_buildout myPlone
$ cd myPlone
$ python bootstrap
$ bin/buildout

Posteriormente podremos usar la opción -No en el buildout para que no chequee que cada egg bajado tenga la última versión.

Para arrancar el zope:

$ bin/instance fg

Despliegue

Como ya es costumbre, los productos que deseemos agregar a nuestra instancia se agregan a la variable egg de buildout.cfg y se vuelve a reconstruir el proyecto. Si el producto tiene algún archivo de configuración zcml, este debe ser agregado en la sección zcml.

Los eggs de desarrollo deben ser registrados tanto en eggs, como en la variable develop.

Desarrollo

Para desarrollar un egg, se usa de nuevo paster en el directorio src de la instancia en cuestion:

$ paster create -t plone mi.producto

Como siempre las dependencias de este producto van en su setup.cfg.

Desarrollo y Despliegue en zope

2008-02-21T07:20:00.000-08:00

Siguiendo con los apuntes de zope 3, aquí esta la versión aumentada y corregida de como trabajar con zope. Básicamente se quiere llevar a cabo dos actividades: desarrollo (development) y despliegue (deployment).

Preconfiguración

Antes de desarrollar cualquier aplicación es conveniente tener un entorno sano y reproducible y de preferencia trabajar en un sandbox personal. Ya vimos una opción para crear este entorno virtual usando virtual-python. El sucesor de virtual-python es virtualenv. Esta aplicación funciona mejor que virtual-python en windows y genera un entorno menos polucionado. Además, instala automaticamente easy_install y un script de activación del entorno:

# con una version previa de easy_install, instalar virtualenv
$ wget http://peak.telecommunity.com/dist/ez_setup.py
$ sudo python2.4 ez_setup
$ sudo easy_install-2.4 virtualenv

# crear el entorno virtual de python
# y comenzar a trabajar en el
$ virtualenv ~/entorno
$ cd ~/entorno
$ source bin/activate

# instalar zope-project
$ easy_install zopeproject

# instalar zc.buildout
$ easy_install zc.buildout

El ultimo comando se encarga de fijar algunas variables de entorno, modificar el path para usar el interprete de python del entorno virtual y modificar el prompt para indicar que el entorno esta activo.

Despliegue

El despliegue es la creación y configuración del sitio web propiamente. Para crear el sitio de despliegue (una instancia de zope 3) usamos zopeproject dentro de nuestro entorno virtual previamente activado:

# Crear una instancia
$ zopeproject misitio
{introducir el login del administrador}
{introducir la contraseña del administrador}
{introducir la ruta donde se guardarán los eggs para el proyecto
indicar preferiblemente ~/entorno/lib/python2.4/site-packages/ }

# comenzar a trabajar en el sitio de despliegue
$ cd misitio

El sitio se configura en src/misitio/sonfigure.zcml y sus dependencias para la generación del egg se especifican en setup.py, como de costumbre. El script para el buildout es buildout.cfg.

Como siempre, al agregar o eliminar dependencias, se debe correr bin/buildout.

Desarrollo

El desarrollo es la creación de paquetes para zope. Estos paquetes normalmente no tienen utilidad fuera del zope, sino que son las piezas de lego con las que se construye un sitio. Es conveniente que cada paquete de desarrollo resida en su propio directorio y sus requerimientos sean manejados por zc.buildout. Ahora se creará la estructura mínima de un paquete de desarrollo, siempre en el entorno virtual previamente activado:

# Crear el directorio para el buildout del paquete
$ mkdir mipaquete
$ cd mipaquete
$ buildout init

# Crear la estructura mínima del buildout
$ touch setup.py
$ mkdir -p src/mipaquete
$ touch src/mipaquete/__init__.py

La estructura básica de buildout.cfg es

[buildout]
develop = .
parts = test
eggs-directory = /home/jdinunci/apps/webdev/lib/python2.4/site-packages/
{ruta donde yo guardo los eggs}

[test]
recipe = zc.recipe.testrunner
eggs = mipaquete [test]

La estructura básica de setup.py es

import os
from setuptools import setup, find_packages

def read(*rnames):
return open(os.path.join(os.path.dirname(__file__), *rnames)).read()

setup (
name='mipaquete',
version='0.1',
author = "Jose Dinuncio",
author_email = "micorreo@midominio.org",
description = "Mi paquete",
license = "GPL",
keywords = "zope3",
classifiers = [
'Environment :: Web Environment',
'Intended Audience :: Developers',
'Programming Language :: Python',
'Natural Language :: English',
'Operating System :: OS Independent',
'Topic :: Internet :: WWW/HTTP',
'Framework :: Zope3'],
packages = find_packages('src'),
include_package_data = True,
package_dir = {'':'src'},
# linea de abajo solo necesaria para
# paquetes virtuales
#namespace_packages = ['reduc'],
extras_require = dict(
test = [
'zope.testing',
'zope.app.container [test]',
],
),
install_requires = [
'setuptools',
'zope.interface',
'ZODB3',
'zope.schema',
'zope.app.container',
'zope.app.content',
'zope.dublincore',
],
dependency_links =
['http://download.zope.org/distribution'],
zip_safe = False,
)

En mi caso, mis paquetes usan paquetes virtuales, por lo que suelen llamarse reduc.mipaquete, lo cual implica ligeras modificaciones en el procedimiento

#Crear el directorio para el buildout del paquete
$ mkdir reduc.mipaquete
$ cd reduc.mipaquete
$ buildout init

# Crear la estructura mínima del buildout
$ touch setup.py
$ mkdir -p src/reduc/mipaquete
$ touch src/reduc/mipaquete/__init__.py

# Crear el paquete virtual reduc
$ echo "__import__('pkg_resources').declare_namespace(__name__)"
> src/reduc/__init__.py

En este caso, hay que agregar una configuración a setup.py para el manejo del paquete virtual:

namespace_packages = ['reduc'],

Estos paquetes en desarrollo pueden ser incluidos en el sitio de despliegue con la directiva develop

[buildout]
develop = .
../mipaquete

Al ejecutar bin/buildout, se crea un enlace en develop-egg que permite que los paquetes sean encontrados.

Este es el ciclo depurado para el desarrollo y despliegue en python. Aún puede agregarse mas comodidad al mismo, como agregar al buildout la descarga automatica de paquetes de desarrollo vía svn.

Como obtener paquetes de Zope via svn

2008-02-15T12:07:00.001-08:00

Lo ideal es obtener los paquetes de zope vía easy_install o buildout. Sin embargo, una importante cantidad de paquetes es estado de desarrollo, pero aún estables, se encuentran en un repositorio de subversion.

La primera pregunta es: ¿Como saber que hay en ese repositorio? Una forma fácil es visitando http://svn.zope.org. Supongamos que eliges http://svn.zope.org/z3c.weblog/. Después de ubicar el paquete en cuestión, es solo cosa de descargando usando el svn, mas con la siguiente salvedad: se sustituye el protocolo por svn y se prefija la url con repos/main/:

svn co svn://svn.zope.org/repos/main/z3c.weblog z3c.weblog

Una vez hecho esto, se debe generar el entorno para el buildout y ejecutar el buildout propiamente:

# bootstrap
# bin/buildout

O, si ya se dispone de un buildout, simplemente invocarlo.

Desarrollando con zc.buildout

2008-02-01T16:16:00.000-08:00

Siguiendo con el desvío tomado en Huevos y Constructores, abordaremos el desarrollo de paquetes en python usando zc.buildout. La instancia de zope que creamos con zopeproject es un proyecto manejado por buildout, por lo que es de suma importancia entender como funciona este de manera aislada. Para ello crearemos un paquete en python con una implementación de ejemplo.

Por que usar buildout? Dado que queremos hacer fácilmente instalable nuestro paquete por terceras personas, requerimos algún método para empaquetarlo y distribuirlo. Podríamos usar distutil, pero durante el desarrollo con cada cambio hecho al código deberiamos generar la distribución e instalarla antes de hacer una prueba. Adicionalmente, para hacer la instalación se requiere permisología de root.

Otras ventajas de builtout sobre distutils es que este usa setuptools, por lo que podemos resolver los problemas de dependencias y versiones con los que se enfrentaría quien tratara de instalar el paquete. buildout se ocupa además de preconfigurar el paquete antes de hacer la instalación o pruebas.

Para instalar zc.buildout se requiere setuptools y se recomienda virtual-python (veáse Instalando Zope 3).

Para procesar un paquete o aplicación con buildout se requiere un archivo buildout.cfg que defina el entorno que el paquete necesita:

[buildout]
develop=.
...

La estructura del archivo buildout.cfg es una serie de secciones cuyo nombre aparece entre corchetes, seguida por una serie de pares clave=valor que definen la sección. [buildout] es la sección principal y la única requerida.

buildout.cfg define una serie de partes o elementos necesarios para que la aplicación funcione. Cada parte se define en una sección diferente. Cada parte es procesada por un recipe (un programa en python para instalar y actualizar la parte). Las demas lineas de una sección sirver para configurar el recipe. Hay una gran variedad de recipes para distintas funciones, como descargar eggs, compilar aplicaciones, correr la batería de pruebas de un paquete,e tc. En caso de necesidad el desarrollador puede crear sus propios recipes.

Desarrollando un paquete con buildout

Comenzamos desarrollando un paquete normal en python

# mkdir blah
# cd blah
# mkdir src {aquí va el código fuente de los paqutes a desarrollar}
# mkdir src/blah
# ... {se agregan los módulos al paquete blah}

Este paquete será distribuido con setuptools, por lo que debemos crear un archivo blah/setup.py que defina su distribución:

# blah/setup.py
from setuptools import setup, find_packages
setup(name='blah', version='0.1',
packages=find_packages("src"),
package_dir={"": "src"},
# Notese que los requisitos del paquete son indicados
# aquí para que setuptools pueda generar
# correctamente su egg
install_requires=[ 'zope.tal' ], )

Hasta este punto tenemos un paquete convencional de python, listo para ser distribuído via setuptools. Ahora hay que convertir el directorio de trabajo en un directorio manejado por buildout.

Ahora, se define el archivo buildout.cfg que determinará como generar la aplicación

[buildout]
develop=.
parts=me

[me] recipe=zc.recipe.egg
eggs=zope.tal

Este archivo define una parte llamada 'me', la cual para ser construida requiere el recipe encargado de descargar eggs. El único egg a descargar será zope.tal.

Pero aún falta en manejar este proyecto a traves de buildout. Para crear la infraestructura necesaria, hay que hacer un bootstrap. Este procedimiento se realiza una única vez en la vida del proyecto:

# ruta-hacia-buildout/buildout bootstrap

(Desde luego, buildout debe estar instalado, cosa fácil gracias a easy_install).

buildout creará un directorio bin donde instalará su ejecutable y cualquier otro requerido por las dependencias. Creará además un directorio eggs donde instalará los eggs necesarios por esta aplicación, un directorio develop-eggs donde creará referencia a los eggs que esta aplicación defina y un directorio parts, para ser utilizado por las partes del archivo de configuración.

Ya con toda la infraestructura en su lugar, para asegurar que la aplicación tenga todos sus requerimientos instalados basta con ejecutar

# buildout

Con cada cambio en las dependencias es necesario re-ejecutar el comando, para que satisfaga las nuevas necesidades de la aplicación.

Jugando con las partes y los recipes se puede automatizar el proceso de instalación de las dependencias de la aplicación. Otras funciones determinan si se descargará la versión mas nueva de un paquete o una en especifico.

Se puede generar la distribución de los paquetes por medio de setuptools o por medio de buildout. En el último caso, los comandos son:

# bin/buildout setup . sdist {distribución fuente}
# bin/buildout setup . bdist {binarios}
# bin/buildout setup . bdist_egg {bnarios en eggs}

La fuente autoritativa de zc.buildout se encuentra en http://pypi.python.org/pypi/zc.buildout

Huevos y Constructores

2008-02-01T11:38:00.000-08:00

Antes de proseguir con el desarrollo en zope es conveniente tomar un desvío hacia dos tecnologías usadas por zope que pueden no ser conocidas por los desarrolladores en python: los eggs y buildout.

Los eggs son una forma conveniente de distribuir paquetes de python. Pueden pensarse como el equivalente a los .jar de java, solo que con mayor riqueza. Los eggs son una extensión al mecanismo tradicional de distribución de paquetes en python, ofrecido por distutils.

distutils es la herramienta incorporada en python para la compilación e instalación de paquetes. Normalmente el usuario descarga un archivo .tgz con la fuente del paquete, lo descomprime y ejecuta el archivo setup.py que este contiene. setup.py invoca a distutils que compila (de ser necesario) e instala el paquete en un lugar donde pueda ser encontrado por python.

Los eggs mejoran este proceso. Son paquetes ya compilados, por lo que no requieren herramientas de desarrollo adicionales (compiladores, etc). Pueden estar comprimidos, siendo mas fácilmente manipulables. Además, ofrecen una metadata mas rica, lo cual permite la detección de dependencias.

Esta última característica es lo que permite usar eggs para construir un repositorio de aplicaciones con instalación simplificada. El programa easy_install.py se aprovecha estas características para permitir una instalación de las aplicaciones y sus dependencias con una simple instrucción.

El crear un egg es tan simple como crear un paquete con distutils. Solo se necesita tener instalado el paquete setuptools (el cual es en si mismo un egg que puede ser instalado automáticamente por easy_install). Si el egg va a ser distribuido empaquetado como un zip, entonces debe seguirse unas convenciones adicionales.

La otra tecnología es buildout. El término en general se refiere a todo lo necesario para la construcción e implementación de una aplicación. Cuando un desarrollador esta trabajando en una aplicación con muchas dependencias, necesita herramientas para automatizar su configuración y seguir las versiones de cada paquete usado. La gente de zope desarrolló el paquete zc.buildout con esta finalidad.

zc.buildout permite crear entornos para el desarrollo que sean fácilmente repetibles. De esta manera, el desarrollador podrá trabajar con frameworks complejos como zope y trasladar su trabajo a otro equipo. El resultado final de zc.buildout es un egg con la información exacta de todas las dependencias, versiones y todos sus procesos de configuración. Al instalar este egg en un tercer equipo se obtendrá una copia exacta del entorno en el equipo original.

El ingrediente final en la entrada anterior fue el paquete zopeproject. Este paquete instala un comando del mismo nombre que genera un buildout preconfigurado para iniciar un proyecto con zope.

En entradas posteriores trataré el uso de los eggs y de zc.buildout en desarrollos de python independientes de zope para mostrar su utilidad general. Esto permitirá comprender de forma mas fácil que su uso en zope es conveniente mas dispensable.

Instalando Zope 3

2008-02-01T06:18:00.000-08:00

La presente explicación aplica para usuarios de Linux y otras formas de Unix.

La mas reciente versión de Zope es la 3.4.0Beta. La serie 3.4 es la primera en migrar hacia la distribución en eggs. Esto hace que su proceso de instalación sea diferente al tradicional descomprimir-configurar-compilar-instalar. Los eggs son paquetes de python con sus dependencias indicadas y una infraestructura (easy_install) para obtenerlos e instalarlos automáticamente.

Otro punto a considerar es que zope recomienda el python 2.4 mas su paquete de desarrollo, los cuales podría no ser los instalados en el sistema.

Para trabajar con mayor comodidad y seguridad con zope es mejor hacerlo como un usuario normal y no hacer una instalación como root en las rutas por defecto. Para ello es recomendable crear un entorno virtual para python. Baja virtual-python.py y ejecutalo:

# python2.4 bin/virtual-python.py --prefix=~/zope3/

Esto creará una carpeta zope3 en tu directorio home que contendrá una copia ligera del python2.4, sus archivos include y sus librerías. Aquí podrás instalar cualquier aplicación o paquete hecho en python sin tener necesidad de privilegios de administración.

El siguiente paso es instalar easy_install, la aplicación que maneja los eggs y permite instalar paquetes de python de manera automatica. Baja ez_setup.py y ejecutalo:

# ~/zope3/bin/python bin/ez_setup.py

Hasta este punto no has hecho nada que sea especifico de zope. Solo tienes un entorno propio de python, con soporte para instalación de eggs. Eso esta por cambiar. Con la magia de easy_install instalaremos un único paquete que te permitirá crear instancias de zope y bajará todas las librerías necesarias:

# ~/zope/bin/easy_install zopeproject

Es en este punto que podemos crear nuestra primera instancia de zope3, llamemosla webdev:

# ~/zope/bin/zopeproject webdev

zopeproject preguntará por un login y contraseña para el administrador de la instancia y por el lugar en el cual descargará los eggs del zope. Responde a esta pregunta con ~/zope/lib/python2.4 /site-packages. A continuación zopeproject bajará zc.buildout que es un paquete encargado de construir aplicaciones, descargando automáticamente sus dependencias. Si es la primera vez que ejecutas zopeproject preparate a esperar unos buenos minutos mientras descarga todas las librerías que conforman zope. Invocaciones posteriores serán mucho mas rapidas mientras sigas indicando la misma ruta de descarga de los eggs.

Al finalizar el proceso tendras dentro de zope una carpeta webdev. Esta carpeta contiene tu instancia zope. Para iniciar tu instancia puedes ejecutar

# ~/zope/webdev/bin/webdev-ctl fg

y puedes ver a la aplicación corriendo en http://localhost:8080

Las fuentes para esta entrada están aquí y aquí, solo que de forma menos digerida.

En este punto solo queda comenzar a desarrollar tu propia aplicación en zope y un poco de conocimiento de zc.buildout para el momento final en que empaquetaras tu aplicación.

zope 2 y zope 3

2008-02-01T06:06:00.000-08:00

La nueva versión de Zope es Zope 3. Esta es una reescritura desde cero de su anterior y también magnifico producto Zope 2. Zope 2 introdujo conceptos interesantes como el desarrollo de aplicaciones a traves del web, almacenar los componentes en una base de datos orientada a objetos y permisología basada en roles.

Sin embargo, extender Zope 2 no era fácil. Adicionalmente conforme la aplicación fue evolucionando, es código se volvió mas y mas desordenado. La aplicación había sobrepasado su diseño original.

Luego se creó el concepto de arquetipos. Desarrollar componentes con arquetipos era una tarea casi trivial: se indicaban los campos que definían a los objetos o componentes por una parte y las funciones que los manipulaban por la otra. La información de los campos era usada para generar las páginas web automáticamente y solo bastaba hacer el enlace con el funciones.

Ese fue el detonante para Zope 3. Si desarrollar una aplicación dentro de Zope era mucho mas fácil usando arquetipos, por que no desarrollar el Zope mismo bajo este concepto? Los arquetipos se convirtieron en interfaces, componentes, adaptadores y utilidades y una aplicación casi monolítica se convirtió en un archipielago de pequeños y simples componentes interactuando entre si.

Desarrollo web con zope

2008-02-01T05:47:00.000-08:00

A principios de este año retomé un viejo amor no correspondido con Zope. Zope es un servidor de aplicaciones con favoritismo hacia el web escrito casi totalmente en python.

Zope ofrece un framework para el manejo de contenido a través del web. Es como un lego que permite armar pieza por pieza una aplicación web. Para quienes gustan de los buzzwords es un CMF con una base de datos transaccional orientada a objetos y con capacidades de diseño a través del web. Que hace a zope atractivo? Un diseño elegante con separación de responsabilidades. Zope mantiene religiosamente separados código y html.

Pero su influencia va mas allá de si mismo. El corazón del Zope, el ZCA (Zope Component Architecture) es usado por terceras partes como Creative Commons Publisher, Gaphor o Launchpad, aplicaciones estas que no tienen que ver con el web. Zope ha sido un motor en el desarrollo de python hasta el punto que se ha llegado a decir que donde Zope guia, python le sigue.

Desde luego, Zope no es perfecto. Al ser un framework, esto le impone al desarrollador el conocer la arquitectura del mismo para poder interactuar con él. Esto significa un costo de entrada pronunciado. Luego de unos intentos en falso, gracias a Web Component Development with Zope 3, he comenzado a cosechar mis primeros resultados sobre los que comentaré en futuras notas.

Sobre Monadas, monoides y afines

2007-11-23T06:16:00.000-08:00

Brian Beckman ofrece un vídeo orientado a los programadores donde explica que es una monada:

http://channel9.msdn.com/ShowPost.aspx?PostID=358968#358968

Otra serie de vídeos interesantes sobre el tópico, aunque mas orientados hacia la parte matemática pueden verse en el canal de YouTube "The Catsters".

Como no aprender sobre recursividad

2007-07-31T05:53:00.000-07:00

A mediados de los 80s descubrí el fascinante mundo de la recursión gracias al lenguaje LOGO. LOGO es un lipsoide con excelente soporte gráfico, por lo que nada mas natural que combinar gráficos y recursión para generar fractales como el copo de nieve. Desgraciadamente la fuente de la que aprendí no era muy buena es ese tópico en particular. Los ingredientes en una función recursiva son:

Un segmento de código que evite la recursión infinita
Un segmento de código que haga el trabajo
Un segmento de código que reinvoque la función

Con esta receta me encaminé a implementar mis propias funciones recursivas como la curva de Hilbert. Pasar de la teoría a la práctica es bastante difícil, sobre todo cuando no se tiene computador, mucho menos una versión de LOGO a la mano. Así que tenía que hacer los algoritmos en papel, hacer una corrida en frío, ejecutándolos con lápiz y escuadra. Pero la mayor dificultad estaba en dar con el algoritmo recursivo correcto, básicamente por ensayo y error.

Cuando pasé de los gráficos a las estructuras de datos, la vieja receta aprendida se mostró igualmente ineficiente. La recursión era para mí un arte y no una ciencia. Eso hasta que fui enseñado correctamente, gracias a un libro de Paul Graham.

La belleza de las funciones recursivas se muestra en todo su esplendor con las estructuras de datos recursivas. Cuando se define una estructura de datos recursiva se da una receta para crear nuevos valores en base a valores previos. Por ejemplo, para definir una lista en Haskell:

data Lista a = Nulo | Cons a (Lista a)

Esta expresión dice que una lista de un tipo "a" es o bien el elemento especial "Nulo" o la unión ("Cons") de un elemento de tipo "a" con una lista de tipo "a" (desde luego, Haskell ya tiene definido su propio tipo para las listas, con una notación mas suscinta. Sin embargo, para fines didácticos esta definición es mas conveniente).

Aquí es donde se evidencia el poder de las funciones recursivas. Para definir una función recursiva sobre el tipo de datos Lista a, solo hay que considerar que se debe hacer para cada una de las partes que conforman su definición. Donde aparezca "Lista a" cabe esperarse que haya un llamado recursivo. Por ejemplo, para obtener la longitud de una lista:

longitud Nulo = 0
longitud Cons a b = 1 + longitud b

Es esta simetría entre la forma de la estructura de datos y la función recursiva lo que facilita el trabajo al programador.

Haskell como herramienta para los matematicos

2007-07-02T08:48:00.000-07:00

Una interesante página en el sitio de haskell resume las ventajas que ofrece un lenguaje funcional fuertemente tipificado para el aprendizaje, estudio y juego con la matemática.

Otros lenguajes, como Qi, pueden ofrecer estas mismas ventajas con el añadido de ser derivados de Lisp y por lo tanto, conceptualmente mas austeros.

Python 3000

2007-06-20T08:09:00.000-07:00

Recientemente, Guido van Rossum concretó mas detalles sobre el futuro Python 3000:

http://www.artima.com/weblogs/viewpost.jsp?thread=208549

Es de particular relevancia:

El Viejo sistema de Clases desaparecerá.
Mayor coherencia en la librería estándar.
La compatibilidad con versiones previas no es un objetivo.

Python ha seguido una evolución interesante, pasando a ser un "verdadero" lenguaje orientado a objetos al tiempo que ha visto incrementado el rango de funcionalidades que ofrece "out of the box". Sin embargo, su inicio modesto y la colaboración de centenares de personas en la elaboración de las librerías, de alguna forma ha causado que el lenguaje haya dejado de ser tan simple y elegante como lo era en un principio.

La mayor (tal vez la única?) envidia que sienten los pythonistas ante, digamos, Java, es que sus librerías lucen estandarizadas. Esto en el sentido que todas cumplen con una convención de nombres y denominaciones que facilita su aprendizaje (podemos criticar todo lo que queramos el diseño, sentido o necesidad de muchas librerías de Java, pero al menos son consistentes en sus APIs).

Esta es una excelente oportunidad para que este magnifico lenguaje, que ya ha sentido las tensiones entre el crecimiento y la elegancia, recobre la consistencia interna que a tantos de nosotros enamoró.

La Perfecta Maquina Virtual

2007-05-28T07:09:00.000-07:00

La idea de una maquina virtual no es nueva. Antes que C#, antes que Java, incluso antes que el microprocesador, ya habían maquinas virtuales operando en los "mini" computadores de la época.

De hecho, el término "maquina virtual" se ha ampliado haciéndose cada vez mas difuso. Al principio, las maquinas virtuales implicaban un soporte de hardware que permitía que varios sistemas operativos corrieran independientemente en un equipo.

Las maquinas virtuales al estilo Java y .Net son las que han traído el concepto al foco de atención de la mayoría de los programadores en los tiempos recientes. Este tipo de maquinas virtuales son "computadores implementados en software" que corren sobre el sistema operativo anfitrión y que se usan para ejecutar las aplicaciones.

Otro enfoque es el del sistema operativo. La idea es que, dado que la principal función del sistema operativo es hacer una abstracción del hardware sobre el que este corre, el propio sistema operativo constituye una maquina virtual. De hecho, muchas veces los núcleos de los sistemas operativos son llamados maquinas virtuales.

Y es aquí donde viene la atractiva idea de Lina. Si una maquina virtual puede ser tanto una aplicación como el núcleo de un sistema operativo, por que no aprovechar uno de los sistemas operativos libres mas populares y exitosos del mundo? Ese es el concepto tras OpenLina: correr el núcleo de linux sobre windows, OSX y el propio Linux. Las librerías de soporte mapearan llamadas estándar de lina a servicios del sistema anfitrión. Las aplicaciones de lina podrán correr así en cualquier plataforma. Si bien esto es poco mas o menos lo que hace Java, por ejemplo, la novedad esta en que la maquina virtual de lina (el núcleo de linux) es una pieza de software muy madura y excelentemente soportada y con librerías estandarizadas.

Diversión con Monadas

2007-05-07T12:31:00.000-07:00

Para el programdor en Haskell, pocos conceptos son tan dificiles de aprehender como las monadas. Existen infinidad de tutoriales sobre el tema y al parecer estos no son suficientes. Su origen en la teoría de tipos y su nombre atemorizante intimidan, al punto que uno de los pilares de Haskell ha comentado que tal vez deban rebaustizarse como las monadas con el titulo de las "cosas difusas y calidas" (warm fuzzy things) con el objeto de hacerlas mas amistosas.

Hay dos elementos que contribuyen a la confusión del recien llegado con las monadas. El primero tiene que ver con su uso especifico para contener los efectos colaterales, es decir la programación no funcional, en particular el sistema de entrada/salida. Esto deja al recien iniciado preguntandose si monadas es sinonimo de I/O.

El segundo elemento que contribuye a la confusión inicial es un menejo del tema desligado de las implicaciones practicas. En Haskell una monada es una clase. Para convertir un tipo dado en una monada hay que implementar las funciones definidas en dicha clase y dichas funciones deben cumplir ciertas de reglas. Un importante conjunto de librerías de Haskell implementan monadas. Todo eso muy bien, pero ¿por que dichas librerías son implementadas así y no otras? ¿Cuando debería un programador desarrollar sus propias monadas?¿Como implemento mi monada?¿Como garantizar que las monadas creadas cumplan con dichas reglas?¿Que pasa si no cumplen con las mismas? Esas son preguntas mas interesantes.

La mejor forma de aprender el significado de las monadas es entender cuando tú como programador deberias implementar una solución basada en monadas. Una vez entendido esto, resulta fácil entender las librerías y saber por que el sistema de I/O de Haskell y el código que produce efectos colaterales es implementado de esa forma. En ese sentido, no hay mejor tutorial que "Tu pudiste haber inventado las monadas! (y tal vez ya lo hiciste)" por sigfpe.

La idea de sigfpe es simple abordar las monadas desde un punto de vista utilitario. ¿Para que sirven?. ¿Que problema resuelven?. Él hace un trabajo insuperable, por lo que aquí me limitare a reexpresar la conclusión a la que llega:

Desde el punto de vista del programador, las monadas son la extensión natural a los functores. Como ya vimos los functores son una forma de mapear las funciones que operan sobre tipos "simples" a funciones que operan sobre tipos "compuestos".
Lo que las monadas permiten es componer funciones cuyo dominio es el tipo "simple" y su rango es el tipo "compuesto" entre si. Sencillo, no?

Eso es todo lo que significa el operador "bind" de la clase Monad:

(>>=) :: m a -> (a -> m b) -> m b

El programador ha desarrollado bastante tiempo creando funciones que toman argumentos simples y devuelven argumentos complejos, como por ejemplo a -> m b, b -> m c y ahora desea combinar esas funciones. Pero como la primera devuelve un valor compuesto (m b) y la segunda requiere un valor simple (b), necesita alguna forma de "sacar" (b) de (m b) para introducirla en la segunda función. Eso responde todas las preguntas planteadas sobre las monadas, como se vera a continuación.

Cuando debería un programdor desarrollar sus propias monadas?

Cuando desarrolla su propio tipo "compuesto" y necesita componer funciones del tipo "simple" hacia el tipo "compuesto".

Por que ciertas librerías en Haskell estan implementadas como monadas?

Porque dichas librerías implican tipos "compuestos" y funciones que devuelven este tipo de valores y que es útil componer. Así por ejemplo, la librería IO no trabaja diretamente sobre enteros, reales y caracteres sino sobre tipos derivados {tipos que contienen de forma oculta el estado del universo y que podriamos sentirnos tentados a representar como (entero, mundo), (real, mundo) y (caracter, mundo)}.
Una revision a las librerías que son implementadas como monadas arroja esa constante: tipos compuestos involucrados (a veces habilmente ocultos) y funciones sobre ellos que es conveniente componer.

¿Como implemento mi monada?

Al crear el tipo compuesto; al necesitar componer las fuciones el programador ya sabe como implementar la monada. Sin un ejemplo en esta pagina puede sonar bastante abstracto, pero el tutorial de sigfpe ofrece suficientes ejemplos y ejercicios. Basta decir que la naturaleza misma del tipo compuesto y su uso deseado sirve para definir la monada.

¿Como garantizar que las monadas creadas cumplan con las reglas de las monadas?

Uno de los temores del programador recien iniciado a las monadas y que las aprendió por su definición es temer que su implementación de una monada sea invalida. Esto ocurre cuando se trata de imponer el concepto no bien internalizado de una monada sobre un problema. En el momento en que el programador se da cuenta que implementar una monada es implementar la composicion entre funciones de una forma que tenga sentido para el tipo "compuesto", el temor a implementar incorrectamente una monada desaparece.

¿Pero que pasa si mi monada no cumplen con la leyes?

Esa situación es perfectamente posible y tiene un término técnico que la describe, se le denomina bug. una monada que no cumple con sus leyes es, desde luego, inútil. Pero ello significa simplemente que tú como progrmador cometiste un error en la función que crea un valor "compuesto" a partir de un valor "simple", o que la función de composición no esta correctamente definida. Es un bug como cualquier otro, no hay nada místico en ello.

Sobre los Tipos de Datos Algebraicos y la Abstracción

2007-04-11T07:17:00.000-07:00

Desde el comienzo de la computación electrónica ha habido dos campos en el desarrollo de los lenguajes de programación: los que buscan velocidad y los que buscan expresividad. Los primeros se caracterizan por su poco nivel de abstracción. Las características del equipo donde corren son visibles al programador y este, en su trabajo, debe preocuparse por ellos. El ejemplo clásico es el lenguaje C.

El otro tipo de lenguajes, representados por scheme, lisp, haskell y varios lenguajes de scripts, busca la abstracción. El programador debe preocuparse por expresar el problema en los términos mas cercanos al mismo, sin hacer consideraciones o concesiones a la plataforma.

Para alcanzar tan loable objetivo, pocas herramientas son tan útiles como los Tipos de Datos Algebraicos o ADT, por sus siglas en ingles. La idea de los tipos algebraicos es permitirle al programador definir nuevos valores primitivos y a partir de ellos generar nuevos tipos, combinando los valores, bien sea por medio de la unión de conjuntos o su producto.

Un ejemplo permitirá mostrar el valor de los ADT como medio de abstracción, comparando la solución a un problema en C, Haskell y, por diversion, BASIC.

Si bien BASIC sería bajo los estándares actuales un lenguaje de script, y por lo tanto mas abstracto, me referiré en cambio a las primeras versiones de BASIC, antes de Visual Basic o Turbo BASIC; un lenguaje mas cercano a la idea original, para correr en una maquina con menores recursos. Hablemos del BASIC que corría en un equipo como el Commode 64 o el Sinclair ZX Spectrum.

El problema en cuestión es extremadamente simple: representar un mazo de cartas. Cada carta tiene una pinta que puede ser corazón, pica, diamante o trébol y un "numero" que puede ser los números del 2 al 10, las letras "A", "J", "Q" o "K".

En un lenguaje de programación contemporáneo una carta podría ser representada por un registro o un objeto, de acuerdo al paradigma para el cual el lenguaje este optimizado. En el BASIC que tengo en mente, conceptos como registros y objetos son términos muy avanzados. Como se representa un registro en tal BASIC? Fácil: con variables separadas, siendo responsabilidad del programador mantener en su cabeza la asociación entre tales variables. Así la J de trébol podría representarse como:

10 c1p = 4
20 c1n = 11

El 10 y el 20 son los "números de linea". Cada linea del programa debía tener un numero, el cual era usado como medio para acceder a la misma por los primitivos editores que era menester hacer caber en 8KB de memoria o menos.

Sin embargo esta solución es suboptima. Los números mágicos 4 y 11 son una mala señal. En un lenguaje cuyos únicos tipos son los números reales, los arreglos y las cadenas de caracteres es poco lo que se puede hacer, mas allá de representar las pintas y los "numeros" especiales de las cartas con constantes:

10 c1p = 4
20 c1n = 11
10 CPCORAZON = 0
20 CPPICA = 1
30 CPDIAMANTE = 2
40 CPTREBOL = 3
50 CNA = 1
60 CNJ = 11
70 CNQ = 12
80 CNK = 13
...
500 c1p = CPTREBOL
510 c1n = CNJ

Mencione que la mayoría de los BASIC de esa época eran insensibles a las mayúsculas y minúsculas y que tenían un limite en el tamaño del nombre de las variables?

Ahora, para representar a un mazo de cartas, se necesita un arreglo... mejor dicho dos arreglos. De nuevo, hay que mantener separados las pintas de los números y hacer la asociación mental durante la escritura del programa.

590 rem el comando dim crea un arreglo
600 dim mp(52)
610 dim mn(52)

Para inicializar los arreglos, es útil el hecho de que la representación elegida para las pintas y los "números" son ambas numéricas, y como cada carta es diferente puede establecerse una correspondencia entre los naturales y estas:

700 for x = 0 to 51
705 rem cada 13 cartas cambia la pinta
710 mp(x) = int(x/13)
720 mn(x) = (x mod 13) + 1
730 next x

La solución en BASIC es engorrosa. Parte del problema no esta reflejado directamente en el programa, sino que debe ser sobreentendido, en particular la necesidad de usar arreglos diferentes para una sola entidad, o la representación numérica de entes como la pinta y el "numero" de la carta.

La solución en C es mas avanzada. El C nos ofrece ENUMs que es una forma básica de representar tipos de datos no númericos.

enum pinta {Corazon, Pica, Diamante, Trebol};
enum numero {As, Dos, Tres, Cuatro, Cinco,
Seis, Siete, Ocho, Nueve, Diez,
Jack, Queen, King};

Tambien permite definir estructuras (registros), con lo que se solventa el problema de mas de una variable para un solo ente.

struct { enum pinta pinta;
enum numero numero; } carta;

Una solución mucho mas elegante que la elaborada en BASIC, pero no mucho mas abstracta. Un enum es poco mas o menos que un conjunto de constantes con valores enteros creados automáticamente. En nuestro caso, Corazon es solo una forma de decir 0 y Trebol es 3. De hecho, una variable declarada como enum puede contener cualquier valor entero, mas allá de los cuatro valores permitidos.

Una estructura tiene también una representación de bajo nivel que puede ser accedida por el programador. Para un compilador especifico el "numero" de una carta puede estar almacenado cuatro bytes después de su pinta, por lo que obteniendo la dirección de esta, se puede modificar aquella.

En resumen, se ha ganado algo de abstracción, pero solo en la forma. Si el programador se compromete a no efectuar ninguna operación sobre las estructuras básicas subyacentes, es probable que todo le salga bien...

Veamos ahora la solución en Haskell, el único de los lenguajes mencionados en este articulo que tiene ADT. Primero creamos un nuevo tipo de datos algebraico para la pinta y el "numero" de la carta:

data Pinta = Corazon | Pica | Diamante | Trebol
data Numero = As | Dos | Tres | Cuatro | Cinco
| Seis | Siete | Ocho | Nueve | Diez
| Jack | Queen | King

Y luego creamos otro tipo algebraico con el producto cartesiano de los dos antes definidos:

data Carta = Carta Numero Pinta

Igual a lo expresado en C? Solo superficialmente. Pinta es un nuevo tipo de datos, no un entero. Su representación interna por el compilador es desconocida. Tal vez sería una buena adivinanza suponer que es representado por un entero de un byte. Pero adivinar sería fútil, ya que el saberlo es irrelevante: la única forma de operar sobre un tipo algebraico es con las operaciones explícitamente definidas por el programador. Lo mismo ocurre con el tipo Carta. Si, de seguro durante la compilación nuestro tipo algebraico se convierte en una estructura equivalente a la del C, pero eso es un asunto entre el compilador y la CPU. Para el programador es un ítem único e indivisible.

También esta el aspecto sicológico. En el caso del C el programador esta definiendo un layout de memoria y unas constantes enteras. En Haskell, el programador esta declarando que una carta es representada por un "numero" y una pinta, y que la pinta puede tomar solo estos valores y que un "numero" en este contexto son tales otros.

Este aspecto sicológico es un subproducto de la mayor capacidad de abstracción del lenguaje, y es una de las mas importantes contribuciones para el programador.

Saber decir "No"

2007-03-16T06:05:00.000-07:00

Que hace a un lenguaje diferente de otro? En el caso particular de los lenguajes de script imperativos, es cada vez mas amplia la lista de características compartidas: las estructuras de control "estructuradas", las listas, los diccionarios, las funciones como ciudadanos de primera clase...

Y sin embargo, programar en Ruby sigue siendo diferente a programar en TCL; programar en python tiene un sabor distinto a hacerlo en perl. Entonces, cual es la diferencia? La raíz en la diferenciación de los lenguajes esta en su filosofía, la idea que guía a sus desarrolladores a decidir que características entran en el lenguaje y como lo hacen.

Paul Graham tiene un articulo interesante al respecto en donde lista los lenguajes de acuerdo al problema que pretenden resolver. Esta puede ser una primera guía sobre la filosofía de los desarrolladores.

En el caso de python, su mantra esta explicado en el 'import this' (pruebe importar el modulo this en un interprete en python). Los dos preceptos fundamentales en el python son la legibilidad y la simplicidad. El lenguaje procura no interponerse en el camino del programador, de manera que el pueda expresar de forma clara sus intensiones. Para ello es fundamental ser sucinto en los conceptos. Por esta razon el punto 13 del zen de python es: "Debe haber una forma obvia de hacerlo --y preferiblemente solo una".

Así, lo que distingue al python es que su filtro para nuevas caracteristicas es: ayuda la característica a expresar los algoritmos de forma mas clara? mas concisa? menos redundante? Y ello lo ha logrado -sorprendentemente, para algunos- sabiendo decir "no" a ciertas funcionalidades.

Después de todo, expresividad no es poder decir una cosa de mil maneras distintas; es poder decir cualquier cosa, al menos de una manera.

Diversión con functores

2007-02-08T06:25:00.000-08:00

Despues de programar durante algún tiempo, es común encontrarse repitiendo una y otra vez las mismas soluciones, con ligeras variantes. Es esta ha originado todas las innovaciones en el campo, desde la creación de subrutinas hasta los macros.

Una de estas situaciones se presenta cuando se tiene una funcion que convierte datos del tipo A al tipo B y se la desea transformar en una nueva función que opere sobre un tipo derivado de A para convertirlo en un tipo derivado (en una manera equivalente) de B.

La definición de functores es:

Dadas dos categorías C y D, un functor F de C a D es un mapeo que:

Asocia a cada elemento X de C un elemento F(X) de D
Asocia a cada funcion f: X -> Y de C otra F(f): F(X) -> F(Y)

De manera tal que

F(IDx) = ID(Fx)
F(f o g) = F(f) o F(g)

Desde el punto de vista programatico, un functor esta formado por dos funciones: la primera convierte tipos "simple" en tipos "complejos" y la segunda convierte funciones cuyo dominio y rango son tipos "simples" a otras funciones, en algún sentido equivalentes, pero cuyo dominio y rango son tipos "complejos". De esta forma, si has programado una función que convierta manzanas en compotas, aplicando un functor tienes automaticamente una funcion que convierta cajas de manzanas en cajas de compotas o camiones de manzanas en camiones de compotas.

Un ejemplo practico es el functor cuyo rango son las listas. La categoría C sería el conjunto de todos los tipos que son susceptibles de ser contenidos dentro de listas (enteros, reales, complejos, caracteres, incluso listas, ...). La categoría D esta formada por las listas de los tipos en la categoría C (listas de enteros, listas de reales, listas de complejos, listas de caracteres, listas de listas, ...).

Para definir dicho functor, necesitamos una función que convierta elementos de los tipos en C a elementos en los tipos en D. En este caso la función es simple, solo necesita crear una lista con ese unico elemeto. El otro elemento necesario es una función que convierta una funcion del tipo X -> Y en una funcion del tipo [X] -> [Y]. En Haskell esta función se denomina map, y su definición es:

map [] f = []
map x:xs = (f x) : (map xs)

Eso es todo. Al definir map, se ha solucionado de una vez por todas el problema de mapear funciones hacia la categoría de las listas. Desde luego, cada categoría distinta requiere un mapeo distinto. Normalmente la primera parte del mapeo es el constructor de tipos y la segunda recibe como nombre genérico "fmap".

La belleza de la programación funcional en lenguajes como Haskell es la simplicidad con la que se implementan conceptos como los functores. Lengajes imperativos como Java poseen todo lo necesario para crear functores: funciones que mapean tipos a otros tipos (generics en el lenguaje de java), funciones como ciudadanos de primera clase (en java, clases) e interfaces. Sin embargo, su implementación es mucho mas verbosa.

El olor de la sangre

2007-02-07T06:46:00.000-08:00

Recientemente he estado implementando un protocolo de comunicación para un dispositivo embebido. Dada la naturaleza de la plataforma, el lenguaje de programación elegido fue C.

Así que comencé a programar: a preocuparme por el manejo de memoria, a acceder a los elementos de un arreglo a través de índices que yo mismo me veía obligado a incrementar, a codificar mis estructuras de datos utilizando números en vez tipos de datos algebraicos.

Conforme iba retrocediendo en la escala evolutiva de los lenguajes me ocurrió algo curioso... algo solo comparable a la involución que sufrieron los protagonistas de "El señor de las moscas". A medida que me acercaba cada vez mas al ensamblador despertaba en mi algo atabico, casi salvaje... Programar la maquina desnuda, sin la ayuda de poderosos conceptos fue una experiencia intoxicante... casi lo mismo que debían sentir nuestros ancestros al cazar bisontes solo con piedras y flechas... al percibir el olor de la sangre de la presa cazada...

Desde luego, la aplicación era lo suficientemente pequeña como para que el lado oscuro del c no se mostrara. De haber sido mas grande la aplicación, los problemas con el manejo de memoria, el tedio de la escritura de código boilerplate, la molestia de tener a cada paso que indicar lo obvio me habría frustrado. Al igual que un citadino transportado a los albores de nuestra especie se habría aburrido esperando por la presa, hambriento, exasperado por los mosquitos y molesto por las inclemencias del tiempo.

Es que el olor de la sangre llama, pero no tanto...

Un abreboca al poder de la programación funcional

2007-02-04T06:49:00.000-08:00

Una de las razones por la cual la programación funcional es considerada poderosa es por la facilidad con la que se puede derivar nuevo código a partir del ya existente. Por ejemplo, una de las tareas mas comunes durante el desarrollo de programas es operar sobre una colección de datos, bien sea para generar una nueva colección, modificar la ya existente o generar una estructura nueva derivada de esta.

Así, si quisieramos la sumatoria de los valores en un arreglo numérico el código (en python) seria:

suma = 0
for x in arreglo :
suma += x

Para elevar al cuadrado los componentes de un arreglo, la solución que implementaría un programador de C escribiendo python seria:

for i in len(arreglo) :
arreglo[i] = arreglo[i]**2

(python tienen una forma mas elegante de lograrlo, pero es precisamente una forma "prestada" de lenguajes con paradigmas diferentes al imperativo).

Estos códigos son representativos de las soluciones imperativas: crear un bucle que recorra el arreglo, operando sobre cada elemento para generar el resultado deseado. Un programador de C o Java con algunos años de experiencia habrá escrito lineas semejantes a esas un millar de veces. El problema esta en que precisamente la tarea es tan común que forma un patrón ideal para ser resumido.

Ahora, como podría aislarse esa solución en un lenguaje como C o Java, de manera que el programador solo tuviera que escribir la parte del problema que cambia (el suma +=x o el arreglo[i] = arreglo[i]**2)? Dado que la estructura semántica del C y el java están fijadas y no lo permiten directamente, la única posibilidad seria por medio de una librería. La librería implementaría la parte común (el bucle) y recibiría como parámetro un elemento (un objeto en Java o un apuntador a una función en C) que contenga el pedazo de programa que varía.

Y he allí el problema. Declarar una función en C es mas trabajo que escribir el bucle directamente. Definir una clase en Java que implemente el comportamiento deseado, instanciarla y pasar el objeto a la librería no es una opción: es una penitencia.

La mayoría de los lenguajes funcionales por otra parte permiten la creación de funciones con un costo mínimo para el programador, razón por la cual hacer una librería con los tipos mas comunes de bucles no solo es viable, sino la forma natural de proceder.

El primer caso mostrado, la suma de los valores en un arreglo, es de hecho un caso particular de un tipo de bucles llamado fold (también llamado reduce). Este caso se caracteriza por dos elementos: un valor a ser devuelto en caso que el arreglo sea de longitud cero, y una función que tome dos valores y devuelve uno, la cual es usada para "reducir" el arreglo. En nuestro caso, el valor a ser devuelto en caso que el arreglo este vació es cero y la función que reduce el arreglo es la suma.

Así, expresar ese bucle en python de forma funcional seria

reduce(real.__add__, arreglo, 0.0)

En Haskell, uno de los lenguajes mas elegantes, seria

foldr (+) 0.0 arreglo

En ambos casos el significado es el mismo: si el arreglo esta vació, devuelve 0.0, sino suma sus elementos. Si bien este programa puede resultar de mas difícil lectura (sobre todo debido a la costumbre imperativa), también ofrece algunas ventajas:

Es mas conciso
No usa variables temporales
Puede ser manipulado programaticamente

El ultimo punto tendrá un impacto gigante en la forma en que programamos en los años venideros. Dado que la función fold aisla las partes que varían en un bucle y homogeniza la estructura, es mas amistosa desde el punto de vista matemático. Si todos los bucles son expresados con fold y otras pocas estructuras semejantes, el código puede ser transformado por un compilador inteligente siguiendo una serie de teoremas, obteniendo un código super-optimizado.

Alternativa al C: O'Caml

2007-01-25T04:55:00.000-08:00

Cuando se habla de alternativas al C, la mayoría de personas piensa en C++, Objective C o Java. Un candidato mas digno, aunque menos conocido es el lenguaje D. Todas estas opciones tienen algo en común: son lenguajes de computación que sigue el paradigma imperativo.

Los lenguajes imperativos se caracterizan por los siguientes elementos:

Son dependientes del estado de la computación: Los resultados de los computos dependen de un conjunto de valores almacenados durante la ejecución del programa y que son mutables
El flujo de control debe ser totalmente especificado
El orden de ejecución debe ser totalmente especificado

Estas características hacen que los lenguajes imperativos puedan ser traducidos mas directa y eficientemente a lenguaje maquina, pero al costo de forzar en el programador la especificación de la solución a un mayor nivel de detalle. Por eso, cuando se busca velocidad, la mayoría de los programadores están predispuestos a buscar lenguajes imperativos. O al menos así solía ser

Bienvenidos a O'Caml

Los lenguajes funcionales por su parte, ofrecen ciertas ventajas al programador:

No dependen del estado: Esto elimina un conjunto de errores y permite que el código sea mas auditable (de hecho el código puede ser demostrado correcto, en el sentido matemático del término)
Composición de programas: Pequeños segmentos de programas pueden ser combinados de manera sencilla, permitiendo la generación de código complejo expresado sucintamente
El flujo de control y/o el orden de ejecución no necesita ser indicado explícitamente

O'Caml es una interesante encarnación de los lenguajes funcionales. Ofrece todas las ventajas descritas (con la excepción del orden de ejecución, el cual sigue siendo explicito). Además, permite programar en otros paradigmas como el imperativo o el orientado a objetos. Agreguesele a ello su robusto sistemas de tipos, el cual permite detectar muchos errores en tiempo de compilación y generar un código super-optimizado.

Adicionalmente, O'Caml parece haberse trazado una meta poco común para los lenguajes funcionales: competir en el terreno de los lenguajes imperativos. Así, O'Caml ofrece librerías para la programación bajo UNIX, depuradores, profilers...

Esto hace del O'Caml uno de los lenguajes mas interesantes y rápidos del vecindario [1], apto incluso para la programación de bajo nivel. De hecho, mientras escribía la entrada respectiva al lenguaje de programación D, para familiarizarme con el, decidí implementar el programa supervise de Dan Berstein. Pues, para mi sorpresa resultó mas directo hacerlo en O'Caml que en D, debido al mejor soporte de las librerías del sistema (el D es facílmente extensible también; no se trata de una crítica al lenguaje D, sino un reconocimiento a las librerías estándares de O'Caml)

[1] Si, si. Son micro-benchmarks. Si, si. Estas pruebas no representan el uso real de los lenguajes in the wild, y todas las advertencias de costumbre cuando se habla de benchmarks. Pero... mientras no haya una forma científica de comparar los lenguajes, una prueba justa es al menos un indicativo a considerar.

Que viene despues de "C"?: "D"

2007-01-19T11:32:00.000-08:00

Habiendo establecido que el lenguaje C es una opción cada vez menos atractiva para la programación de sistemas, cabe preguntar: cual es la alternativa? Existen varias, entre ellas:

C++
D
OCaml
SML

La opción mas obvia, el C++ es la menos interesante. Dado que el C++ es una extensión del C cuyo objetivo era mantener la compatibilidad con el mismo a nivel de código fuente, presenta las mismas debilidades. C++ es decepcionante en muchos aspectos. No va lo suficientemente lejos en su intención renovadora. Ofrece programación orientada a objetos y templates, pero no hace ningún esfuerzo por eliminar las debilidades del C. No agrega recolección de basura y su sintaxis es perversamente compleja. Pese a todo ello el C++ conquisto parte del mercado del C.

Por que?

Precisamente debido a su bajo perfil pudo el C++ colarse en el mercado. Casi puedo escuchar el razonamiento de los primeros gerentes en adoptarlo en sus proyectos: "Quieres cambiarlo todo para que nada cambie? Quieres mantenerte a la moda sin arriesgar un ápice? C++ es para ti". Sumele a ello la inercia de la interacción con librerías y código heredado, el temor al reentrenamiento, y tendremos un panorama en el que el el heredero de C debía provenir de su mismo linaje.
Desde luego, también estaban los programadores que deseaban probar el paradigma de la programación orientada a objetos y no conocían nada mejor. Como podrían conocer otra cosa? Quien les hablaría de otros paradigmas, como la programación funcional o implementaciones mas radicales y puras como Smalltalk?

En donde nos deja todo esto?

Existen otros lenguajes no emparentados directamente con el C que permiten la programación de sistemas y ofrecen una velocidad igual o superior. En efecto, el C, el lenguaje mas veloz de la cuadra, el hasta hace poco imbatible líder en rendimiento, se ha visto superado por otros contenedores, los cuales ofrecen además mejoras en otras áreas.

D

Sobre las alternativas en el paradigma funcional (OCaml y SML) hablaré en otra ocasión. Centremonos en el mas clásico D. El lenguaje D es a la programación de sistemas lo que Java es a la programación de aplicaciones generales: la satisfacción a la promesa incumplida por C++ de un mejor C.

D no pretende ser compatible a nivel de código fuente con C. Sin embargo, si ofrece compatibilidad a nivel binario. Esta característica clave ya lo separa del montón. Para que un lenguaje de alto rendimiento aspire tener algún éxito, debe necesariamente poder interoperar con las librerías heredadas. Muchos lenguajes conceptualmente mas interesantes que el C han fracasado por el problema del huevo y la gallina (o es el programador y la librería?): El lenguaje es interesante pero no se usa para el desarrollo porque no tiene suficientes librerías, las cuales no son escritas porque no hay suficientes programadores trabajando en el lenguaje porque... no tiene suficientes librerías.

D ha escapado graciosamente a este circulo vicioso al no reinventar la rueda. Las estructuras de datos entre C y D son compatibles. Además, D usa la misma ABI que C. Esto significa que, dado un binario, no hay forma de distinguir si proviene de código fuente escrito en C o en D.

Pero D ofrece mucho mas que compatibilidad binaria:

Recolección de basura con capacidad de ser desactivada, permitiendo el manejo manual de la memoria.
Programación orientada a objetos.
Eliminación de las arbitrariedades e inconsistencias del C.
...manteniendo una sintaxis semejante.
Eliminación del preprocesador de texto.
Un poderoso sistema de tipos.
Las mas importantes estructuras de datos están predefinidas en el lenguaje.
Implementación en software libre.

En definitiva, en la clase de lenguajes imperativos destinados a la programación de sistemas o aplicaciones, ya existe una alternativa viable a C/C++. Solo el miedo irracional a nuevas alternativas mantendrá al C en su posición actual.

Migración a Blogger

2007-01-15T09:44:00.000-08:00

He migrado todas las entradas del blog a un nuevo proveedor, http://www2.blogger.com/. Por esta razón todos los post previos a este tienen la misma fecha.

El mal C

2007-01-15T09:43:00.001-08:00

No deja de resultar paradójico que las características que hacen que un lenguaje triunfe suelen ser las mismas que ocasionan que este deje de ser una alternativa viable. Esta aparente paradoja se entiende cuando se analizan los cambios en el entorno: mientras un lenguaje sigue siendo básicamente el mismo conforme pasa el tiempo, el poder de computo, la memoria y el tipo de problemas evolucionan continuamente.

En una entrada anterior comente que hizo grande al C. Ahora comentare por que el C es cada vez menos una opción valida en un conjunto cada vez mas grande de problemas.
Las principales características que evidencian la edad del C son:

Sin colección de memoria
Sistema de tipos débil
Muy de bajo nivel
Pobre especificación

La falta de un recolector de memoria, la cual es una atractiva característica en la programación de sistemas es una pesadilla en casi cualquier otro ámbito. Con excepciones limitadas a cierto tipo de problemas, el ser humano no es mejor administrando la memoria que el compilador. Esta simple verdad es difícil de aceptar por los miembros de la vieja escuela, incluso cuando ellos mismos confían rutinariamente en el compilador para optimizar su código.

El sistemas de tipo del C es otra de esas características que son una bendición/maldición. En el momento de su diseño, el sistema de tipos del C era elogiable: lo suficientemente simple para ser implementado sucintamente, lo suficientemente poderoso para generar código optimizado, lo suficientemente flexible para competir con el ensamblador. Eso fue entonces. Ahora existen sistemas de tipos mas poderosos que permitir expresar los problemas de manera mas clara y ahorrar lineas de código. Estos mismos sistemas, al ser mas estrictos, permiten hacer mas y mejores optimizaciones, por lo cual el C ya no es el lenguaje mas rápido del oeste (véase el lenguaje D, Ocaml o SML).

Otro aspecto que ha cambiado en el ecosistema, es que con el aumento en la velocidad de los procesadores y su memoria, muchas tareas privilegian el tiempo de programación sobre el tiempo de ejecución. Esto hace que el C sea un lenguaje de muy bajo nivel. La administración de sistemas, la cual se hacia antes con C, se hace ahora con bash, perl o python. El desarrollo de aplicaciones web es dominada por lenguajes interpretados. Incluso el uso de lenguajes mas flexibles ha llegado al escritorio de la mano de java/C#-mono/tcl-tk/python.

El ultimo punto, la pobre especificación del C tiene que ver con el hecho que el lenguaje, en aras de permitirle al implementador obtener la máxima eficiencia en la plataforma de destino, se negó a regular de manera completa el comportamiento del lenguaje. Aunque admito que este seria un problema aun mas grave de no haber sido superado por la incompatibilidad entre librerías en el mundo UNIX…

El buen C

2007-01-15T09:42:00.000-08:00

Con mas de treinta años de existencia, el lenguaje C aun es uno de los mas usados para escribir las aplicaciones con las que el usuario final se relaciona. Virtualmente todos los sistemas operativos de uso masivo son escritos en el, al igual que muchas aplicaciones en las que la velocidad es critica.

Si bien las costuras del lenguaje tienen tiempo siendo evidentes, hoy quiero escribir de las características que hicieron al C atractivo durante este periodo. En otro momento escribiré sobre los elementos que lo hacen hoy día, a mi modo de ver, dispensable.

En la época en la que el C fue desarrollado los recursos del sistema eran sumamente escasos para los estándares actuales. Los costosos minicomputadores median su memoria en Kilobytes en vez de gigabytes y la programación en ensamblador aun era común.

Bajo estas condiciones el C hizo lo mejor que pudo:

Permitir expresiones aritméticas y lógicas en alto nivel, siguiendo la tradición de los lenguajes imperativos que lo precedieron.
Permitir el manejo de la memoria con una flexibilidad comparable al del lenguaje ensamblador.
Usar un sistema de tipos que permite la generación de código optimizado.
Dejar el manejo de memoria al programador.

Estas características le valieron al C el ser considerado el lenguaje de “alto-bajo nivel”: lo suficientemente alto como para que no fuera tedioso escribir código para el procesamiento de datos y lo suficientemente bajo para sustituir al ensamblador el 99.9% de las veces. Sumesele a ello que fue el lenguaje utilizado para escribir el sistema operativo UNIX y se tiene una combinación ganadora.

La razón por la que el lenguaje C se ha mantenido saludable durante estas décadas (además de la inercia causada por el volumen de librerías a su disposición) es que durante todo este tiempo no ha habido alternativas creíbles e interoperables que permitan hacer programación de sistemas. El controlar ese nicho ha mantenido la preponderancia del C en la escritura de sistemas operativos y librerías de soporte.

Tal situación podría estar por cambiar, aunque eso es motivo para otro post.

Hacia el Sistema Operativo del siglo XXI

2007-01-15T09:39:00.000-08:00

Hay muchos conceptos interesantes en el desarrollo de sistemas operativos. Buena parte de ellos son diseños totalmente nuevos. Si bien el desarrollo desde cero ofrece el terreno óptimo para la innovación, experiencias del pasado sugiere (el computador personal, MSDOS, ethernet…) que la evolución de los sistemas actuales tiene mayores probabilidades de éxito.

En este orden de ideas, cuales son las áreas en las que Linux necesita evolucionar para hacerse mas flexible y coherente? He aquí algunas posibilidades:

Una nueva jerarquía en el filesystem: La jerarquía de directorios de linux, si bien es mas coherente que la de Windows, aun tiene mucho espacio para mejorar. Otros Unixes ya han comenzado el proceso, desde NeXT, hasta Mac OSX. Un ejemplo interesante dentro del mundo del Linux es Gobolinux.
Paquetes para aplicaciones: Los sistemas de paquetes dependen de la jerarquía actual en el sistema de archivos, lo cual tiene sus inconvenientes: esparcen los archivos de una apelación entre varios directorios y tienen dificultades con múltiples versiones de librerías.
Un nuevo sistema de archivos: En particular uno que permita asociar propiedades a los archivos. La mas reciente versión de ReiserFS podría permitirlo a través de plugins.
Nuevos mecanismos de seguridad: La seguridad de UNIX basada en usuario-grupo-otros ya esta mostrando su edad. Si bien es suficiente para muchos entornos, en la actualidad ya hay varias opciones con distintos grados de utilidad.

Estos cambios son superficiales y pueden implementarse en nuevas distribuciones sin tocar el núcleo. Hay otras mas ambiciosas, las cuales requieren abandonar Linux tal y como lo conocemos. En futuros artículos comentare algunos de esos cambios.

Uno en particular, es abandonar el mantra de UNIX “todo es un archivo”. Es cierto, esa concepción fue una de sus grandes fortalezas, y tal vez la mas influyente. Sin embargo, la vieja conseja nunca fue del todo cierta. Comenzando con la división entre dispositivos de bloque y de carácter. Adicionalmente, las infames llamadas ioctl también conocidas como todo-lo-que-no-cabe-en-la-interface-de-archivos-va-acá. Un paso adelante seria el reconocimiento que todo no es un archivo y adoptar un enfoque mas liberal. En vez de tener una jerarquía de archivos, el sistema seria un espacio de nombres de objetos.

Sustituir “archivos” por “objetos” puede sonar cosmético, pero elimina la necesidad de ioctl, homogeniza los conceptos y permite al SO adaptarse a necesidades cambiantes. Desarrollare el concepto en próximo artículos.

Por que calcular es mejor que esquematizar?

2007-01-15T09:38:00.000-08:00

En http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf se puede encontrar el paper de Philip Wadler “Why calculating is better than scheming”. Este paper compara lenguajes de la familia lisp/scheme con lenguajes tipo miranda/haskell en el contexto del excelente libro de Abelson y Sussman “Structure and Interpretation of Computer Programs” (SICP).

El paper analiza temas aun no resueltos en el área como:

Definición de tipos
Notación prefija vs. infija
Las virtudes del sistema de macros de lisp

Su conclusión? Que la notación infija, la posibilidad de declarar tipos de datos, el uso de tipos de datos algebraicos y el emparejamiento de patrones hacen que la intención del programador sea expresada de manera mas clara y concisa; que la identidad entre código y datos en lisp puede ser un importante factor de confusión para los programadores noveles (y los no tanto); que la evaluación perezosa ofrece una elegante homogenización de los lenguajes que la poseen.

En definitiva, lisp no sale muy bien parado en el análisis de Wadler. Tal vez ello le condujo al desarrollo de Haskell…

Sobre Strong Typed

2007-01-15T09:37:00.000-08:00

Strong Typed es un blog dedicado al estudio de la ciencia de la computación, programación y sistemas operativos. Otros temas afines, en lo tocante a matemática también tienen cabida acá.