lunes, abril 30, 2007

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

miércoles, abril 18, 2007

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:

Y algunos enlaces más

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

martes, abril 17, 2007

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 :)

Ahora en inglés. De David Heinemeier Hansson: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 ;)

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

martes, abril 10, 2007

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:

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

lunes, abril 02, 2007

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