Entrevista sobre YARV

Vía la sección de reddit de programación (que a pesar de su sistema de filtrado y puntuación, también tiene el mal del exceso de información... ) he encontrado una serie de entrevistas sobre la nueva máquina virtual que ejecutará Ruby: YARV. Responden las dos personas más involucradas en ello, Matz (recordemos, el creador del lenguaje) y a Koichi Sasada, el desarrollador principal.

En la segunda parte de la entrevista se habla de las distintas implementaciones de los entornos de ejecución de Ruby. Por resumir, Koichi dice: "Necesitamos especificaciones, buenos test y buenos benchmarks". Por las bitácoras de barrapunto se ha hablado de ello, porque Robert h Quinn está trabajando en los test, según comentaba en GSoC 2007 : De que va mi proyecto

Sobre todo me ha gustado la tercera parte, sobre el pasado el presente y el futuro de los threads en Ruby.En esta parte se argumentan las razones por las que se abandonó la implementación de threads en espacio de usuario por el uso de los threads nativos del sistema, además de explicar como eso afecta el soporte de continuaciones.
(Hablamos de estas cosas hace unos meses en Noticias sobre Ruby 2.0 (que al parecer no son sobre 2.0 estrictamente...)

Actualización: Como me comenta Robert h Quinn, en On Ruby tienen una serie de entrevistas a los desarrolladores de distintas implementaciones de entornos de ejecución de Ruby. Más para leer...

"Entrevista sobre YARV" en barrapunto

Programando con Erlang

Dave Thomas ha escrito una serie de apuntes introductorios a erlang, aprovechando el nuevo libro, Programming Erlang de Joe Armstrong (un esfuerzo publicitario, porque el libro se publica bajo el amparo de los programadores pragmáticos, pero aquí nos da igual, ¿no?)

Entonces pasemos a los enlaces:

• A First Erlang Program Un programita para usar la API de servicios web de amazon
• Adding Concurrency to Our Erlang Program El mismo programa, pero concurrente

Y algunos enlaces más

• What's all this fuss about Erlang?
  por Joe Armstrong, una introducción al lenguaje
• Concurrent Programming in Erlang, Part I (pdf 884 KB) un libro introductorio con el que estuve trasteando hace un tiempo, también de Armstrong (entre otros)

Publicitado también desde los programadores pragmáticos... ¿le pasará lo mismo que a Ruby? ¿tendrá el mismo crecimiento? Personalmente lo dudo, a pesar de que el lenguaje tiene unas características muy interesantes, entre otras el tratamiento de la concurrencia. La principal pega la comenta el propio Armstrong en el artículo introductorio: ¿Es Erlang difícil? No, pero es diferente.

(Se habló en barrapunto de él hace bastante tiempo en Otro lenguaje de programación: Erlang)

Programando con Erlang en barrapunto

Twitter, RoR, escalabilidad y flames

Ha sido imposible escapar al contrahype: un desarrollador de twitter, el servicio webdospuntocero de moda (¿o ya no está de moda?, no sé, a mi que no me pregunten, que yo en estas cosas estoy muy démodé), Alex Payne, declaró que Ruby on Rails no escala, que tiene un cuello de botella en la base de datos (comentado en barrapunto en Entrevista con Alex Payne, uno de los desarrolladores de Twitter) y se desató el multiflame. Debido a la relevancia y al ruido conseguido por los fans de RoR parece que se les tenía ganas... El hecho es que se ha levantado una polvareda de bytes bastante importante, lo que en estos tiempos significa una conversación fragmentada de post cruzados en muchísimos blogs y alguna lista de correo, que aún quedan :)

Tengo que reconocer que me gustan los flames, sobretodo si no me tocan de cerca, porque en general y con un poco de suerte, de tanto ruido se puede extraer información interesante...

Aunque, debo confesar, esta vez me ha sorprendido que la onda expansiva ha llegado hasta la blogosfera hispana, cosa que no suele ser usual... Primero pues, los enlaces en castellano. Ah, seguro que me dejo algo, se admiten sugerencias de enlaces interesantes :)

• Ricardo Galli: Los problemas de Twitter (y la escalibilidad)
• Un muy reciente La polémica sobre la escalabilidad de Rails (tan reciente que lo ha escrito mientras yo redactaba esto y que es un buen resumen y además apunta posibles soluciones...) de Sergio Gil (porras), aunque ya dejó algún mensaje interesante en barrapunto: La escalabilidad de Rails
• rvr ya hizo referencia hace casi un año a un artículo, Does Rails Scale Down? que pone de manifiesto el posible peligro.
• "Los dolores de Ruby on Rails" en la lista de correo ror-es

Ahora en inglés. De David Heinemeier Hansson:

• Twitter trouble. Primera reacción de DHH (Parodiada en DHH translation con mucha acidez. Puro flame.)
• Scaling to multiple databases with Rails Solución rápida a la conexión a distintas bases de datos con rails

Ha habido respuesta de diversa índole, pero se pueden rastrear fácilmente. Solo voy a resaltar alguna que se va por las ramas, que son las que más me interesan ;)

• Is platform selection premature optimisation? ¿cuando se empieza a optimizar? Dice el dicho, comentado ahora mismo en la bitácora de fernand0, que Primero haz que funcione, segundo hazlo elegante y después hazlo que sea rápido Y estoy completamente de acuerdo, pero a twitter el tercer paso le vino demasiado rápido, me temo... O sea ¿cuando llega el momento de optimizar?
• Twitter and Rails brouhaha Sobre la conveniencia de evaluar lenguajes y frameworks separadamente
• Actualización: Me olvidé de poner uno interesante "Reddit: Language vs. Platform" en Coding Horror, en el que se recuerda el caso reddit con interesantes lecturas también...

Dice Juan Lupión en "sobre railes" que permanezcamos a la escucha. Desde luego, un flame es un flame ;)

Twitter, RoR, escalabilidad y flames en barrapunto

Orientación a objetos: algunas críticas

Vía Reddit me he encontrado con un escrito, intencionadamente provocador diría yo, de Joe Armstrong (de nuevo): Why OO Sucks. No obstante me gustaría resaltar los argumentos, que dan que pensar y para eso estamos aquí:

• Las estructuras de datos y las funciones no deberían ir juntas:
  Esto es una característica en principio ventajosa de la POO, pero puede ser una servidumbre, además de que no deja aprovechar algoritmos genéricos al estilo de C++ con la STL. No obstante hay que decir que variaciones de la programación orientada a objetos permiten el Duck typing, como en python o ruby que favorece la posibilidad de hacer algoritmos más genéricos...
• Todo debe ser un objeto:
  Relacionada con la anterior, todo dato debe ser un objeto y tener la parafernalia necesaria para serlo. En esto los lenguajes van mejorando, creo yo, reduciendo lo necesario para ser objeto, a veces haciéndolo implícito.
• La estructura de datos está dispersa por todos lados:
  Y no le falta razón. Esto es particularmente importante si las estructuras de datos van a ser usadas para hacer la interoperabilidad entre sistemas heterogéneos
• Los objetos tienen un estado privado:
  Esta es una crítica muy desde la perspectiva de la Programación funcional (bueno, las otras también...) pero muy interesante. La primera vez que oí eso de que en Erlang (por ejemplo) no se podía reasignar variables me resultó muy chocante, pero ver hacer las cosas de un modo diferente es muy ilustrativo a veces... Es el "truco" de estos lenguajes de no usar el estado para evitar efectos laterales, muy relevante también para programación concurrente.
  

Mi opinión sobre el tema ya la expresé en ¿Ha muerto la orientación a objetos?: Conceptos como encapsulamiento, interfaces, reusabilidad pueden seguir siendo útiles, pero hay que evaluar el impacto positivo, no sea que matemos moscas a cañonazos...

Y ahora una serie de enlaces sobre el mismo tema:

• Object-Oriented Considered Harmful
• OOP Is Much Better in Theory Than in Practice Una crítica desde el punto de vista del programador de a pie, comentado en lambda the ultimate y The Server Side
• ¿Porque ARC no es especialmente orientado a Objetos? por Paul Graham
• Listado de críticas a la orientación a objetos en dmoz que enlaza a un muy interesante Objects Have Failed de Richard P. Gabriel
• Software Reusability: Myth Or Reality? Una de las supuestas ventajas de la OO es la reusabilidad, pero ¿es posible conseguirla?
• Y por fin algo por contrastar: Invasion Of The Dynamic Language Weenies como respuesta a los fans forofos de los lenguajes dinámicos...

"Orientación a objetos: algunas críticas" en barrapunto

Entrevistas a gurús de la programación paralela

En el estupendo blog Thinking Parallel, se ha comenzado una serie muy prometedora, entrevistas a gurús de la programación paralela, gente que ha diseñado sistemas que la soportan, la facilitan y/o la potencian: Joe Armstrong de Erlang, William Gropp de MPI, Sanjiv Shah de OpenMP, David Butenhof de los threads POSIX (de quien ya se ha hablado por aquí en Diseño sencillo contra implementación correcta) Además promete intentar entrevistar a los responsables de los threads de la JVM y del .NET framework. Las entrevistas son por correo y tienen la particularidad de que son las mismas para todos ellos, cinco preguntas sobre el la programación paralela en general y cinco preguntas sobre su sistema en particular.

De momento ha publicado ya dos, muy interesantes: Ten Questions with Joe Armstrong about Parallel Programming and Erlang y Ten Questions with William Gropp about Parallel Programming and MPI.
Actualización: Se ha publicado la tercera entrega: Ten Questions with Sanjiv Shah about Parallel Programming and OpenMP

Extractando. Joe Armstrong:

• Sobre balas de plata: Si, las infraestructuras puras de paso de mensajes resolverán muchos problemas (cosas como el servicio de cola simple de amazon(?)). Es una vuelta a la programación basada en flujo de Paul Morisson
• Comparando la programación paralela con la secuencial: No es más difícil - es difícil debido al modelo dominante de bloqueos, threads y memoria compartida, que si es dificil. Los sistemas puros de paso de mensajes son más fáciles de programar y de comprender

William Gropp (más pragmático al parecer):

• Sobre mensajes contra memoria compartida: Ambas tienen virtudes y defectos. El paso de mensajes traspapasa la gestión de las estructuras de datos distribuidas al programador. La memoria compartida requiere un gran cuidado para evitar condiciones de carrera y bugs de rendimiento (como la falsa compartición). Ninguno es un modelo de programación completo. Hemos tenido y seguiremos teniendo acaloradas discusiones(*) sobre las deficiencias de ambos.

(*)también conocidas como flames :)

Actualización: Sanjiv Shah:

• Ahondando más en el tema de paso de mensajes contra memoria compartida:Decidir cual es apropiada depende muchísimo de la aplicación: la memoria compartida facilita unas cosas y la memoria distribuida otras. SETI@home es ahora el ejemplo clásico: apenas se comparten estados entre todos los ordenadores que están ejecutándose a lo largo del mundo independientemente. Muchas aplicaciones de este estilo usan memoria distribuida de modo natural. Por otra parte cuando hay muchos cambios de estado que se deben compartir, el uso de memoria compartida tiene mucho sentido.

Entrevistas a gurús de la programación paralela en barrapunto