Javascript para programadores funcionales - Parte 1

 ¿Por que no hablo de Coffee Script? 
 
  Basicamente por dos razones:

• Lo miré por arriba, pero por ahora Coffee script no se banca todo lo que quiero
• No siempre se pueden usar frameworks

¿Por que javascript y no otro?

   Por que es un lenguaje que uno facilmente puede odiar por no verle las posibilidades que nadie cuenta.  Si me dan las ganas voy a tratar de poner ejemplos de como se haría en Scala, Haskell, Python y si tengo ganas sobrenaturales lisp (perdon amantes de lisp, odio los parentesis).


¿Que me motiva?

  Cuando llegué al mundo de javascript y vi los frutos lo primero que pensé es: ¡Esto es una mierda!

   Pero después de entender javascript como javascript y no como lo que se hace con javascript ví la luz. Javascript no solo no es una mierda, sino que es hoy por hoy uno de mis lenguajes favoritos.
 
  Hay dos razones por la cual pasa esto:

   a) tengo objetos armados armados a partir de prototipos (por lo que tengo mixins en dos patadas)
   b) las funciones son datos.


  En los posts relacionados con el tópico me voy a dedicar al punto b.

 Las funciones son datos

  En javascript todo es un dato. Algunos datos son ejecutables otros no. Esto plantea una situación completamnete opuesta a la típica implementación de paradigma funcional, donde todo (incluyendo los datos) son funciones.

 En una situación opuesta, y con el soporte que tiene javascript a los tipos de datos (basicamente ninguno) uno tiene un montón de herramientas para poder llegar en pocos pasos al lado opuesto.

  En javascript la analogía se ve muy claramente a la hora de crear una funcion y asignarla a una varible:

var suma = function (a, b) {
   return  a + b
}

 Como se puede ver, suma es una variable y contiene una funcion, por lo que es un dato.
 Como buen lenguaje orientado a datos, los datos se pueden pasar por parametro, con lo que tenemos la libertad de hacer con las funciones lo que querramos. Lo unico importante es asegurarse de que lo que vamos a ejecutar sea una funcion y no un dato.

 ¿Y que ventajas de funcional puedo llevar a javascript?

  Bueno, hay varias ventajas que se pueden pensar y que voy a enumerar en adelante y que voy a ir explayando en varios articulos. Hay otras que no voy a nombrar por que bue, no tiene sentido (como el sistema de tipos de haskell) y otras que por ahora no se me ocurre como hacerlo sin asesinar un gatito a sangre fría.

• Lazy evaluation (Evaluacion perezosa)
• Lambda expressions (Funciones anonimas)
• Currification - Partial Application (Aplicación parcial y currificación)
• Highorder functions (Funciones de orden superior)
• Monads (Mónadas -- esto no estoy seguro de que pueda hacer esto sin matar gatitos =P )

POO, primer pantallazo de lo mas básico.

En la version para tu vieja me tuve que controlar y no profundizar demasiado. Ahora no voy a profundizar mucho mas, pero no me voy a meter en analogías sino en el mismo paradigma.

Bueno, en POO como decíamos hay objetos y relaciones por medio de dialogo. Formalizando un poco mas, los conceptos mas importantes del paradigma de objetos son:

• objeto
• mensaje

Un objeto es un ente computacional, una representación de un concepto o parte de un concepto.

El mensaje es la forma en que se relacionan los objetos, la forma en que dialogan (o mas bien dan ordenes.. son medio cobanis).

Si venis de un lenguaje basado en el paradigma procedural imperativo (estructurado) como C, pascal, etc podrías preguntarte cosas como:

• ¿Los objetos son estructuras de datos?
• No. No son estructuras de datos, son objetos. Las estructuras de datos como bien indica su nombre son formas de dato complejas compuestas a partir de datos mas simples. Un objeto no necesariamente tiene datos, un objeto tiene que tener comportamiento propio (cosa que no permite una estructura de datos... no con punteros a funcion tampoco es lo mismo)
• ¿Los mensajes son funciones?
• No. En C lo mas parecido a un mensaje que hay es la definición de la firma de una función (definido tipicamente en un archivo header -.h-), un mensaje es una petición a un objeto que esta definida por el selector (el nombre del mensaje a ejecutar) y los parametros. 

Si venis de un lenguaje con orientacion a objetos como python, java, c++, smalltalk, etc (basados en clases) por ahi tenés preguntas como:

• Y las clases ¿No son tan importantes?
• No. Una clase es una forma de definir, compartir código y hacer plantillas para la creación de objetos. Hay otras formas de crear objetos.

Si venis de un entorno no computacional en absoluto, te sugiero que busques por otro lado. O dejame un comment y cuanto tenga algun tutorial armado te lo paso.


Es importante tener en cuenta que todo se reduce a objeto - mensaje.


Ej.

Tenemos que modelar un mundo de fantasía donde hay un dragon que se llama norberto que tiene que poder comerse a carlota la oveja, a jacinto el caballo o bien a juana la vaca.

Sabemos por fuentes fidedignas que cada vez que norberto come obtiene la mitad de energía de lo que se come. También sabemos que cada vez que tira fuego, norberto consume 2 puntos de energía por segundo que dura la rafaga.

Un bosquejo en pseudo smalltalk sería

#Norberto
>>  come: unAnimal
          energia := energia + unAnimal energia.
          unAnimal energia: 0.

>>  energia
           ^ energia

>>  escupiFuegoDurante: unosSegundos
           energia := energia - 2 * unosSegundos.

#Carlota
 >> energia
          ^ energia
>> energia: unaCantidad
           energia := unaCantidad.
>> estaMuerto
            ^ energia = 0


#Jacinto
 >> energia
          ^ energia

>> energia: unaCantidad
           energia := unaCantidad.
>> estaMuerto
            ^ energia = 0

#Juana
 >> energia
          ^ energia

>> energia: unaCantidad
           energia := unaCantidad.
>> estaMuerto
            ^ energia = 0

^ este simbolo indica que se devuelve ese valor al ejecutarse el metodo.
>> este simbolo es un separador para indicar que es un metodo
:=  este simbolo indica una asignación
= este simbolo indica la comparación por igualdad entre los objetos a izquierda y a derecha
# este simbolo indica que en mas estamos definiendo el objeto cuyo nombre sigue al simbolo.


Bueno, ya tenemos nuestros entes que tienen comportamiento (bastante acotado si.. sobre todo el de los animales), ahora falta relacionarlos para poder modelar los hechos que son que norberto se morfa todo y escupe fuego.

================================================
norberto come: carlota.
norberto come: juana.
norberto come: jacinto.

carlota energia // Esto tiene que retornar 0.
juana energia // Esto tiene que retornar 0.
jacinto energia // Esto tiene que retornar 0.

carlota estaMuerto // esto tiene que retornar 'true'

norberto escupiFuego.
================================================

Bueno entonces vemos como la asociación es clave. Podemos tener al mejor objeto del mundo que si no se relaciona con ningun otro es inútil.



Nota:
>> pará pará... antes eran mensajes y ahora son metodos?
>> eeeemm uhmm.. eee.. son dos cosas distintas. Bien distintas. la forma en que se relacionan los objetos entre si es por el envio de mensajes, la forma en que el objeto define como ejecuta ese mensaje es lo que se llama método.
>> pero entonces tendria que estar con objeto y mensaje en importancia
>> uhm.. no, un metodo es parte de un objeto, en cambio el mensaje es parte de la relación entre objetos.

POO, para que se lo cuentes tu vieja

Bueno, como todos saben la programación orientada a objetos es algo que esta en boca de todos, en mente de una menor cantidad de personas y en comprensión de aun menos.

La razón de esto no es que sea algo muy complicado, sino que hay muchas literaturas controversiales, montones de conceptos cruzados, banda de blogs que la explican cosas a partir de tecnologías, niños que creen en los gurues y pelotudos que se creen gurues.

Lamento ser yo quien se los diga: los gurues son los padres, ninguna idea es definitiva, no hay cookbook para la programación de verdad.

Una vez planteado esto, la mejor forma, a mi manera de ver las cosas, de explicar POO es partiendo de una analogia de lo más básico.

Hacer un programa orientado a objetos se trata ni mas ni menos que de concebir entes con comportamiento y hacer que se relacionen entre ellos concibiendo asi un ente aun mas grande al que se le puede pedir que resuelva los problemas que tenemos que resolver.

Ok, tu vieja por ahi asi no lo entiende, vayamos a una analogía:

Suponete que tenemos que construir un edificio ¿Qué necesitamos? Bueno, basandonos en un sistema de trabajo clásico, uno necesita albaniles con distintos conocimientos: levantar paredes, hacer cimientos, hacer columnas, etc. Tambien necesita especialistas de instalaciones: Plomeros, electricistas, gasistas etc. Además necesita supervisores que sepan controlar y tomar decisiones que no pueda tomar el albanil por que no le corresponde (sea por falta de conocimiento o por estar fuera de su responsabilidad), a eso le podemos agregar un ingeniero y/o arquitecto encargado de las decisiones mas generales. Finalmente agregamos diseñadores de ambiente para la parte estética.

Para mantener acotado el ejemplo no vamos a preocuparnos por los materiales y la lógistica de los mismos, supongamos que estan ahi y son infinitos.

Ahora mismo entonces tenemos un monton de gente (entes) que sabe hacer su tarea (reponsabilidad) y que hay que organizar (relación) para que trabajen juntos para resolver los problemas propios del negocio de la construcción.


Que es lo mas importante del ejemplo:

1. una responsabilidad a grandes rasgos en POO suele estar definida por uno o mas objetos relacionados (asi como levantar una columna implica varias personas de distintos conocimientos trabajando juntos). 
2. La relación entre los distintos responsables esta dada por el dialogo entre los mismos (envio de mensajes) Obvio, ¿No?
3. Cada responsable es un pequeño sistema en si que forma parte de uno mas grande que es el encargado de resolver el problema.
4. El mismo plomero puede trabajar en esta obra o bien cambiando el cuerito de la canilla de tu casa, así como los mismos objetos se pueden usar en varios problemas donde calcen.

Ahora, que es lo que no es extrapolable de este ejemplo:

1. He escuchado muchas veces 'orientación a objetos es programar la realidad', ok, por suerte eso es mentira, si fuese verdad nunca se hubiese terminado de hacer el primer programa. Solo se programa lo que se necesita. En este caso las relaciones informales - sociales no nos importan.
2. He escuchado tambien muchas veces que la definición de los objetos esta dada por la realidad. Pero bue, al final uno tiene que mandar un mail basandose en un protocolo que no tiene nada que ver con la realidad, o tiene que hacer un editor de texto y de pronto no existe algo así en la realidad. Al final lo mas razonable es evitar el exceso de realidad y tratar de armar una realidad adhoc.
3. No existe necesariamente una "cadena de mando" (Suena re milico) en la programación.