Ruby vs Python (era: Comentarios sobre web frameworks)

[Chema Cortes]

Esteban Manchado Velázquez escribió:

>    Sobre lo de la herencia múltiple, comentar que la técnica de Mixin (que
> tengo entendido que se puede hacer en Python, pero en Ruby se usa mucho)
> permite hacer las cosas más comunes que se buscan con herencia múltiple (y en
> opinión de algunos, de manera más clara).

Aunque a nivel simple hay quien usa la herencia múltiple para hacer
"mixin" de interfaces, la herencia múltiple permite crear wrappers
(decoradores, pre y postcondiciones, ...) así como algunos
"malabarismos" con metaclases que, sin tener aún demasiada experiencia
con ruby, no sabría hacer que quedase más claro sin herencia múltiple.

>    Lo de cargar módulos dinámicos no lo entiendo, ¿a qué te refieres? ¿En
> Python no puedes hacer "import foo" y que "foo" sea un "foo.so" en algún
> sitio?

Me refería al ruby-dl, a que puedes cargar una dll del sistema y acceder
a ella directamente. En python tienes que cargar una librería glue que
haga de conexión entre python y la librería dinámica.

>    1) Normalmente en Ruby todo lo programas orientado a objetos, con lo que
> ese caso no es muy común (los «atributos» del objeto serían «@a», no «a», que
> sería una variable local). Y como no se puede acceder desde fuera a los
> atributos de un objeto (sólo se puede llamar a métodos), sabes positivamente
> que todo lo que se llamaría desde fuera serían siempre métodos.
>    2) El principal problema de legibilidad y mantenimiento de ese trozo de
> programa, es, precisamente, llamar de la misma manera a dos cosas distintas
> :-) No veo la ventaja de que se pueda hacer lo que tú esperas, tal como lo
> haces: normalmente en Ruby eso serían métodos, no variable y funciones (o
> atributos llamables o no, en mentalidad Python), y redefinir métodos es
> trivial, así que seguramente el ejemplo no es muy real...

No estaba poniendo ningún caso real ;-)
Cuando hablaba de "verrugas" me refería a que en los lenguajes de
programación hay cosas que son propensas a malinterpretarse. Casi
siempre se pueden evitar con unas adecuadas reglas de estilo (como
indicar siempre explícitamente quiénes son los atributos de instancia ó
de clase).