sábado, 31 de diciembre de 2011

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 )

Para el año que viene

 No puedo dejar de enojarme cada vez que termina un año y sale el 'Top 10 de cosas que tenes que saber para el año que viene' (para levantarla con pala siendo programador).

Ok, Sun Tzu dice, lo primero que hace un guerrero es hacerse invencible y después esperar a que el enemigo sea debil

Lo primero que tiene que hacer un programador (ingeniero, diseñador, arquitecto, y todos los lvl de programador para mi son programadores.. la diferencia es una marketineada pelotuda para los de RRHH asi nos dan mas plata y cosas mas divertidas) es hacerse "invencible".

¿Que significa hacerse invencible en el contexto del conocimiento? 

 En este contexto se trata de ser una persona pensante.  Muchas veces creemos que ser pensante se trata de ser inteligente, y de hecho, en parte se trata de eso, pero no es lo unico, se trata de analisar las experiencias, se trata de cablear los conocimientos, relacionarlos, pulirlos hasta que entren en instancias del sentido común. Una vez ahí, lo que sabemos pasa a ser parte de la inteligencia y cualquier aprendizaje posterior va a ser mas sencillo.

¿Por que pensante y no con muchos conocimientos?

 Cuando lo que se hace es levantar conocimientos sin relacionarlos o llevarlos hasta un nivel de obviedad tenemos un monton de conocimiento mal clasificado, es un conocimiento tan util como saber que es un strategy o un state y no entender para que sirve y cuando se usa y como se usa.


 ¿Que es ser una persona pensante en sistemas?

     La programación es un mundo muy divertido por que incluso la ciencia ficcion, o mejor dicho, sobre todo lo ficticio es una excelente herramienta de trabajo.
    Una persona pensante en sistemas es una persona que cuando aprende un framework no lo hace solo a nivel empirico, sino que tambien se detiene a entender la metasfora, la analogía loca que hizo el que lo pensó.
    Una persona pensante en sistemas es una persona que es capaz de salirse de los purismos pelotudos que uno adopta al momento de aprender solo para entender la idea completa, por que los purismos atentan con la creatividad y con la comprensión.
    Puedo seguir con mas puntos, pero creo que ya hice mi punto, se trata de aprender del uso, la experiencia y la reflexion creativa (me pueden decir que es todo lo mismo, pero eso es en el siguiente nivel de abstraccion, no en este) los conceptos abstractos.

 ¿Como me hace invencible el aprender a nivel de conceptos?

   Sencillo, los humanos no somos taaan avanzados, los conceptos que se manejan son unos pocos, de vez en cuando aparece algun meta concepto que engloba a otros y así.
   Una vez que uno pasa la primera barrera de la comprensión conceptual de las cosas (Que es bastante cuesta arriba, pero que yo lo haya logrado implica que se puede) todo se vuelve mas sencillo. Por ejemplo, nada de lo de clouding es realmente novedoso en nivel conceptual, estamos hablando de procesamiento paralelo que existe desde hace decadas. Se usa  un poquito distinto, ahi esta el verdadero conocimiento, agregar la idea de que se puede usar de otras formas (Que es el disparador verdadero de todas las demas ideas de clouding actuales). El iphone es una idea viejisima de interaccion con usuario (como cajero automatico) revivida por la wii y bajada finalmente a telefono- dispositivo movil. Donde esta lo nuevo? se puede usar de otra manera.

   Finalmente, uno se hace invencible en sistemas cuando es capaz de entender en lineas generales y pudiendo usar cualquier framework y cualquier lenguaje conceptualmente similar a otro (o mix de otros) ya usado en un par de dias o menos y pudiendo llevarlo a su maxima expresión en un par de meses y pudiendo pensar cosas distintas a las que pensó el autor sobre eso, pero con verdadera consistencia en menos de un manojo de meses.


Finalmente

    Lo que realmente me molesta del top 10 es que la gente lo ve y dice 'tengo que aprender esto asi me forro de guita' y va y aprender un par de pelotudeces y realmente cree que entiende algo. Cuando con un poquito de esfuerzo extra ahora podrian entender por encima todos los top 10 de todos los años en 1h anual, forrarse en guita y ademas entender en serio.
    Hagamosnos entonces un favor, percibamos, analisemos, hagamos, percibamos. comprendamos, reflexionemos y volvamos a empezar.


  Mi mensaje de fin de año es: El dogma es el peor enemigo del conocimiento.

lunes, 26 de diciembre de 2011

Mixins y javascript

Para terminar el día del blog (ahora paso a hacer catarsis en otro blog) voy a tirar un par de ideas de compartimiento en javascript.

 Antes que nada voy a remarcar que escucho mucho 'javascript es una mierda' 'javascript no es orientado a objetos' y otras paparruchadas.

Javascript no es una mierda, la mierda es tener que programar una pagina y que se vea bien en internet explorer 6.

A javascript lo unico que le agregaría para orientación a objetos seria la palabra clave object para no tener que definir un objeto con function. Pero no me pondría a hablar de forradas como clases, herencia y eso, después de todo es un lenguaje orientado a objetos con otras forma de armado de objetos, mas manual si, pero mucho mas poderosa.


 Empecemos un poco por, ¿Por qué existen las clases?

Simple, tengo un monton de objetos que van a tener el mismo comportamiento, defino una plantilla y después los creo creandolos a partir de esta plantilla.

Si nos ponemos a pensar que lo importante en la orientación a objetos son los objetos, entonces en seguida salta a la luz que la clase es una forma de programar menos en ciertos contextos, es una forma de clasificar y ordernar conocimiento que tira una linea fuerte obvia y unidireccional: un objeto puede ser de solo una clase (bajo la idea original de clases) y en general esta clase esta muy relacionada con la clasificación que tiene esta 'idea' en el contexto de nuestro negocio.

>> y entonces... la herencia? 
>> la herencia es para poder compartir aun mas código, y para mantener la clasificación en varios niveles, permitiendo mejores abstracciones que las que daría una linea tan dura como ser una clasificación única. (por ejemplo, si solo puediera tener una clasificación no se me ocurriria pensar en la clase animal domestico, iria directamente a tener las clases perro y gato) 


>>Pero javascript no tiene una buena forma de ordenar y compartir codigo
>> Eso lo decís por que estas pensando en clases cuando debieras estar pensando en compartir código.


Hace algunos años apareció la idea de traits / mixins. En lineas generales se trata de compartir codigo entre distintos objetos / clases (segun approach) a un nivel menos estricto que el de clase, permitiendo otras figuras de clasificación que solo el jerarquico de un padre a n hijos (como propusiera en su momento la herencia multiple sin buen recibimiento por la paja mental de los diseñadores de lenguaje a la hora de pensar en la resolución de mensajes).

Probablemente después me cope y haga un articulo para este tema puntual, ahora mismo voy a suponer que lo tienen al menos de oido. Sino busquen por google o esperen a mañana o pasado que escriba y lo suba.

Aca les dejo una idea de mixin en javascript


function BaseComponentMixin (object) {
         object.log = function (message) { console.log (message); };
         object.renderOver = function (componentId) {
                                 $("#"+componentId).append(object.getHtml());
         };
         object.getHtml = function (){
                                  alert("El objeto mixeado debe implementar getHtml()");
        };
}

function HtmlExample (object)  {
       object.getHtml = function () { return "<b> hola mundo </b>"; } ;
}


function  Componente () {
        BaseComponentMixin(this);
        HtmlExample(this);
}

var comp = new Componente();
comp.log("hola");
comp.renderOver("unIDdeDiv");



Que ganamos con esto? Ahora tenemos codigo ordenado por cierta 'habilidad' y podemos organizarlo en mas formas que solo clases. Eso nos permite reutilizar mas código y llegar a abstracciones mas locas que en un codigo sin orden y que en un codigo con un orden demasiado estricto.



>> pero.. es javascript, para que me quiero romper tanto la cabeza? es solo la pantallita
>> Si bueno, la pantallita te puede traer muchos problemas y mucha repetición de código. Tambien hay que tener en cuenta que los sitios evolucionan a ser de una sola pagina por lo que ya no es mas un poquito de javascript para animar los menues, sino que tambien necesitamos java para el comportamiento que ya no va a generar el servidor.
>> Bue.. no se.. igual yo voy a seguir haciendo clases aunque sean mixins
>> No seas pelotudo, usa los mixins como mixins y las clases como clases. No acotes tu pensamiento a la costumbre y no pronuncies opiniones tan cerradas sin haber probado si quiera una vez lo que vas a críticar.




Finalmente si sos usuario de Javascript por ahí te hace ruido que en el mixin haya usado objeto.selector = function ().... en vez de hacerlo vía objeto.Prototype.selector, la razón por la que lo hago así es por que me gusta la posibilidad de elegir que objetos estan mixineados y que objetos no.

domingo, 25 de diciembre de 2011

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. 

Presentacion

Hago la presentación por que bue, es casi una necesidad. Este es mi segundo intento de hacer un blog de programación. La verdad que me suele aburrir escribir cosas que ya estan bien explicadas en otro lado, pero bueno, voy a tratar de aportar un punto de vista distinto y ademas postear cosas locas que se me ocurran. ble, listo me harté, para catarsis tengo otro blog.