Programación funcional (Scala, Clojure, etc.)

bloodhound

#30 Al final no era mucho problema, pero daba asco cuando te olvidabas alguno. No usábamos ningún IDE, notepad++ y tirando. =P

1 respuesta
eisenfaust

#31 Pues hay que tenerlos cuadrados para programar en Lisp usando notepad++ xD

Yo personalmente lo que más odio de CL son nombre como rplaca, progn... En serio, ¿En qué estaban pensando? Generalmente la comunidad Scheme suele tener algo más de sensatez en este sentido.

El que sea un LISP-1 también es un coñazo cuando empiezas. Aunque en teoría y según el autor de Let Over Lambda sea mejor pero sigo sin ver la luz xD

Tampoco mola nada que el estándar actual no incluya una especificación de sockets, ni de programación paralela... data de más de 20 años y necesito una revisión urgente. Tienes que irte a versiones de pago como LispWorks para tener algo en condiciones.

Que vale, tenemos Arc, Racket, Shen, Clojure, Newlisp, Nu, R*RS... Todos perfectamente válidos y con sus pros y sus contras, pero la idea de Common Lisp es ser el lenguaje de los 100 años, debería recoger y seguir recogiendo todos los cambios, unificar y unir todos los dialectos de la forma en que se hizo durante los ochenta. Pero dudo que se vuelva a hacer. La creación de un estándar lo ha matado.

1 respuesta
elkaoD

#32 CL es Lisp-2, ¿no?

¿LispWorks en condiciones? xD Cada X errores el programa casca y se te abre en CMD (con la consiguiente pérdida de datos...) Toda una maravilla. Yo aún no he encontrado un buen editor de Lisp aunque tampoco me he preocupado mucho (tiro más de Scheme, Clojure.)

¿A qué te refieres con que lo mató un estándar? ¿No nació precisamente como estándar y precisamente para estandarizar Lisp? Ha muerto de vejez, es así de simple.

1 respuesta
eisenfaust

#33 Cierto, LISP-2. Se me había ido la pinza.

En cuanto a LispWorks... Es que seguramente estés usando la Personal Edition xD

De todas formas me refiero a la implementación, no al IDE. El IDE es algo chusquero y hay que usar el plugin de Edi Weitz para que al menos se parezca algo a la experiencia que te puede ofrecer un SLIME con Clozure o SBCL.

Me quedo con LispWorks porque funciona out of the box en todos los sistemas operativos, presenta la mejor API para programación paralela (que no concurrente) de todos los lenguajes dinámicos que he visto y CAPI es simplemente la HOSTIA.

Además, cuando finalizas un programa, un ejecutable de SBCL (aunque sea un triste hola mundo) no bajará de 30-40MB. En cambio LispWorks es capaz de cargarse funciones no utilizadas, símbolos no referenciados, etc, creando un subset del lenguaje con la consiguiente reducción del ejecutable.

A día de hoy, y especialmente para programadores freelance, LispWorks es la herramienta de desarrollo rápido y prototipado más potente que existe.

Edit: A lo que me refiero es que el estándar es lo que ha dejado congelado el lenguaje. Por eso muchos piden una nueva revisión. Es la única manera de "deszombificarlo". De la misma forma que Fortran y Scheme van teniendo revisiones a lo largo del tiempo.

Otros, en cambio, no pueden esperar a que se muera de una vez xD

1 respuesta
elkaoD

#34 en efecto, uso la Personal Edition pero... no jodas. ¿Tanto cambia? Vale que tenga límites y tal, pero lo que yo digo son puros crashes, no límites (y si lo son, la publicidad que se hacen es MALÍSIMA.)

Si con LispWorks te refieres a HyperSpec, todo correcto :P Y si es cierto que es muy de agradecer que funcione a la primera pero también tiene unos fallos garrafales que no logro entender, amén de que al principio es MUY poco user-friendly (aunque si me lo comparas con Emacs... xD)

No conozco ni el API de programación pararlela ni CAPI, no he tocado mucho CL fuera de lo algorítmico... Fue de lo primero que probé pero en cuanto saboreé las mieles de Scheme y Clojure no pude evitar huir. Me acabaron gustando ciertas decisiones de diseño en Scheme (minimalismo, Lisp-1...) y la potencia/ubicuidad de Clojure.

Y sí, el estándar ha dejado congelado el lenguaje pero si no se revisa es porque la mayoría de los que lo hicieron pasan de CL. Han migrado a otros lenguajes (¿no se fue uno de ellos al review board de Scheme?) y han dejado a CL morir en su propia podredumbre xD

PD: Ojo, buscando en Wikipedia si recordaba correctamente lo de que había gente de CL en el review board de Scheme he encontrado esto:

"It had a significant influence on the effort that led to the development of its sister, Common Lisp."

¡Lisp es HEMBRA! (o al menos CL)

eisenfaust

Lisp es hermafrodita y homoicónico.

Clojure es un travelo con Java Stack Traces sin operar xD

1
eisenfaust

Otro Lisp en el explorador. Recomendadísimo ver el vídeo.

http://ss-lisp.net/

El editor parece ser este: http://www.ymacs.org/

1 1 respuesta
elkaoD

#37 oh, mola. Esa librería es como Logo.

Añado algún REPL (que no entorno completo):
www.repl.it
http://lotrepls.appspot.com/


Por cierto, una duda que llevo unos días dándole vueltas. Ya van varias veces que quiero implementar un Chain of Responsibility pero no se me viene a la cabeza como hacerlo bien sin currarme yo la iteración en el handler a mano.

Mi idea es algo así como un reduce pero que se pueda controlar el corte (es decir, cuando quiero consumir el evento, que no siga) además que de veo reduce un poco demasié para esto (técnicamente no quiero reducir a un elemento, sólo scanear hasta un cierto punto de corte que además puede no llegar.)

No se me ocurre ninguna forma real de hacerlo sin hacer yo mi propio "dispatcher". ¿Es aquí donde entran en juego las mónadas?

Mi empeño en no montarme el dispatcher es no reinventar la rueda. Si por cada vez que tengo que hacer algo parecido (no sólo para CoR) tengo que implementarlo... apaga y vámonos.

1 respuesta
eisenfaust

#38 Hmmm, si te he entendido bien y lo quieres hacer con un reduce...

;; Definimos nuestro wrapper.
(defn wrapper [function-1 function-2]
  (fn [data]                           ; Devolvemos closure.
    (when (function-1 data)            ; De devolver function-1 algo false,
      (function-2 data))))             ;  aquí terminaría nuestra cadena.

;; Definimos nuestra cadena, con un pipeline de varias funciones que ya
;; tengamos predefinidas.
(def our-chain (reduce wrapper [my-fn1 my-fn2 my-fn3]))

;; Lo llamamos como una función normal.
(our-chain (range 1 (inc 10)))

De esta forma, estaríamos llamando continuamente al pipeline de funciones hasta que la cadena termine o una de éstas devuelva false.

Es algo limitado ya que hay que trabajar con booleans y no sé si es lo que buscas xD

Échale de todas formas un vistazo a la función comp del core, que fijo que con un pequeño hack sobre ésta lo tienes.

1 respuesta
DantePD

Que envidia me dais los programadores!

Yo me pierdo con Java : ((((((

1 respuesta
eisenfaust

#40 Yo también xDD

DantePD

Yo creo que mi problema es que no veo como lo que aprendo se convierte en un programa...

1 respuesta
elkaoD

#39 algo así es lo que tengo sólo que con loop-recur en lugar de reduce (para evitar stackoverflow) y devolviendo o un valor de guarda (:consumed) o el dato a seguir procesando. ¡Es que no me puedo creer que no haya un patrón así ya inventado! Si tengo que andar hackeando es que algo va mal.

Esto tiene un problema gordo y es el trabajar con varios argumentos: hay que hacer un vector intermedio de los argumentos originales y luego llamar con apply (el código ya se va complicando.)

Además está muy limitado: sólo puedo tener una implementación y tengo que repetir y repetir código si quiero cambiar el flujo del proceso. Por ejemplo, ¿qué hay si quiero cambiar el valor de guarda? ¿Y si quiero añadir algún otro tipo de excepción? ¿Y si quiero apilar varias de estas cadenas de procesamiento? Desde luego que puedo pasarle todo esto en cuanto construya el procesador pero, ¿no se parece esto mucho a una mónada?

Vamos, que cada nueva opción complica el código un poco más y me da la sensación de que reinvento la rueda. En resumen: tal y como lo describo se me parece demasiado a las mónadas pero con muchas limitaciones.

Con comp es muy parecido sólo que no puedo evitar el stack overflow y además tengo que wrappear las funciones para que no llamen a la función real si ha llegado al valor de guarda. Además así no para, sólo "pasa por encima" de las funciones (que es lo que pretendo evitar.)

#42 eso sólo se aprende... programando! :P

20 días después
eisenfaust

Está un poco parado esto... Pongo algunas noticias funcionales.

  • Aparición de Alonzo Church en un restaurante de comida rápida:

  • Se publica el libro "Haskell and Yesod". Disponible gratuitamente en su web. Ando peleándome con él últimamente y creo que no me llamaba tanto un framework web desde Sinatra y Mojolicious.

http://www.yesodweb.com/book

Lamentablemente es algo avanzado y no hay mucha documentación para newbies.

Un buen tutorial: http://yannesposito.com/Scratch/en/blog/Yesod-tutorial-for-newbies/

  • Actualización de Haskell Platform. Compatible con los tres OS primarios. Personalmente me parece una de las mejores main pages que he visto.

Decir que el soporte hacia Windows ha mejorado una barbaridad en los últimos años. Antes petaban la gran mayoría de instalaciones en cabal, ahora apenas ocurre.

http://hackage.haskell.org/platform/

  • Egg de gónadas (perdón, mónadas) para Chicken Scheme.

http://wiki.call-cc.org/eggref/4/monad

2
eisenfaust

Por cierto, de cara a un proyecto personal, ¿Qué veis más molón en cuanto a pattern matching?

En plan Shen...

(define fact
    0 -> 1
    X -> (* X (fact (- X 1))))

Algo más Schemer...

(define (fact 0) 1)
(define (fact x) (* x (fact (- x 1))))

O siguiendo más la herencia Erlang / Prolog, sin utilizar define. Ejemplo de una sesión (Nótese que las "variables" empiezan con mayúscula y atoms y funciones en minúscula):

Name
;=> nil

(Name "eisen")

Name
;=> "eisen"

fact
;=> fact

(fact 5)
;=> undefined blablabla fact

((fact 0) 1)

((fact X) (* X (fact (- X 1))))

(N 5)

(fact N)
;=> 120

((fact 2) 11.1)

(fact N)
;=> 666

Edit: Tras pensarlo un rato la tercera no es viable. Me quedo con la segunda xD

13 días después
eisenfaust

Excelente recurso para novatos en Common Lisp http://lisp.plasticki.com/

Los ejercicios están bastante bien.

Experienced Lisp programmers may say that there are built-in Lisp procedures that will achieve far more succinctly and efficiently what I have achieved in some of the example programs here.

My defence is that the point of these tutorials is not to teach Common Lisp in its entirety, but to help the reader understand the general principles of programming in Lisp. I believe that it is daunting for a beginner to be confronted with a catalogue of Lisp procedures to learn by rote. It is far more important to understand how to approach a problem, and break it down into simpler problems with the help of recursion.

1 comentario moderado
1 mes después
zildjian

A Coursera se han añadido muchísimos cursos, entre ellos uno de programación funcional en Scala por su mismísimo creador.

Empieza en septiembre así que os podéis ir apuntando si queréis ;-)

Razón aquí

eisenfaust

Scala no me parece el lenguaje más indicado para aprender FP, pero se le echará un ojo al curso.

1 respuesta
elkaoD

#49 por la TOC se limita a conceptos funcionales: inmutabilidad, colecciones, pattern matching...

Supongo que han elegido Scala por la sintaxis Javalike (para dar menos miedo) y porque ahora es trendy.


Aprovecho la noticia ya que tiene que ver:

Llevo un tiempo dándole vueltas a hacer un screencast de introducción a Clojure, que ya sé de algún compañero de clase que le llama la atención pero no se pone a ello por no pegarse con la documentación sin "profesor". ¿Alguien estaría interesado? Mi idea es hacerlo en plan participativo, con preguntas del público según voy haciendo el cast.

Con que se apunte uno ya me vale (total, luego puedo subir el video por si a alguien más le interesa.)

eisenfaust

Hombre, hace poco Emerick subió un screencast bastante chulo llamado Starting Clojure y la verdad es que no se dejó nada en el tintero.

¿Supongo que el tuyo estaría en castellano? De ser así seguramente le interese a alguien.

1 respuesta
elkaoD

#51 en efecto, he visto MUY poco material de Clojure en castellano y un screencast introductorio me ha parecido bien para quitar los miedos a la gente y que empiecen a cacharrear, aunque sea toquetear el REPL e ir cogiéndolo el "feeling".

Parece una tontería pero un REPL (y tan versátil como el de Clojure) es una gran herramienta que mucha gente se pierde (fuera de la PF, de uso común creo que sólo Python... y Node, que no cuenta porque es raruno.)

1 mes después
B

#1: Podrías añadir esto a lo de Scala: https://www.coursera.org/course/progfun

Yo voy a seguirlo a ver qué tal. Parece ser que el profesor es el diseñador de Scala.

#54: Estoy de acuerdo contigo en todo lo que dices, de hecho yo estaba siguiendo uno en Udacity y lo llevo muy de poco en poco.

La cosa es que en mi caso viene bien porque aunque no es la mejor forma de aprender ni de lejos, es una forma bastante amena y motivante, al menos para los primeros pasos.

Yo la seguiré muy posiblemente, con mucha calma. Luego, si me gusta, entonces es cuando me pillo libros y me rompo la cabeza.

Si alguien quiere seguir la clase conmigo, que avise ;)

PD: Btw, es muy graciosa la nota en amarillo en el CV de Norvig http://www.norvig.com/resume.html xDDDD

1 respuesta
eisenfaust

#53 Se podría hasta hacer un grupo de estudio. Aunque dudo que contéis conmigo.

A mi personalmente todos estos cursos que he visto tanto de Udacity como Coursera me han parecido una chapuza. Tienes un montón de vídeos para explicarte cualquier chorrada y luego en otros se quedan cortos, siempre se dejan cosas y el sistema de examinación de Coursera en plan quiz es horrible. Por no hablar de que a nada que tengas un curro o responsabilidades familiares fallas la deadline y todo pierde la gracia xD

Al final siempre te sale mejor leer un buen libro sobre la materia y dedicarle las horas y el esfuerzo que quieras. Yo por ejemplo tuve muchas ganas de empezar el curso de Norvig en Udacity y lo terminé dejando (principalmente por la interfaz y la elección del lenguaje). Y estamos hablando del autor de PAIP que es posiblemente uno de los mejores libros que se han escrito sobre computación.

Pero bueno, entiendo que eso de que te den un papelito al final le llame la atención a más de uno, aunque al final no sirva para nada xDDD

2 2 respuestas
BLZKZ

yo lo seguiré también xD, a ver si lo termino

por lo que dice #54 es que dan diploma? wtf

#56 para mi no vale nada ninguno, los que estan "firmados por el rey" tampoco xD

2 respuestas
B

#55: Eso no vale para nada xD

Los firmados por el Rey sí que valen, si no te cuento como me descartaron de un proceso de selección por ser I.T y no I.I, y eso que estaba recomendado por gente de dentro xD

#57: Yo no he aplicado esa lógica, digo que a veces pasa. Hay empresas que lo requieren sí o sí, solo eso.

Respecto a lo de que dices de la forma de aprender, estoy de acuerdo, y es lo que comentaba antes. Aprender, aprendes más cogiéndote un libro. Si no quieres tomártelo tan en serio, pues tienes estos cursos.

Pero estos cursos lo que tienen de bueno es que es una forma fácil de meterte con algo. El título no vale para nada (si ya no vale la carrera según vosotros, menos va a valer un curso de 100 horas por vídeo con ejercicios fáciles como son los de Udacity, por ejemplo), pero sí que valen los conocimientos (que, como siempre, es lo realmente importante).

3 respuestas
RandomNick

#56 Curiosa la lógica de "Me ocurrió a mi, así que debe de suceder siempre".

#55 Creo que puedes examinarte en algunos sitios por un precio para que te lo den. El caso es que no están digamos regulados por ninguna ley, lo que enseñan no está reconocido en ningún lado, así que depende de la persona que te contrate. Si sabe lo que es Udacity y le gusta, lo valorará.

Evidentemente, siendo un proyecto con tan poco tiempo, mucha suerte tendrías que tener para entrar en un sitio donde si lo conozcan, al menos en España. Tal vez, con el tiempo, tenga mucho más reconocimiento. De momento solo puede ir a mejor.

De todos modos hay que valorarlo por lo que es. Evidentemente, coger un libro denso sobre la materia te puede aportar mucho más. Pero los cursos de Udacity son mucho más didácticos que cualquier libro. No digo que tengan más sabiduría, pero hacen que aprender sea más fácil que leerte un libro de 700 páginas sobre lo que sea.

2 respuestas
BLZKZ

#57 la lógica de #56 la aplica en tanto en cuanto en muchas empresas en España se hace así, incluso en empresas de fuera afincadas aquí, aunque se está intentando cambiar esa mentalidad, pero todo depende del director de HR y de Recruitment.

Está claro que luego a tu "jefe", en un departamento técnico le suda las pelotas los títulos mientras seas muy bueno en lo que pide, pero en HR hacen así las cribas, es lo que hay.

eisenfaust

xDDDD

1
BLZKZ

el de haskell xdddddddddddddddd

Usuarios habituales