El día 5 de noviembre de 2010 10:56, Alejandro F. Reimondo <[email protected]> escribió: > >> 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. > > > > > ----- Original Message ----- From: nelson fernandez > To: Grupo Ruby Argentina > Sent: Friday, October 29, 2010 10:47 PM > Subject: Re: [RubyArg] Ocurirrá algo nuevo? > > > > > > 2010/10/29 Alejandro F. Reimondo <[email protected]> > > Hola, > En los ultimos años ha crecido la popularidad de lenguajes de scripting > orientado a objetos. > Lenguajes a los que se agregaron facilidades de uso práctico presentes desde > hace más de veinticinco años (quizás debería decir +35, pero me remito a > cosas que he visto y utilizado personalmente). > > Abunda hoy literatura (de medio pelo) sobre metaprogramación, en dónde se > alienta a la fasinación con la creación de métodos dinámicamente (me cuesta > no dispararme por una tangente acá :-) pero sin mas información que la > documental e instructiva sobre cómo estan resueltas tecnicamente esas > facilidades. No se habla en absoluto de las consecuencias de esa vision > minimalista, ni sobre mantención de sistemas. > Esto está relacionado, en mi opinión, con la promosión de técnicas de > scripting, por quienes no reflexionan sobre sus limitaciones (por quienes no > han avanzado en la práctica con su uso). > > La pregunta que me motiva a escribirles (después de tanto tiempo), es si > consideran que este contexto que se ha gestado, luego de la aparición de > Ruby, Phyton, etc... promoverá algún avance (de relevancia tecnológica) en > esta década. > Es una pregunta dificil, lo se, pero creo que amerita algún diálogo al > respecto; y que puede ser de utilidad para quienes desde nuestro lugar > siempre hemos alentado avances; y muchas veces ya nos hemos equivocado como > niños ;-) > > Una pregunta colateral es el rol de smalltalk en este nuevo estadío de la > informática, en dónde se alienta sin limites al fraccionamiento de los > sistemas y aún no se motiva más que a seguir escribiendo código (a mano o > "automáticamente")... sin esperar en usar los objetos. > > hasta pronto, > Ale. > > pdta.: disculpas por copiar este email en la lista de ruby de argentina; > pero creo que esta pregunta será de interés también allí, y será considerada > ante ópticas diferentes a las que nos ocupa en Smalltalking. > > > > > 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. 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. > > > -- > :: nelson :: > [ artesano de software ~ software craftsman ] > http://netflux.com.ar > > > > > >
Alejandro: No suelo tomar muy en serio los mensajes que me ingresan con errores de ortografía, pero tiraste el guante y no me queda otra que recogerlo. Primero quisiera hacer una pequeña exposición. Hubiera preferido resumirla más, me disculpo por no poder ser un poco más sintético. Luego responderé algunos de tus conceptos. Los lenguajes scripting no forman parte de revolución alguna, ni son un paradigma en sí, y mucho menos tienen la pretensión de serlo. Son nada más que otros o los mismos lenguajes, con la consigna de poder ser ejecutados en forma interpretada. Buenos o malos, aptos para la investigación o no, productivos o no, no son otra cosa. Cito una definición interesante que me robé de la Wikipedia “Teóricamente, cualquier lenguaje puede ser compilado o ser interpretado, así que esta designación es aplicada puramente debido a la práctica de implementación común y no a alguna característica subyacente de un lenguaje en particular”. No hay nada más que decir al respecto. La aparición de una amplia gama de lenguajes interpretados es la respuesta de la industria de software ante un cambio fundamental en el "ecosistema", que es la caída abrupta de los costos de los recursos físicos y el consiguiente aumento relativo de los costos de los recursos humanos iniciada a fines de los 80. El causal de éxito de algunos de estos lenguajes (no todos salen al estrellato) son totalmente heterogéneos. Si tomamos los cinco principales (dejando de lado shell scripting, tenemos por popularidad Perl, PHP, Python, Ruby y Javascript) nos damos cuenta que en ellos motivó siempre momento y oportunidad, y no la respuesta que pudieran dar a determinado/s paradigma/s. En todos los casos, lo que primó fue resolver en forma sencilla un problema, o simplemente, hacer más fácil lo ya existente. Esa es la razón de ser, y el fuerte consiste en la simplicidad para el desarrollador y no la de responder a algún paradigma de programación o formar programadores en determinadas capacidades. ¿Eso atenta contra el avance técnico o teórico, o “imposibilita contextos de desarrollo”? Todo lo contrario. Los lenguajes scripting sólo son otra forma de encarar un problema, pero fomentan el acceso a muchos a la generación de software. Sintetizan paradigmas (malo quizás para el ámbito académico, pero excelente para quienes necesitan o prefieren una herramienta amplia). Abstraen conceptos. Simplifican el camino. Por eso, tildar a estos lenguajes de "limitados" o "sin compromiso", o de "irreflexivos" a quienes lo usan, no sé si es superficial, ingenuo o insultante. Lo que sí, estoy totalmente convencido que esas afirmaciones son anacrónicas y están totalmente ajenas a la realidad. Realidad que habla por sí sola en la enorme variedad de soluciones de calidad provistas y que se proveen a diario, desarrolladas con estas herramientas, disponible al público general (muchas veces, gratuitamente). Los lenguajes scripting están desde hace más de 20 años aquí y están para quedarse. Quizás un cambio en los paradigmas actuales harán que muchas cosas cambien. Los lenguajes scripting se adaptarán como ya lo han hecho. ¡Larga vida a ellos! Expresado mi “alegato”, me animo a tomar algunos de los conceptos que tirás entre muchas frases que no llego a entender ya que no sé si es mi propia estupidez, si están fuera de contexto o simplemente fueron agregadas para dar grandilocuencia a un texto con muchas adjetivaciones y poca profundidad. >> Esto está relacionado, en mi opinión, con la promosión de técnicas de >> scripting, por quienes no reflexionan sobre sus limitaciones (por quienes no >> han avanzado en la práctica con su uso). Esa promoción de lenguajes scripting de la que hablás no es casual. Se debe a varios factores que hicieron y hacen que muchos desarrolladores y empresas vuelquen su estrategia hacia estos pagos. Está el indudable (y eludido en este hilo hasta recién) factor económico, tal como recalqué al principio, pero también están la facilidad de distribución, la simplicidad de uso, el movimiento hacia plataformas web (donde estos lenguajes están excelentemente adaptados a los requerimientos de los propios desarrolladores), entre las que se me ocurren. Ahora, si después de 20 años no se ha avanzado en la práctica, no sé de qué estamos hablando, o, en todo caso, cuál sería el problema. Todo lo contrario, luego de tanto tiempo, la práctica ha hecho que estos lenguajes sean una salida posible ante problemas concretos. Sí, hay limitaciones, pero como en todos los ámbitos, la balanza costo beneficio manda sobre el purismo. > En el área de sistemas, hay cambios menores; no importantes, > pues siempre se trata de evitar las crisis del software, los lenguajes > de scripting parecen ser una avance a ciegas, sin reflexión > sobre los resultados de las últimas décadas, al menos su propagación > es idéntica a la de los virus... que no es algo que tranquilice. [*] ¿Tuviste alguna vez en cuenta el abaratamiento y mejora de capacidades de hardware de los últimos 30 años (perdón por mi insistencia)? ¿O de las mejoras en las técnicas de compilación y procesamiento? ¿O del incremento relativo de los costos en recursos humanos que se viene observando desde fines de los 80 (otra vez)? Hoy por hoy, en la mayoría de los casos, se hacen insignificantes los tiempos de interpretado y de ejecución sobre las máquinas virtuales. La discusión que planteás era interesante hace 25/30 años atrás, cuando los costos de hardware eran otros y eran incomparables con los de recursos humanos ... hoy, invertida la ecuación, el programador es el rey y sólo queda la dialéctica purista. Entonces me pregunto ... ¿Bajo qué criterio avance a ciegas? ¿De cuál de todas las crisis del software estás hablando, de las de los 60, de las del 70 o de los 80? ¿Está mal haber intentado evitarlas desde el enfoque tradicional? Advertencia: pasaron de 30 a 50 años y los aportes prácticos de la tecnología de objetos y el Smalltalk en este sentido dan para otro post. ¿Cuáles son las reflexiones que nadie hizo sobre los resultados de las últimas décadas? ¿Realmente fueron malos, teniendo en cuenta la complejidad de las aplicaciones finales que usa el hombre medio hoy comparadas con las de, digamos, 10 años atrás? > La utopia de poder ignorar los efectos secundarios tiene > como tal (como utopia), toda la fuerza de la seducción, > incita a pensar que lo que escribimos de un sistema (en > su código) lo condiciona... > La difución y promosion de esa utopia no viene, claro, > de un área de producción; sino de un área diferente > que no tiene vinculo con la capacidad productiva. ... > La forma de escribir sistemas sigue siendo la misma. > Se los "define desde afuera", se ve aplicación y programa, > no se entiende la palabra "sistema" y/o se piensa en sistema > como algo con lo que uno no puede trabajar (solo puede intentar > definirlo, condenarlo a una forma idealizada; reducirlo a sus > partes, como si un sistema fuera la suma de sus partes). La forma de escribir es la misma y seguirá siéndolo. Acá hay un serio problema de concepto. Un sistema es algo inmaterial. La "forma ideal" es una condena ya que es inalcanzable, pero también, su sublimación. Lamentablemente, los sistemas pueden tener sólo dos fines a) ser implementados imperfectamente (no hay otra, sólo su forma ideal es perfecta) b) no ser implementados. Para el a) los lenguajes scripting son una posible solución. Para el b) están los perfeccionistas con sus métodos inapelables. No sé si la difusión y promoción de esto está bien o está mal, o de parte de quién viene, pero me parece más utópico pretender convertir lo inmaterial (un sistema o un ideal) en materia perfecta (su código o su implementación no condicionante) que dividir un sistema en partes para encarar una posible (e imperfecta) solución. > 1.- toda abstracción implica pérdida de información > ... Todo lo que dijiste luego de esto se invalida por el simple hecho que te faltó agregar una palabra: "irrelevante". Deberías haber escrito "toda abstracción implica pérdida de información irrelevante". Si no, no es abstracción. ¿Porqué no promocionás trabajar directamente en assembler que carece de esto? ¿o no usarías OpenGL o SQL porque son abstracciones? Yo he ensamblado a mano ... muy lindo para divertirse un rato ... muy malo para intentar hacer un sistema con responsabilidad. Ah, con una tecnología realmente de objetos, sin abstracciones, podríamos reemplazar todos los sistemas de archivo, interfaces humanas y acceso a datos masivos con objetos. Extirparnos el cáncer del SQL y de las API del kernel para hacer las cosas como corresponde. Por suerte hay mucha variedad de sistemas operativos basados en esta tecnología. Está el celular de mi nene... Huy! Cierto, el otro día me enteré que Sun abandonó el proyecto JavaOs. ¡Malditos! Seguro fueron los programadores de lenguajes scripting que no se animaron a encarar todo con Smalltalk. > 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. Debo sincerarme y decir que fue este párrafo el que me motivó escribir este largo post. Me generó más indignación que la que puedo contener. Ignorante no es un programador iniciado. ¡Ignorancia es escribir promoción con s (parece que ni los carteles publicitarios son leídos) o liviandad con b larga! El error es darle a un iniciado responsabilidades propias de un puesto que requiere una visión generalista de sistemas. Pero si una abstracción permite que un novato pueda hacer una aplicación exitosa, bienvenida ¡La quiero ya! ¿El daño? Daño puede haber en una aplicación en tiempo real que maneje un avión. Excluidos esos casos, el daño es no terminar nunca una aplicación. Por otro lado, hay millones de "ignorantes" que acceden a la informática desde el lado usuario, gracias a aplicaciones hechas por "ignorantes" de sistemas con lenguajes como PHP. ¡Desterremos estos productos corruptos y viciosos para impedir el ingreso del aluvión zoológico a nuestra cofradía inmaculada! > Si, yo tampoco sé desde cuando se usa Perl, > pero fue muy sorprendente para mí, encontrar en wikipedia > referencias que dicen que solo es desde 1995 que hay una > version usable; y que aún hoy siguen usando reference count, > que hay una sola VM, etc. > Este y otros indicadores, indican que no es usado para sistemas > sino informalmente (la recolección por conteo de referencias > es una tecnica de utilidad práctica solo en sistemas pequeños; > uan sola VM indica que no sellegó a una etapa de expresión > de diversidad). Perl existe desde 1987. Yo tengo una versión de Programming perl del 93. No sé dónde leíste que la versión usable del mismo es del 1995 (¿Te estás refiriendo a Ruby quizás?) ¿Informalmente? No puedo dejar de pensar que hubo malicia en incluir ese término. Usé perl al menos cada vez que verificaba los términos de este post a través de los motores de búsqueda. Los que hacemos cosas con otros lenguajes debemos sacarnos el sombrero ante la potencia y velocidad de la única máquina virtual de Perl existente (en realidad hay otra, pero sólo experimental). Lamentablemente, su desarrollo no ha avanzado comparativamente desde la versión 5, quizás debido a que han surgido otras herramientas (con VM peores) que han cubierto "nichos" que perl ocupaba o era candidato a ocupar. Además, conociendo Perl, no le veo el sentido de tener un abanico de implementaciones como lo tienen Ruby, Java, C# o Smalltalk. Por otro lado, si el "conteo de referencias" hace que Perl tan rápido como cualquier lenguaje compilado, será hora de pensar en que esa técnica no es tan mala, a pesar de ser tan vetusta. Ah! ¿Habrá algo nuevo? No lo sé. El futuro siempre es incierto, pero seguro nos encontraremos con niveles de abstracción mayores y más gente usando tecnología cada vez más compleja. Para bien o para mal. Por suerte, estará el Smalltalk que llevará a los sistemas a la integridad absoluta. Mientas tanto, nosotros con nuestras impurezas seguiremos construyendo software para la gente. Y los lenguajes scripting estarán allí para darnos una mano. Saludos! Silvio Descargo antes del flamewar: Así como me saco el sombrero con Perl y su eficiencia, lo hago con Smalltalk, pionero en OOP y quizás único como TO puro (reconozco que necesito desasnarme, ya que no soy marino de esas aguas). Además, el enfoque de la teoría de la tecnología de objetos fue y es fundamental para analizar y llevar a tierra esos objetos inmateriales que son los sistemas. No hay que dejarse llevar por las ironías de un desalineado como yo, así como tampoco hay que escribir sistemas perfectos. La gente sólo necesita software que ande. _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
