"Must learn from the bruises..."

Hoy no fue un buen día. Uno de los peores, en realidad.
Es momento de cambiar de dirección y pisar el acelerador.

The eyes, looking so cold
Condemn failure
And seek for perfection
What will never be attained

They're judging the denying face which stares back
A bewildered revelation

Show me objectivity
And let these eyes judge again

You cannot touch what you can't ever obtain
I'm inexhaustible
As well as empty in my bitter search

My words are yours,
my voice speaks for your thoughts
I am your mirror without remorse,
your reflection without doubts

I fall and fall
I must learn from the bruises
The scars will be my guide

There's no excuse in ignorance
No time for weakness or regret
Face your mirror without doubt
Your reflection without remorse

If knowledge was wisdom
And wisdom the key to inner rest
Teach me...

--The Key. After Forever.

Dándole a Lisp

Bueno... últimamente, y después de programar un rato en Haskell, retomé los dialectos basados en Lisp y me dí cuenta que Lisp puede ser mejorado. En concreto, la característica que más me gustó de Haskell es la forma en que manipula las funciones. Si bien en ambos lenguajes son objetos de primera clase, Haskell desde mi perspectiva lo hace mejor. El uso intensivo de funciones de orden mayor como map y fold en lugar de escoger iteración o recursión, la composición de funciones, aplicación parcial implícita de funciones (o curried functions en inglés), etc., son las características que más puedo resaltar.

En particular, intento incluír en mi estilo de programación en Lisp a map y fold así como la aplicación parcial implícita; ésta última dándome más problemas dado que ningún dialecto principal de Lisp la maneja automáticamente. Si bien hay algunas macros que ayudan a realizar algo parecido, el tener un dialecto que las maneje desde el principio sin que el programador tenga que modificar algo en su Lisp, sería muy cómodo.

Lo anterior me estimuló a pensar cómo incluír dichas facilidades en el dialecto que programé hace tiempo. Necesitaré un poco más de tiempo para encontrar cómo hacerlo pero estoy seguro que es posible. Mientras tanto... estaré repasando (y haciendo por fin los ejercicios) de los varios libros de Lisp que he querido leer y no he terminado: On Lisp y Practical Common Lisp.

Desde el día de hoy soy "orgullosamente" SCJP 6.0

¡Oh, la humanidad!

Por ahí dicen que P != NP. ¿Será eso cierto?

Cerraduras

No, accidental lector, este post no tiene nada que ver con aquellos dispositivos mecánicos que sirven para cerrar puertas o similares. No. Para variar esto tiene que ver con temas de programación. Advertido está usted. Siga leyendo si la curiosidad lo corroe.

Estudiando para el examen de SCJP he llegado al tema de Clases Internas. Haré a un lado mis típicos comentarios de cuánto y por qué pienso que Java es un lenguaje muy mal diseñado y sólo comentaré que la existencia de las cerraduras léxicas me ha hecho la vida muy fácil en los distintos lenguajes que las tienen y he utilizado (Lisp, Erlang, Haskell) y que la inexistencia de las mismas en Java me hará la vida muy difícil.

Como soy un programador funcional creí que la existencia de las clases internas en Java era para tener "cierto tipo" de cerradura léxica. Pues bien, creí mal. Hasta la versión 1.6 no existen y no parece que las vayan a tener pronto o que, para variar, las implementen de una manera limpia (lo cual se me hace cómico y trágico al mismo tiempo ya que las cerraduras ayudan a crear código más limpio). Las clases internas no sirven para emular cerraduras. Punto. Memorízalo, Iván.

Me pregunto por qué es que los desarrolladores de Java no las logran implementar aún. Cuando yo programé mi intérprete de SALSA! (un lenguaje estilo Scheme) me costó trabajo tener cerraduras verdaderas, ya que las que tenía parecían ser cerraduras pero lo único que hacían era buscar el símbolo en el siguiente scope. Al final logré implementarlas haciendo varios cambios a las tablas de símbolos y la forma en la que éstas funcionaban pero lo logré. ¿Qué impide a los desarrolladores de Java tener cerraduras? No creo que sea algo como "un simple bug" como el que mi intérprete tenía, deben ser cosas más profundas que de seguro tocan puntos medulares en el diseño del lenguaje. Al menos esa es mi idea ya que ha pasado mucho tiempo como para que no las tengan.

Por ahí escuché que C# tiene una forma de cerraduras que hacen llamar delegates (amo esa consistencia en Microsoft de inventar términos para llamar a cosas que pretenden ser otras que no llegan a serlo). Si es que los delegates están bien programados o si al menos mantienen en cierta forma el poder de las cerraduras reales, harán a C# un lenguaje digno de ser aprendido y hasta, tal vez, usado.

Me pregunto si los demás lenguajes de ultima generación que no son funcionales y más o menos conozco (Python, PHP, Ruby) las tendrán implementadas y cómo. Empecé a buscar en Google los términos "python closures" y "ruby closures" (aún falta que busque para PHP) y encontré algunas ligas que estaré revisando y tal vez haga un post acerca de las mismas.

Ligas para Ruby:
http://www.artima.com/intv/ruby.html
http://www.artima.com/intv/tuesday.html
http://www.artima.com/intv/closures.html

Ligas para Python:
http://mail.python.org/pipermail/python-list/2004-July/270951.html
http://ivan.truemesh.com/archives/000392.html

Liga para Java:
http://gafter.blogspot.com/2007/01/definition-of-closures.html

Interesante...

Una era de avances en una sola liga

Se solicita...

Por término de periodo vacacional se solicita estudiante de ingeniería en sistemas o afín de séptimo semestre o posterior para concluir estudios en conocida escuela superior.

Requisitos: Desbordante paciencia. Deseos de aprender y superarse no son aconsejables. Se recomienda haber llevado un curso de anger management. Tendrá más posibilidades de ser contratado si se parece al susodicho que aparece en las fotos de este perfil.

Ofrecemos: Un sincero pésame.

Interesados por favor comunicarse con su santa madre.