Comments on: Prelude - a Haskell-like functional library http://www.lacaraoscura.com/2006/08/31/prelude-a-haskell-like-functional-library/ La Cara Oscura del Desarrollo de Software Tue, 09 Sep 2008 23:46:01 +0000 http://wordpress.org/?v=2.6.1 By: andrew cooke http://www.lacaraoscura.com/2006/08/31/prelude-a-haskell-like-functional-library/#comment-462 andrew cooke Fri, 22 Sep 2006 11:47:05 +0000 http://www.lacaraoscura.com/2006/08/31/prelude-a-haskell-like-functional-library/#comment-462 aiie - puchas, disculpame. recien recibi un email diciendo que estan en venezuela, y no chile. encontre el sitio web buscando "haskell santiago chile" en google, si me acuerdo bien, y por eso asumi que ustedes eran chilenos. disculpame.... aiie - puchas, disculpame. recien recibi un email diciendo que estan en venezuela, y no chile. encontre el sitio web buscando “haskell santiago chile” en google, si me acuerdo bien, y por eso asumi que ustedes eran chilenos. disculpame….

]]> By: andrew cooke http://www.lacaraoscura.com/2006/08/31/prelude-a-haskell-like-functional-library/#comment-461 andrew cooke Thu, 21 Sep 2006 20:55:44 +0000 http://www.lacaraoscura.com/2006/08/31/prelude-a-haskell-like-functional-library/#comment-461 haskell si es interesante - pero no se si seria facil cambiar ruby a haskell a traves de usar una libreria. veo muchos problemas, incluiendo: 1- parece, leyendo la documentacion de la dicha libreria, que ruby no tiene "tail call optimisation" (lo que expliqueria porque no se puede definir un fold recursivo que funciona bien con una lista de mas que 800 elementos). en haskell es muy, pero muy, usual definir procesamientos en la forma de funciones recursivos porque.... 2- haskell tiene "pattern matching", y ruby no (si entiendo bien). aunque no es nada mas que "syntax sugar", pattern matching es responsable por la elegancia de la mayoria del codigo escrito en haskell. por ejemplo: f 0 = 1 f n = n * f (n-1) (codigo haskell valido) - no se necesita "if n == 0 .... else ....". asi que el codigo se ve muy limpio y puro. 3- es facil confundirse sin static types. en un programa haskell es normal usar funciones muy generales (map, fold, etc) para procesar estructuras complejas. en un idioma como ruby, hay que escribir pruebas para todo los casos y, cuando fallen, a veces no es tan claro porque. en haskell, ese problema no existe - no se necesita definir ningun tipo (normalmente), pero igual el compilador va a verificar que el codigo sea auto-consistente. lo que estoy tratando de explicar (una meta no tan facil con mi castellano horrible) es que este problema - que ya conozemos desde la diferencia entre java y ruby, por ejemplo - es mucho mas grave en el caso de haskell, donde se usa funciones much mas generales, y mas niveles de abstraccion. ja. tengo que confesar que nunca he usado ruby (aunque he estudiado un sistema escrito con ruby on rails y me impresiono *harto* - era much mas simple que algo equivalente que escribi en java) pero si he usado haskell. si aun quieres probar haskell, puedo sugerir que una libreria mia - pancito, http://www.acooke.org/jara/pancito/index.html - puede ser util. no soy un experto en haskell, y el codigo no es perfecto, pero la generacion de "imagenes funcionales" es un proceso entretenido, y ya ha servido como introduccion basica a haskell por unas personas. [soy ingles, vivo aca en stgo, y trabajo en turnos en la serena. encontre este blog buscando algo interesante, relacionado a programacion aca en chile. me gusta mucho lo que ya he leido. hay otros blogs que tratan de temas similares? hay alguna sociedad profesional con charlas aca? bueno - gracias por tratar de entenderme! andrew] haskell si es interesante - pero no se si seria facil cambiar ruby a haskell a traves de usar una libreria. veo muchos problemas, incluiendo:

1- parece, leyendo la documentacion de la dicha libreria, que ruby no tiene “tail call optimisation” (lo que expliqueria porque no se puede definir un fold recursivo que funciona bien con una lista de mas que 800 elementos). en haskell es muy, pero muy, usual definir procesamientos en la forma de funciones recursivos porque….

2- haskell tiene “pattern matching”, y ruby no (si entiendo bien). aunque no es nada mas que “syntax sugar”, pattern matching es responsable por la elegancia de la mayoria del codigo escrito en haskell. por ejemplo:
f 0 = 1
f n = n * f (n-1)
(codigo haskell valido) - no se necesita “if n == 0 …. else ….”. asi que el codigo se ve muy limpio y puro.

3- es facil confundirse sin static types. en un programa haskell es normal usar funciones muy generales (map, fold, etc) para procesar estructuras complejas. en un idioma como ruby, hay que escribir pruebas para todo los casos y, cuando fallen, a veces no es tan claro porque. en haskell, ese problema no existe - no se necesita definir ningun tipo (normalmente), pero igual el compilador va a verificar que el codigo sea auto-consistente. lo que estoy tratando de explicar (una meta no tan facil con mi castellano horrible) es que este problema - que ya conozemos desde la diferencia entre java y ruby, por ejemplo - es mucho mas grave en el caso de haskell, donde se usa funciones much mas generales, y mas niveles de abstraccion.

ja. tengo que confesar que nunca he usado ruby (aunque he estudiado un sistema escrito con ruby on rails y me impresiono *harto* - era much mas simple que algo equivalente que escribi en java) pero si he usado haskell. si aun quieres probar haskell, puedo sugerir que una libreria mia - pancito, http://www.acooke.org/jara/pancito/index.html - puede ser util. no soy un experto en haskell, y el codigo no es perfecto, pero la generacion de “imagenes funcionales” es un proceso entretenido, y ya ha servido como introduccion basica a haskell por unas personas.

[soy ingles, vivo aca en stgo, y trabajo en turnos en la serena. encontre este blog buscando algo interesante, relacionado a programacion aca en chile. me gusta mucho lo que ya he leido. hay otros blogs que tratan de temas similares? hay alguna sociedad profesional con charlas aca? bueno - gracias por tratar de entenderme! andrew]

]]>