Como lenguaje, Ruby ofrece caractersticas muy interesantes.

Una de >> ellas es que han logrado disear un lenguaje elegante que soporta >> mltiples paradigmas de programacin. Yo lo definira como un lenguaje >> de "propsito general" que proporciona estrs cero. Su curva de >> aprendizaje es relativamente suave, haciendo que por supuesto atraiga >> a muchas personas. Ruby tiene otro plus, como lenguaje se puede hacer una implementacin muy eficiente siempre que se hagan ligeros cambios en la definicin del lenguaje, experimentos con JRuby, muestran que se puede hacer que Ruby se aproxime mucho a Java en rendimiento y consumo de memoria, lo que resulta impresionante para un lenguaje tan dinmico. Una implementacin, que creo es privativa, dice tener una eficiencia brutal, mucho mejor que Java, de hecho muy cercana a C, aunque muchos dudan de los benchmarks, y esperan el release. Pero si es cierto, vamos a tener un compilador privativo de Ruby que ser entre 3 y 3.5 ms rpido que Python. > En realidad el paradigma es un lenguaje 100% orientado a objetos, inclusive > los nmeros "enteros" tienen mtodos, todo tiene mtodos, ese es > prcticamente el paradigma de Ruby. No 100%, los bloques son objetos de primer orden y eso permite implementar clausuras, lstima que son ms restringidas que las Perl y Lisp, hay que hacer algunos truquitos para simular algo como eso. El sistema de OO es muy potente basado en mix-ins, la gente que viene de otros lenguajes puede que tenga algunos problemitas cuando se ponga a hacer objetos si no se lee bien la documentacin, pero los mix-ins son una maravilla, las clases son abiertas y por lo tanto se puede extender cualquier clase dinmicamente, lo que resulta asombrosamente til (no se si las clases se pueden cerrar como en Lisp por eficiencia). De cualquier forma Ruby es uno de los lenguajes ms elegantes que he visto y es igual de limpio que Python pero sin la bendita broma de los espacios, y bueno sin las libreras espectaculares de Python o Perl. >> >> Por supuesto, exige sacrificios inaceptables para proyectos en los que >> la escalabilidad es indispensable. Aunque en honor a la verdad, en >> este caso la eficiencia depende mas de una implementacin particular >> de una mquina virtual que de el diseo del lenguaje en si. Es >> tericamente posible escribir mquinas mas eficientes que ejecuten >> cdigo ruby, de hecho hay algunos intentos[1]. >> > > Sacrificios inaceptables donde la escabilidad es indispensable? Por favor > podras darme mas detalle, he trabajado en proyectos con Ruby donde se > escoge precisamente Ruby por su facilidad de escabilidad y su rpido > aprendizaje. Cual escalabilidad ? 1.- escalabilidad de los desarrollos?

2.- escalabilidad de la aplicacin? Creo que en 1 Ruby es escalable por definicin, debera servir para hacer cosas realmente grandes y complejas sin mayor problema. En 2 creo que est en la misma liga de Python con un handicap debido a que la mquina virtual aunque mejorada todava le falta, sin embargo el threading de Ruby a decir verdad no me gusta, pero tiene una ventajita, es similar al de Erlang, claro que a) se comparte la memoria, b) la memoria es mutable y c) no tiene OTP (Open Telecom Platform). De cualquier modo aunque la implementacin de threads de no sea lo mejor para aprobechar el paralelismo, siempre se pueden hacer mltiples procesos para usar mltiples procesadores. Por favor ni se atrevan a comparar la escalabilidad con Erlang, no es justo. Ruby compite con Python y con Perl. > >> >> >> >> >> >> Otra caracterstica inconveniente es la metodologa utilizada para evolucionar ruby -no existe una especificacin pblica del lenguaje-, no me queda claro si existe una comunidad lo suficientemente organizada como para dar los pasos necesarios en la direccin correcta, o si se trata de un esquema de "dictador-benevolente". Simplemente no lo se.

Rubinius intenta cambiar eso, y adems parece estar haciendo progresos impresionantes en cuanto a rendimiento, claro que todava no corre Rails (ni pasa muchos de los tests). > Existe una comunidad muy organizada, funciona al todo estilo del desarrollo > del kernel de Linux. El nico inconveniente que quizs te puedas encontrar > es que existen muchos "Japoneses" dentro de esa comunidad (aunque todos los > que he visto hablan ingles perfecto), inclusive en la actualidad Ruby > sobrepas a Python como lenguaje mas usado en Japn. Claro, Ruby es un lenguaje Japons. >> Ahora, si hablamos de altos niveles de concurrencia, definitivamente >> ruby no es la opcin, al menos no en este momento. Con el advenimiento >> de lenguajes mejor adaptados a manejar concurrencia, es posible que >> esos principios influencien a lenguajes como ruby y otros, aunque >> ciertamente esto requiere de un gran esfuerzo. >> >> > > Por que piensas que no se puede tener alta concurrencia con Ruby? Mongrel > (mongre_cluster especificamente) es un servidor http creado especificamente > para soportar altisimas concurrencias, tiene tolerancia a fallas y puedes > distribuirlo entre todos los servidores que requieras para tu aplicacin. Y

> es 100% Ruby. Como este existen otro tanto de aplicaciones escritas en Ruby > especificamente _diseadas_ para muchisimas concurrencias y tolerancia a > fallas. Porque no, como dije antes Ruby no est en esa liga. Menos cuando quieres alta concurrencia y aprobechar todos los procesadores al mismo tiempo, en eso ya sabemos todos que Erlang es el rey que seguir reinando durante un tiempo debido a que tiene OTP que es un esfuerzo de 20 aos de ingeniera que no es fcil reemplazar. Lo nico que se le acerca es Termite y Haskell concurrente, algo me dice que paralelismo masivo y lenguajes con mutabilidad va a ser extremadamente difcil, as que vayan aprendiendo programacin funcional, que por cierto Ruby no soporta muy bien y Python va avanzando como el cangrejo (hacia atrs). >> Por otra parte, no creo que perl y python sean indiscutibles en >> aplicaciones masivas y escalables. En esa escalabilidad no veo muchos problemas con Ruby, por ejemplo si haces la arquitectura adecuada y utilizas mdulos de Ruby equivalentes a Twisted Matrix (python) o Danga::Socket (Perl) -- que no se si existen -- vas a tener escalabilidad del mismo orden de magnitud, con el handicap de la VM como de costumbre.