Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Escogiendo un lenguaje de alto nivel

osoh's Diary
Por osoh
departamento pito-pito-colorito , Sección Diarios
Puesto a las Wed Jan 28th, 2004 at 06:11:08 PM CET

Estoy interesado en empezar a hacer desarrollos sobre Qt utilizando algún lenguaje del estilo de Python o Ruby, pero tengo una duda acerca de cuál escoger.

 


Ni que decir tiene que Python es uno de los lenguajes de moda. Tiene una comunidad de usuarios bastante extensa y "bindings" para todas las bibliotecas habidas y por haber. Además, cuenta con una documentación bestial. Pero sin ánimo de ofender, su orientación a objetos no me parece ninguna maravilla. Y si no, les invito a que lean cómo funciona el tema de los atributos privados :-P

El otro candidato es Ruby. Se trata de un lenguaje muy elegante (sí, ésta es una afirmación muy subjetiva), con una orientación a objetos realmente buena. ¿Sus "peros"? La documentación no es del todo completa (la buena está en Japonés... y no está entre mis prioridades aprender éste lenguaje) y no sé hasta qué punto es completo y estable el binding para Qt.

Además, no sé hasta qué punto se trata de un lenguaje escalable.

Así que, mientras me debato entre uno u otro, me gustaría conocer la opinión de los libertonianos y, de paso, preguntar si alguien conoce algún otro lenguaje de características similares que sea maduro para un entorno de producción.

< Llamada a votación para crear es.comp.os.unix (11 comments) | Primeros pasos de la lista de ayuda de Mozilla en español (3 comments) >
Enlaces Relacionados
· Python
· Ruby
· More on osoh's Diary
· Also by osoh

Encuesta
¿Utilizas habitualmente "lenguajes de script"?
· Perl rulez 19%
· Por supuesto, Python 19%
· PHP sirve para todo 7%
· Soy uno de los pocos que tira de Ruby 14%
· ¿Lenguajes de alto nivel? C 35%
· Te olvidaste de... 4%

Votos: 42
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Escogiendo un lenguaje de alto nivel | 18 comentarios (18 temáticos, editoriales, 0 ocultos)
Por una vez, no a Ruby :) (none / 0) (#1)
por davinci (davinci at ecol org) a las Wed Jan 28th, 2004 at 10:50:58 PM CET
(Información Usuario)

Me encanta Ruby, pero eres lo bastante específico acerca de tus intenciones como para que no pueda recomendártelo en esta ocasión.

Las extensiones para Qt son de las más inmaduras que existen para este lenguaje y sólo hay versiones para Qt 1.x y Qt 2.x.

Otra cosa sería que intentases programar algo para Gtk2. En ese caso te recomendaría Ruby sin dudarlo, por grande que fuese el proyecto.

Pero tu caso es bien diferente. Supongo que Python puede resultar una buena alternativa, pese a esa "nada maravillosa orientación a objetos" ;)


¡Es la guerrrrrrra!


Hay binding para Qt3 (none / 0) (#2)
por osoh (imobachgs at softhome dot net) a las Thu Jan 29th, 2004 at 12:28:37 AM CET
(Información Usuario) http://www.banot.net/~imo/

Creo que, afortunadamente, ya hay binding para Qt3. Puedes encontrarlo en el CVS de KDE, más concretamente entre los "kdebindings".

Sin embargo, como bien comentas, no parece estar excesivamente maduro.

Gracias por tu sugerencia.
--
Que no haya pasión que no valga el mal que cien años dura (Enrique Bunbury)
[ Padre ]


No están en RAA (none / 0) (#3)
por davinci (davinci at ecol org) a las Thu Jan 29th, 2004 at 11:05:46 AM CET
(Información Usuario)

Me sorprende no encontrar ninguna referncia en el repositorio de módulos de Ruby. Quizá pronto formen parte de Kde y se estabilicen. Por lo que he podido comprobar, son unos bindings bastante completos, aunque supongo que inestables.

Si tuviese más tiempo les echaba un buen vistazo. Lo dejo pendiente 0:)


¡Es la guerrrrrrra!
[ Padre ]


Voy a echarle un ojo (none / 0) (#4)
por osoh (imobachgs at softhome dot net) a las Thu Jan 29th, 2004 at 03:56:53 PM CET
(Información Usuario) http://www.banot.net/~imo/

Yo les quiero echar un vistazo este fin de semana. Ya contaré por aquí qué es lo que averiguo acerca de este binding.

Saludos.
--
Que no haya pasión que no valga el mal que cien años dura (Enrique Bunbury)
[ Padre ]


 
¿y nuestro amigo el camello? (none / 0) (#5)
por jamarier a las Thu Jan 29th, 2004 at 08:22:18 PM CET
(Información Usuario) http://barbacana.net/blog/

Es curioso que aunque lo mencionas en la encuesta, despues no haces consideraciones sobre Perl en la entrada.

Ya me conozco las pegas que la gente le pone al Perl (aunque la mayoria de esas pegas son de gente que NO programa Perl, así que no es para tomarselas demasiado en serio).

Así que voy a comentar extrictamente las peculiaridades de Perl para programación QT:
  • Perl tiene un Binding para QT muy consolidado: PerlQT
  • PerlQT incluye las mismas clases que la librería QT original. Salvo que sustituye la Q inicial de las declaraciones por Qt:: Esto permite usar la documentación y referencias originales de QT para programar en PerlQT.
  • Perl es orientado a objeto.
  • La última versión de qt designer, te permite generar los Guis directamente en Perl.

-----
- Porque mañana será un gran día.



¿Perl orientado a objeto? (none / 0) (#6)
por preage a las Thu Jan 29th, 2004 at 10:58:40 PM CET
(Información Usuario) http://geocities.com/dariapra

Perl es orientado a objeto.

Yo apenas he cacharreado con Perl, y que yo sepa, no es un lenguaje orientado a objeto (OO). O mucho ha cambiado Perl en dos años o no me enteré de gran cosa en su día.

No sé si habrás querido decir que Perl tiene algún tipo de extensión que permita hacer programación OO. Digo esto porque Tcl, otro lenguaje de scripting, sí las tiene, como por ejemplo incr Tcl. En mi opinión, a pesar de extensiones así, decir que Tcl (o Perl) son lenguajes OO me parece un tanto exagerado.

Y si Perl es OO como lo son, por ejemplo, Java o Python, que los libertonianos me vayan corrigiendo...

[ Padre ]


Pues sí (none / 0) (#8)
por osoh (imobachgs at softhome dot net) a las Fri Jan 30th, 2004 at 12:29:34 AM CET
(Información Usuario) http://www.banot.net/~imo/

Aunque parezca mentira, Perl tiene objetos. Yo en su momento los probé para una práctica de clase, pero me no recuerdo por qué motivo no me gustaron. Así que decidí hacer aquello en Python.

Y si Perl es OO como lo son, por ejemplo, Java o Python, que los libertonianos me vayan corrigiendo...

No recuerdo qué tal era la orientación a objetos de Perl, pero hay una diferencia importante entre la calidad de la orientación a objetos de Java y la de Python ;-)

Venga, un saludo a todos.
--
Que no haya pasión que no valga el mal que cien años dura (Enrique Bunbury)
[ Padre ]


¿Cuál es la gran diferencia? (5.00 / 1) (#9)
por jorginius ("jorginius" en Google Mail) a las Fri Jan 30th, 2004 at 01:46:53 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

hay una diferencia importante entre la calidad de la orientación a objetos de Java y la de Python ;-)

Por curiosidad, entre la orientación a objetos de Java y la de Python ¿cuál es la diferencia importante?: ¿qué Python soporta herencia múltiple y Java no?, ¿la sobrecarga de operadores?, ¿el self?, ¿qué en Python es muy poco recomendable usar métodos de acceso para los atributos por la lentitud de las llamadas?, ¿la sobrecarga de métodos (en un lenguaje en que el tipo de los parámetros no se especifica)?, ¿qué?.

¿Te parece mal como se manejan los miembros de clase privados en Python?: si no te gusta la forma por defecto (a lo C++ sólo que en Python no hay un compilador que, sólo en tiempo de compilación, nos impida acceder a lo privado) puedes restringir el acceso a miembros y a métodos de una clase en tiempo de ejecución, si no por medio de Bastion, por lo menos sobrecargando el operador de acceso... Aunque no merece la pena: puedo prototipar mi código C++ en Python sin todo eso. Lo que no puedo hacer es prototiparlo sin sobrecarga de operadores o sin herencia, por decir algo, pero eso sí que me lo da el lenguaje: lo otro es opcional y más informativo que otra cosa.

Si al menos hubieses comparado con Smalltalk...

[ Padre ]


Las diferencias (none / 0) (#12)
por osoh (imobachgs at softhome dot net) a las Fri Jan 30th, 2004 at 01:16:30 PM CET
(Información Usuario) http://www.banot.net/~imo/

La gran diferencia entre una y otra orientación a objetos, es que la de Java es bastante más natural que la de Python. Me remitiré a un par de ejemplos para intentar demostrarlo.

Pasar el 'self' como parámetro

Hasta donde yo sé, cuando invocamos un método de una clase en Python, hay que indicarle explícitamente sobre qué clase actúa (debería sobreentenderse). Es decir, supongamos que tengo la clase Libertoniano, y que tiene un método ManifestarOpinion.
class Libertoniano:

  def ManifestarOpinion(tema):
    # Supongamos que aquí hay código útil.


Si queremos que este método actúe sobre la propia clase, deberemos hacer uso de self entre la lista de parámetros. Algo así:
  def ManifestarOpinion(self, tema):


¿Es grave? No, no es grave... simplemente me parece -y es una opinión- anti-natura.

Variables privadas

Los nombres de variables privadas han de comenzar por __. Bueno, no pasa nada, una restricción como otra cualquiera. Sin embargo, realmente no existen variables privadas, ya que simplemente se usa un "truco" para enmascararlas. Volvamos a nuestro libertoniano: añadámosle una dirección privada de correo electrónico y veamos lo que pasa:
class Libertoniano:
  __correoe = "notengo@nodomain.org"
  def __init__(self, nombre, correoe):
    self.nombre   = nombre
    self.correoe  = correoe

# Cuerpo principal
libertoniano = Libertoniano("osoh", "imobachgs@enalgunlugardeinternet.net")
print libertoniano.__correoe


En este caso, el intérprete de va a quejar: AttributeError: Libertoniano instance has no attribute '__correoe'. Parecería, por tanto, que efectivamente ese atributo es privado. Sin embargo, y tal y como se explica en el tutorial oficial -aunque no con estas palabras-, únicamente se ha "enmascarado" su nombre anteponiendo un guión bajos seguido del nombre de la clase. Así, esto sí que funcionaría:
  print libertoniano._Libertoniano__correoe


Supongo que es cuestión de opinión, pero eso no me parece una implementación muy limpia de los atributos privados, ¿no?

Respecto a la solución de sobrecargar el operador de acceso, me parece más un parche que otra cosa.

Y, lo de Bastion, pues no lo he probado, pero no deberían hacer falta aditamentos para hacer esta clase de cosas tan básicas.

Herencia múltiple

Cierto, Java no permite herencia múltiple y Python sí. Ahí tienes razón.

Pues nada más, creo que mi opinión ha quedado clara. De todas formas, corrígeme si me he equivocado en algo, porque puede ser que no haya entendido bien los conceptos.

Un saludo.

PD: espero no haber cometido errores con el código.
--
Que no haya pasión que no valga el mal que cien años dura (Enrique Bunbury)
[ Padre ]


Las no tan grandes diferencias :-) (none / 0) (#13)
por jorginius ("jorginius" en Google Mail) a las Fri Jan 30th, 2004 at 04:04:10 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Hasta donde yo sé, cuando invocamos un método de una clase en Python, hay que indicarle explícitamente sobre qué clase actúa

Supongo que hablas de instancias u objetos y no de clases.

Por ejemplo, a mí ese "self" me sirve para distinguir métodos de funciones anidadas (con la misma indentación) de un sólo vistazo y ya, dentro del cuerpo del método, acceder a traves de "self" a los miembros de clase no me parece raro: total en C++ y Java siempre acabas marcándo los atributos de alguna forma especial para que no se confundan con las variables locales (o accedes a ellos a través de 'this'). Al menos aquí tienes una forma estándar de hacerlo. Es cuestión de gustos.

También es cuestión de gustos si quieres complicar la gramatica con un caso especial sólo para distinguir llamadas a métodos de clases de llamabas a funciones. La gente de Python ha considerado que no hace falta y yo no le veo mal. En otros lenguajes en los que no hay funciones (como el no-tan-purista Ruby: lo más parecido son métodos definidos en la clase de lo alto de la jerarquía Object) como sólo tienen un caso pueden mantener una gramática consistente sin ese "self" y sin casos duplicados.

Los nombres de la variables privadas han de comenzar por __ [Sin embargo] únicamente se ha "enmascarado" su nombre anteponiendo un guión bajo seguido del nombre de clase
Supongo que es cuestión de opinión, pero eso no me parece una implementación muy limpia de los atributos privados, ¿no?

Es de lo más habitual y eficiente. Es poco más o menos lo mismo que hace C++. Si quieres miembros privados a los que no se pueda acceder en tiempo de ejecución, tendrás que moverte a Java y a su VM que si verifica y protege los atributos privados de los objetos.

Los calificadores como "protected", "private" o "public" son sólo informativos en C++. El compilador no genera código especial para ellos, sólo los tiene en cuenta al verificar la sintaxis durante la compilación. En muchos, muchos lenguajes puedes acceder si quieres a las variables declaradas privadas, y entre ellos están Python y Ruby (con su buena orientación a objetos).

El método que tiene Python de "enmascarar" los miembros privados no es peor ni mejor que el que siguen otros muchos. Indica al programador qué miembros son privados (con el "__") y evita que se acceda a ellos por despiste. Si quieres realmente acceder a miembros declarados privados, pocos lenguajes te lo van a impedir.

no deberían hacer falta aditamentos para hacer esta clase de cosas tan básicas.

Seguimos con lo mismo: no tan básico. En C++ se puede acceder a la varibles privadas en tiempo de ejecución, en Python se puede (por lo que ya se ha dicho) y en Ruby también (simplemente añade un método a un objeto o a una clase en tiempo de ejecución y podrás leer y modificar la parte privada de una instancia desde él). Si no quieres que eso sea posible, necesitas "algo" que monitorice el código que se está ejecutando y eso no es básico (ni barato en términos de rendimento).

Java no permite herencia múltiple y Python sí. Ahí tienes razón.

Tampoco sobrecarga de operadores y Python sí. Bastante molesto, además.

[ Padre ]


Algunas discrepancias (none / 0) (#14)
por osoh (imobachgs at softhome dot net) a las Fri Jan 30th, 2004 at 07:54:21 PM CET
(Información Usuario) http://www.banot.net/~imo/

Supongo que hablas de instancias u objetos y no de clases.

Cierto, un despiste. Tienes razón, me equivoqué. Quería decir objetos (o instancias), no clases.

acceder a traves de "self" a los miembros de clase no me parece raro

Ojo, yo no me quejo de eso. A mí no sólo no me parece raro, sino que además creo que es una buena práctica. Yo me refiero a tener que indicar en la lista de parámetros al propio objeto, cuando eso debe sobreentenderse.

Es decir, si tienes un objeto de la clase Libertoniano y llamas a uno de sus métodos, obviamente debería ser ese objeto el que recibiese el mensaje. Si ese objeto no es relevante para esa llamada, quizás el método no esté bien situado en esa clase.

En otros lenguajes en los que no hay funciones (como el no-tan-purista Ruby: lo más parecido son métodos definidos en la clase de lo alto de la jerarquía Object)

No entiendo que quieres decir con "no-tan-purista". En Ruby no tienes funciones porque todo, absolutamente todo, son objetos. Así que, lógicamente, sólo hay métodos.

Admito, sin embargo, que no siempre se respeta esta metodología: se escribe puts myName en lugar de myName.puts.

Los calificadores como "protected", "private" o "public" son sólo informativos en C++. El compilador no genera código especial para ellos, sólo los tiene en cuenta al verificar la sintaxis durante la compilación.

Es lógico que no se genere código especial: en teoría ya se ha comprobado que no se accede a atributos privados durante la compilación. No podemos comparar este caso con el de Python o Ruby.

en Ruby también (simplemente añade un método a un objeto o a una clase en tiempo de ejecución y podrás leer y modificar la parte privada de una instancia desde él). Si no quieres que eso sea posible, necesitas "algo" que monitorice el código que se está ejecutando y eso no es básico (ni barato en términos de rendimento).

Aquí quería llegar yo: fíjate que son dos cosas distintas. En el caso de Ruby, tú mismo lo has dicho, estás declarando un nuevo método desde el cuál acceder al atributo privado. Conceptualmente, estás modificando la clase (aunque sea en tiempo de ejecución). ¿Entiendes lo que te quiero decir? Has añadido una "funcionalidad" a la clase para poder leer ese atributo privado, al que accederás mediante ese nuevo método. En Python tienes acceso con un simple cambio de nombre. No sé si me expliqué.

Desde luego que pocos serán los lenguajes en los que puedas construir una caja negra perfecta, pero creo que no es esa la intención. En la práctica, puedes acceder a las variables privadas, pero debes considerar que el modo de hacerlo es conceptualmente distinto.

En cuanto a la sobrecarga de operadores, estás en lo cierto y vuelvo a darte la razón. Tiene ventajas que no pueden despreciarse a la ligera.

En fin, creo que nada más. La verdad es que he de confesar que estoy divirtiéndome con este mini-debate y me está haciendo plantearme cosas que quizás de otro modo no me habría planteado. Al menos para mí, está siendo muy instructivo. Muchas gracias ;-)
--
Que no haya pasión que no valga el mal que cien años dura (Enrique Bunbury)
[ Padre ]


A vueltas con la encapsulación en Python (none / 0) (#15)
por jorginius ("jorginius" en Google Mail) a las Fri Jan 30th, 2004 at 09:42:38 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

No entiendo que quieres decir con "no-tan-purista". En Ruby no tienes funciones porque todo, absolutamente todo, son objetos. Así que, lógicamente, sólo hay métodos.

No lo digo por eso y no me parece mal la aproximación de Ruby, sólo justificaba en el párrafo anterior por qué no se hace así en Python si, a fin de cuentas, sería cortar y pegar unas cuantas líneas en el archivo de la gramática y explicaba en éste el caso de Ruby.

Digo que Ruby no es el más purista de los lenguajes OO porque en él NO TODO es un objeto: por ejemplo no los son las estructuras de control del lenguaje. En Smalltalk sí.

Bien pensado, en Python si no nos ponemos quisquillosos, también se puede decir que "todo", o casi, es un objeto.

Supongo que lo que pasa que en Python el concepto gordo no es el de clase sino el de espacio de nombres, como todo el mundo sabe. A los objetos se hace por su nombre consultando el espacio de nombres en el que estemos (un diccionario que mapea nombres con objetos, entendiendo por objeto cualquier cosa: funciones, tipos básicos, clases, etc), las clases, los módulos, las funciones... Definen nuevos espacios de nombres y las instancias guardan sus propios valores en ellos.

Lo bueno es que así Python es coherente. A partir de los espacios de nombres monta todo: módulos, funciones, clases, objetos, etc. Y todo se comporta de la misma manera. Lo malo es que, por mantenerlo simple no hace excepciones para "mejorar" la sintaxis orientada a objetos. Pero vamos, esto es a "bajo nivel". Tú lo que ves en la superficie es que "todo" es un objeto y listo :-).

[Sobre C++] Es lógico que no se genere código especial: en teoría ya se ha comprobado que no se accede a atributos privados durante la compilación.

Lógico si no le pides más que sea un mecanismo para evitar despistes. Si quieres, desde el mismo programa que se ha verificado se puede acceder a ellos leyendo de la memoria que ocupa el objeto. Si puedes inyectar código de alguna forma también. O puedes extender esas clases con acceso a sus atributos privados simplemente modificando las cabeceras y enlazando con el código objeto verificado por el compilador antes.

Yo no veo la diferencia (salvando las distancias y el compilador) entre esto y lo que hace Python. En ambos puedes acceder a los datos privados pero tienes que hacerlo "a posta" :-), con todas las consecuencias.

En el caso de Ruby [para acceder a lo privado] estás declarando un nuevo método desde el cuál acceder al atributo privado.
Conceptualmente, estás modificando la clase.

Conceptualmente los atributos privados de Python lo son :-): lo que falla es la práctica, y en Ruby igual.

Además, no sé exactamente como va pero me extrañaría que el soporte para depuración estuviera incluido directamente en el intérprete de Ruby, así que posiblemente exista un "escape" similar al de Python, más simple que lo que yo propongo, para que pueda inspeccionar las variables un depurador externo.

En fin, que Python es un lenguaje orientado a objetos como el que más porque soporta encapsulación, herencia y polimorfismo, y su encapsulación no es menos encapsulación porque haya trucos (no recomendados) para saltársela, al menos conceptualmente hablado :-).

[ Padre ]


¿Y qué título le pongo? :-P (none / 0) (#16)
por osoh (imobachgs at softhome dot net) a las Fri Jan 30th, 2004 at 11:16:28 PM CET
(Información Usuario) http://www.banot.net/~imo/

Digo que Ruby no es el más purista de los lenguajes OO porque en él NO TODO es un objeto: por ejemplo no los son las estructuras de control del lenguaje. En Smalltalk sí.

Cierto. De todas formas, tengo entendido que los bloques de código también son objetos en Ruby. Pero no me hagas mucho caso. Sin embargo, es cierto que no llega hasta el punto de Smalltalk

Supongo que lo que pasa que en Python el concepto gordo no es el de clase sino el de espacio de nombres[..]

Debe ser eso.

Yo no veo la diferencia (salvando las distancias y el compilador) entre esto y lo que hace Python.

Hombre, yo tampoco he dicho que C++ sea lo mejorcito en cuanto a POO ;-)

Conceptualmente los atributos privados de Python lo son :-): lo que falla es la práctica, y en Ruby igual.

En este punto está visto que tú y yo no vamos a ponernos de acuerdo ;-) Eso es bueno, sería aburrido que todos pensáramos igual. Me parece que el modo de hacerlo en Ruby es más correcto desde el punto de vista de la orientación a objetos.

no sé exactamente como va pero me extrañaría que el soporte para depuración estuviera incluido directamente en el intérprete de Ruby

Pues que yo sepa no, aunque hay que tener en cuenta que sé poco ;-) Intentaré averiguarlo preguntando en ruby-talk y ya les contaré.

Python es un lenguaje orientado a objetos como el que más porque soporta encapsulación, herencia y polimorfismo

Yo no discuto, válgame Dios, que sea un lenguaje orientado a objetos. Simplemente, su aproximación no me convence del todo. Pero claro, es una opinión personal.

Venga, un saludo.
--
Que no haya pasión que no valga el mal que cien años dura (Enrique Bunbury)
[ Padre ]


 
defectos de programadores != defectos del lenguaje (none / 0) (#10)
por jamarier a las Fri Jan 30th, 2004 at 09:57:01 AM CET
(Información Usuario) http://barbacana.net/blog/

Como ha comentado por ahí osoh, Perl permite la programación orientada a objeto de serie.

Lo que se le pide a un lenguaje de programación para considerarlo OO es (la nomenclatura puede variar de un lenguaje a otro):
  • encapsulación
  • herencia
  • polimorfismo


Además Perl incorpora sobrecarga de operadores y otros detalles que lo hacen valedor perfectamente de clasificación de lenguaje OO.

Distinto es que sea un lenguaje solo OO como puede ser C#. Muchos lenguajes no son exclusivamente OO y no constituyen un desmerito para él, como el famoso C++ del que nadie duda sus habilidades.

La mayoría de los paquetes o módulos de Perl son orientados a objetos o incluyen un interface orientado a objeto y otro funcional (tradicional).

Recordemos que el objetivo de Perl es facilitar al programador hacer su trabajo de forma más cómoda es el famoso: "Hay varias maneras de hacerlo en Perl". Si quieres hacer programación OO, puedes, si quieres hacer programación orientada a función, puedes, si quieres hacer OO mezclado con tradicional puedes aunque probablemente serás un mal programador por mezclar los distintos enfoques (No achaquemos los defectos de los programadores al lenguaje de programación).

PD: En Perl 6, Todo será orientado a objeto aunque se presentará un interface dual para que podamos escribir «$string.length» o «length($string)» a gusto del programador.

-----
- Porque mañana será un gran día.
[ Padre ]



 
python if not ruby, el dejà-vu y el lado oscuro... (none / 0) (#7)
por thibaut (asp16 [ykwim] alu.ua.es) a las Thu Jan 29th, 2004 at 11:16:04 PM CET
(Información Usuario)

... el lado oscuro de Ruby, claro, pero no sá por qué el scoop este pone límite a la longitud de los títulos. En fin, que voy a lo mío.

La situación actual de python/ruby se parece, o yo lo veo así, a la que había en su día con perl/python: el lenguage que surge para mejorar a los existentes, que si es más elegante, que si me quiero cambiar pero no hay suficientes librerías, que mola pero es más lento... Cosas que no hace mucho (?) decían los usuarios de perl wrt python las decimos ahora los usuarios de python wrt ruby. Esperemos (o al menos yo lo espero) que ruby tenga tanta suerte como python, y que entonces surja un lenguage que nos guste aún más (el cuento de nunca acabar).

Así que, de momento, mi language of choice es «python if not ruby», es decir: que para todo lo que pueda ruby y si no, pues python. Aunque también va por rachas.

Por otra parte, y pasando ya de comentar por enésima vez todas las maravillas de ruby (aunque no me resisto a mencionar: 3.times { puts "hola" }), creo que toca hablar del «lado oscuro» de ruby, lado que a mí me encanta pero que los pythonianos más puristas encontrarán aterrador, y que a la vez atraerá a más de un usuario de perl (¡oído cocina!): hereda de este segundo lenguage (perl) historias como una facilidad pasmosa para procesar texto (cosa que siempre se ha reprochado a python), acompañado de las maléficas $< y $> y otras como %w() y similares que, aunque nunca he usado perl, echo de menos en python.

Por cierto, ¿alguno tiene ya experiencias sobre revisar código de ruby antiguo? Por eso de la mantenibilidad que se supone nula en perl y absoluta en python. Tengo curiosidad de saber cómo queda ruby por ahí...



Mantenibilidad de Ruby (none / 0) (#11)
por davinci (davinci at ecol org) a las Fri Jan 30th, 2004 at 11:39:36 AM CET
(Información Usuario)

Precisamente ahora ando en el curro revisando el código que creé en su día con Ruby y Gtk1.2, para migrarlo a Gtk2.

El proyecto es relativamente complejo; no es una macroaplicación con millones de líneas de código, pero se trata de un soft de base de datos corriendo encima de Postgresql y es lo suficientemente abstracto como para, aprovechando las mismas clases, crear una nueva aplicación en tan sólo unas horas. Al menos se demarca bastante del script rápido habitual y en su día tuve que enfrentarme a una suculenta jerarquía de clases.

¿Mantenibilidad?... Ruby me ha permitido restructurar todo el código sin apenas problemas. Trabajo rapidísimo en la secuencia cambio/prueba/corrección y se adapta como un guante a la idiosincrasia del más inepto de los programadores (léase yo mismo). Todo parece sencillo de implementar, incluso a posteriori; quizá por eso constituya un lenguaje cuasi-perfecto de prototipado. Los pormenores que he tenido que solventar en la migración, se han debido a las extensiones de Ruby para Gtk2, que aún son algo inmaduras y durante largo tiempo han contado con una escasa documentación para realizar cosas complejas (aunque ésto yo más lo achacaría a la biblioteca Gtk2 en sí misma).

Creo que Ruby es el lenguaje más transparente y versátil que he visto. En realidad no se diferencia demasiado de las últimas versiones de Python (teniendo en cuenta que el último ha ido incorporando las mejores características del primero), pero me resulta más ágil en conjunto. Para mí Python se parece mas al profesor estricto, mientras que Ruby sería algo así como un budista zen. Hecha la parábola estúpida, queda por resolver aún, en esta tesitura, ¿a qué se parece Perl?... :)


¡Es la guerrrrrrra!
[ Padre ]


 
Una razón de peso (none / 0) (#17)
por osoh (imobachgs at softhome dot net) a las Fri Jan 30th, 2004 at 11:22:55 PM CET
(Información Usuario) http://www.banot.net/~imo/

Pues por fin una razón de peso para usar Ruby y no Python. Está en la documentación del binding de Qt (para Ruby):
Of course it is no surprise that you can get more and cuter girls with Rubies than you can with Pythons.


Traducción "on-the-fly": por supuesto, no es ninguna sorpresa que puedas conseguir más chicas y más lindas con "Rubies" que con "Pitones".

Probaré con eso, a ver si así... ;-)
--
Que no haya pasión que no valga el mal que cien años dura (Enrique Bunbury)


 
Sí se puede en Ruby (none / 0) (#18)
por osoh (imobachgs at softhome dot net) a las Sat Jan 31st, 2004 at 12:25:26 AM CET
(Información Usuario) http://www.banot.net/~imo/

Pues que yo sepa no, aunque hay que tener en cuenta que sé poco ;-) Intentaré averiguarlo preguntando en ruby-talk y ya les contaré.

Efectivamente, sé poco. Pueden hacerse cosas así con el grupo de funciones instance_*:

class AA; def initialize; @a = 1; end; end

aa = AA.new
aa.instance_eval { puts @a; @a = 2 }
aa.instance_variable_set :@a, 17
aa.instance_variable_get :@a


Hala, ya sé algo más :-)
--
Que no haya pasión que no valga el mal que cien años dura (Enrique Bunbury)


 
Escogiendo un lenguaje de alto nivel | 18 comentarios (18 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda