Hola, Por alguna razon no puedo acceder a la página, ya conocia el proyecto, pero me dio curiosidad de ver algo mas al respecto. De todas formas la "VM", es solo la maquina, el fierro, no es importante e suna recursos que nos posibilita trabajar, pero ahi no termina la cosa (quizas empieza ahi?) No necesitamos saber como es una vm, ni hacer una; yo he participado en el desarrollo de algunas, pero te aseguro que no es nada del otro mundo, es un tema muy tecnico y aburrido, si... tan aburrido como las maquinas!
>todo muy lindo, pero para manejar un auto no necesito saber mecánica...... > para 'escribirle una carta a dios' no necesito saber programar una VM..... si, deacuerdo entonces, en que ni la existencia de la herramienta, ni la de una especificación/lenguaje/modelo nos libera de nuestra responsabilidad que es la de tratar de abordar sus limitaciones (o al menos considerarlas). En los ultimos años, se ha hablado tanto de la libertad que nos da el poder montarnos sobre lo "hecho" por otros y tan poco sobre como andar ese camino inevitable hacia la desaparición de la ignorancia... Que se ve frecuentemenet personas que no se plantean mas que el tener algo potente en la punta de sus dedos, de la libertad de poder "hacer uso", para hacer, para hacer-hacer, o como expresion de uno mismo (que ya no lo es). Volviendo a el no necesitar saber... todos conocemos que esto esta regulado por la voluntad, es decir, quien no quiere, no sabe. Pero resulta que si muchos "no quieren", los pocos que quieren no pueden... es decir, este mecanismo posibilitador del uso, es tambien el mecanismo inhibidor del desarrollo. (el zorro no llega a las uvas, por lo que al zorro no le gustan las uvas) ojo! no me malinterpretes, no estoy "en contra" de las abstracciones, ni de las formalizaciones, ni de escribir código. Digo que allí mismo esta nuestra limitacion, en no desarrollar algo complemenario. El ver muchas veces un boca-river, o el polarizarnos por la evasion (el odio a lo malo) al punto tal de promover a evitar los efectos secundarios en software. Pensando siempre en encontrar lo mejor para no aceptar la falla. >acabo de ver esto que .... IBM Research acaba de hacer opensource > una maquina virtual de SmallTalk optimizada para trabajar con multicores ah! smalltalk es una sola palabra, es con "t" minuscula, en ingles quiere decir "hablar de cosas sin importancia" (ese tipo de conversaciones distendidas sobre el dia a dia, etc). un cordial saludo, Ale. ----- Original Message ----- From: nelson fernandez To: Grupo Ruby Argentina Sent: Friday, November 05, 2010 12:32 PM Subject: Re: [RubyArg] Ocurirrá algo nuevo? hola, 2010/11/5 Alejandro F. Reimondo <[email protected]> como decía Juan, no son cosa nuevas los lenguajes de script, ruby es del 83 y smalltalk es del 70 por ejemplo,.... la 'novedad' o redescubrimiento se debe creo, por un lado, a la rapidez de prototipado que ofrecen y por otro lado, la abstracción que presentan de cara al hardware o a arquitecturas complejas. Si, esos son argumentos que se usan, pero sabemos que son engañosos, pues cuando uno hace poco, siempre lo puede hacer rapido y usarlo al toque... En ese punto estariamos como con Basic; nada nuevo ni necesitaríamos mas (solo cambiamos sintaxis... seguimos escribiendole una cartita a Dios). Por ejemplo toda la tecnología nueva de multicores es muy dificil de programar, pero si se tiene un runtime que abstrae toda esa complejidad, programarlos con un lenguaje de script seria muy simple y ese es el camino que se esta siguiendo. mmm... aqui hay dos comentarios me gustaría hacer 1.- toda abstracción implica pérdida de información En sistemas de objetos, por ejemplo, podemos ver cómo la distribución de comportamiento se encuentra con un máximo en las clases mas abstractas como también en las clases al fondo de la jerarquía (en las clases intermedias no pasa mucho :) Esto tiene relación con que lo abstracto es de aplicación horizontal, y con el tiempo uno necesita aplicar cosas a todo el mundo con una vision universalista del sistema (en los sistemas sin mucha historia el % es similar a los viejos, pero son pobres de contenido al nivel mas abstracto). Tambien las clases mas concretas poseen mucha información, y esto tiene que ver con la realidad, con lo diverso. Pero resulta que ambos extremos no son equivalentes. La forma en que se sintetiza/obtiene el comportamiento abstracto es muy diferente del concreto. La energía que debemos poner a un elemento abstracto para usarlo en la(una) realidad, es mas alto cuanto mas abstracto sea. Y "la virtud" de la abstracción es una espada de doble filo. (el segundo punto) 2.- permitir el acceso inmediato del ignorante [una de las utopias de la informática] Lo abstracto permite el uso inmediato de software(de un ingenio) por parte del ignorante. Los resultados son inmediatos, pero la percepción del daño causado por su aplicación (exitosa, claro!) llega, en el mejor de los casos, mucho mas tarde. En los casos en dónde se ven los efectos (muchas veces no se desean ver, pues revelan insatisfacción en quien ve solo el valor de lo abstracto y no sus limitaciones) ocurre frecuentemente una reacción, se impone una voluntad de reparación, y allí es donde vuelve a hacerse daño :-) A veces definiendo el daño como un nuevo problema, y atacándolo igual (con el mismo método... OO ). En el desarrollo de sistemas de objetos en ambiente, muchas veces se pretende reducir la velocidad del desarrollo; porque es tan veloz que es contraproducente a mediano plazo (y letal, desestructurante, a largo plazo). La problemática hoy no es producir mas rápido, ni la cantidad de detalles, sino cómo promover los ciclos de experiencia de la manera mas eficiente. Ni el uso de scripting, ni el uso de APIs(interfaces) ha mostrado utilidad alguna en esta dirección, aunque si, el interés por ellos ha aumentado en los ultimos años, en los que el acceso a ellos es gratuito (inmediato). Pero, ocurrirá algo nuevo? Mas modelos abstractos es mas de lo mismo, mas objetos mas papeles que leer, o mas reglas, es mas de lo mismo. no? De ser así la crisis de software que nos espera en estos años será impresionante! O será que no puede haber ya una crisis, porque hemos desmantelado toda posibilidad de reacción? hasta pronto, Ale. todo muy lindo, pero para manejar un auto no necesito saber mecánica...... para 'escribirle una carta a dios' no necesito saber programar una VM..... acabo de ver esto que .... IBM Research acaba de hacer opensource una maquina virtual de SmallTalk optimizada para trabajar con multicores https://github.com/smarr/RoarVM -- :: nelson :: [ artesano de software ~ software craftsman ] http://netflux.com.ar ------------------------------------------------------------------------------ _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
