sirve - ruby tutorial
Si la gente de Java va a Scala, C#va a F#, ¿a dónde van las personas de Ruby para el nirvana funcional? (7)
Cualquier versión de Lisp debería estar bien.
Sé que mucha gente de Java ha comenzado a buscar en Scala ya que se ejecuta en la JVM, y mucha gente en el mundo de Microsoft está mirando F #, pero ¿qué tiene Ruby como un sucesor funcional natural?
En un sentido puro de FP, a Ruby no le falta nada, en cambio tiene mucho que decir. Un lenguaje funcional obliga al programador a no usar tanto las variables globales y otras expresiones idiomáticas (aunque es posible usar variables globales en los lenguajes funcionales)
En el nivel de bombo, Haskell.
Hay dos definiciones muy diferentes de lo que significa "programación funcional". Puedes hacer uno de Ruby, pero no puedes hacer el otro.
Esas dos definiciones son:
- programación con funciones de primera clase y
- Programación con funciones matemáticas
Puede programar algo con funciones de primera clase en Ruby. Tiene soporte para funciones de primera clase. De hecho, tiene demasiado soporte para ellos: hay Proc.new , proc , lambda , Method , UnboundMethod , blocks, #to_proc y ->() (y probablemente algunos otros que no recuerdo).
Todos estos se comportan de forma ligeramente diferente , tienen una sintaxis ligeramente diferente, un comportamiento ligeramente diferente y restricciones ligeramente diferentes. Por ejemplo: el único de estos que es sintácticamente lo suficientemente ligero como para poder usarlo densamente, es bloques. Pero los bloques tienen algunas restricciones bastante severas: solo se puede pasar un bloque a un método, los bloques no son objetos (lo que en un lenguaje orientado a objetos en el que "todo es un objeto" es una restricción muy severa) y al menos en Ruby 1.8 también hay algunas restricciones wrt parámetros.
Referirnos a un método es otra cosa bastante incómoda. En Python o ECMAScript, por ejemplo, puedo decir baz = foo.bar para referirse al método de bar del objeto foo . En Ruby, foo.bar es una llamada a método, si quiero referirme al método bar de foo , tengo que decir baz = foo.method(:bar) . Y si ahora quiero llamar a ese método, no puedo simplemente decir baz() , tengo que decir baz.call o baz[] o (en Ruby 1.9) baz.() .
Por lo tanto, las funciones de primera clase en Ruby no son realmente de primera clase. Son mucho mejores que los de segunda clase, y son lo suficientemente buenos ™, pero no son completamente de primera clase.
Pero en general, los Rubyists no dejan a Ruby solo para las funciones de primera clase. El apoyo de Ruby es lo suficientemente bueno como para que cualquier ventaja que pueda obtener de un mejor soporte en otro idioma sea consumida por el esfuerzo de capacitación para el nuevo idioma o por alguna otra cosa a la que esté acostumbrado a la que ahora deba darse por vencido. Como, digamos RubyGems o integración ajustada de Unix o Ruby on Rails o sintaxis o ...
Sin embargo, la segunda definición de FP es cuando Ruby cae de bruces. Si quieres hacer programación con funciones matemáticas en Ruby, te espera un mundo de dolor. No puede usar la mayoría absoluta de las bibliotecas de Ruby, porque la mayoría de ellas son estables, efectivas, fomentan la mutación o, por lo demás, son impuras. No puede usar la biblioteca estándar por las mismas razones. No puedes usar la biblioteca central. No puede usar ninguno de los tipos de datos principales, ya que son todos mutables. Podrías decir "No me importa que sean mutables, simplemente no los mutaré y siempre los copiaré", pero el problema es que alguien más puede mutarlos. Además, debido a que son mutables, Ruby no puede optimizar la copia y el recolector de basura no está sintonizado para ese tipo de carga de trabajo.
Simplemente no funciona.
También hay un par de características que realmente no tienen nada que ver con la programación funcional, pero que la mayoría de los lenguajes funcionales tienden a tener, que Ruby se está perdiendo. Coincidencia de patrones, por ejemplo. La pereza también no era tan fácil de lograr antes de que los Enumerator se usaran más agresivamente en Ruby 1.9. Y todavía hay algunas cosas que funcionan con Enumerable s o Array s estrictos, pero no con Enumerator s perezosos, aunque en realidad no hay ninguna razón para que requieran rigor.
Y para esta definición de FP, definitivamente tiene sentido dejar atrás a Ruby.
Los dos lenguajes principales a los que los rubyistas han acudido en masa son Erlang y Clojure . Ambas son coincidencias relativamente buenas para Ruby, ya que ambas son de tipo dinámico, tienen una cultura REPL similar a Ruby, y (esto es más una cosa de Rails que de Ruby) también son muy buenas en la web. Todavía tienen comunidades bastante pequeñas y acogedoras, los creadores de idiomas originales aún están activos en la comunidad, hay un fuerte enfoque en hacer cosas nuevas, emocionantes y vanguardistas, todos los cuales son rasgos que también tiene la comunidad de Ruby.
El interés en Erlang comenzó cuando alguien mostró el video de presentación original de 1993 " Erlang: The Movie " en RubyConf 2006. Un par de proyectos de alto perfil de Rails comenzaron a usar Erlang, por ejemplo PowerSet y GitHub . Erlang también es fácil de dominar para los Rubyistas, ya que no lleva la pureza tanto como Haskell o Clean . El interior de un actor es bastante puro, pero el acto de enviar mensajes en sí mismo es, por supuesto, un efecto secundario. Otra cosa que hace que Erlang sea fácil de entender, es que los actores y los objetos son en realidad lo mismo, cuando se sigue la definición de Alan Kay de programación orientada a objetos .
Clojure ha sido una adición reciente al cinturón de herramientas del Rubyist. Su popularidad se debe principalmente a que la comunidad de Ruby finalmente se entusiasmó con la idea de que JVM ≠ Java y abrazó a JRuby y luego comenzaron a mirar a su alrededor qué otras cosas interesantes había en la JVM. Y nuevamente, Clojure es mucho más pragmático que los otros lenguajes funcionales como Haskell y otros Lisps como Scheme y mucho más simple y más moderno que CommonLisp, por lo que es una opción natural para los Rubyistas.
Otra cosa interesante de Clojure es que, como Clojure y Ruby se ejecutan en JVM, puedes combinarlos .
El autor de " Programming Clojure " (Stuart Halloway) es un (¿antiguo?) Rubyist, por ejemplo, como lo es Phil Hagelberg , el autor de la herramienta de construcción Leiningen para Clojure.
Sin embargo, los Rubyists también están mirando tanto a Scala (como uno de los lenguajes FP más pragmáticos y estáticos) como a Haskell (como uno de los más elegantes). Luego hay proyectos como Scuby y Hubris, que son puentes que te permiten integrar a Ruby con Scala y Haskell, respectivamente. La decisión de Twitter de trasladar parte de su infraestructura de mensajería de bajo nivel primero de MySQL a Ruby, luego de Ruby a Scala también es bastante conocida.
F # no parece jugar ningún papel en absoluto, posiblemente debido a un miedo irracional hacia todas las cosas que Microsoft tiene en la comunidad de Ruby. (Lo cual, por cierto, parece ser infundado, dado que el equipo de F # siempre ha hecho versiones disponibles para Mono).
Las personas de Java están usando un lenguaje en la JVM y quieren una más funcional compatible con su tiempo de ejecución, por lo que van a Scala.
Las personas C # están usando un lenguaje en el CLR y quieren un más funcional compatible con su tiempo de ejecución, por lo que van a F #.
Las personas de Ruby están usando un lenguaje que ya es bastante funcional, y lo están usando en varios tiempos de ejecución subyacentes (JRuby, IronRuby, MRI, MacRuby, Rubinius, etc.). No creo que tenga un sucesor funcional natural, ni siquiera necesita uno.
Ruby it self es una especie de lenguaje de programación funcional, así que no veo ningún dialecto especial para FP usando ruby.
Ruby no es tan funcional como dice Lisp, pero es lo suficientemente funcional como para que puedas hacer una programación funcional de una manera divertida. (a diferencia de tratar de hacer programación funcional en algo como C #)
Además, en realidad te obliga a utilizar paradigmas funcionales en algunas de sus sintaxis, como el uso intensivo de bloques y el rendimiento. (que me enamoré después de aprender Ruby).
Suponiendo que la gente de Ruby no vaya solo a la JVM, creo que la mayoría adoptaría Erlang, que es otro lenguaje de tipado dinámico.