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
