El día 8 de noviembre de 2010 10:02, Alejandro F. Reimondo <[email protected]> escribió: > Estimado Silvio, > > Cuidado! mi email seguro contiene errores, no solo de ortografía, > espero tengas la fortaleza de poder soportarlo. > Pero che! has hablado mas de Smalltalk que yo!, sin conocer > mucho de que se trata (pero no hay drama, es algo frecuente). > Acepto que, al no conocer, lo trates como a otros lenguajes. > > Acepto tambien que te irriten mis errores ortográficos, como > seguramente te irritarán tus errores (quizás no ortográficos). > > Pero pienso distinto que vos y mis palabras estan excentas > de todo fanitismo y animosidad de descalificación. > Puedo comentar varias cosas sobre tu largo mail, todo largo > mail es una invitación al diálogo. > No se por dónde gustarías de seguir la charla, lo digo para > no contestar sobre algo que no te interese; solo copia un > par de tus comentarios (tratá que no tenga desalificaciones, > es decir, hacelo cuando estes un poco mas frío, si te dan > ganas de seguir el diálogo). > > Como ocurre frecuentemente, es posible que no respondas, > no hay drama; quizás ya dijiste lo que querías, y solo necesitabas > reducir la carga de indignación que impone leer a alguien que ve las > cosas distinto y las dice con errores. > > Si es así, me gustaría comentar que Smalltalk es evidencia > de que podemos ambicionar algo más que un nuevo lenguaje. > Esta evidencia podría promover avances, que no se han dado, > si fuera posible una masa crítica de personas que superaran > el estadío de fanatismo que promueven algunos abordajes > informales. > > un cordial saludo, > Ale. > pdta.: veo en tu email que la palabra "ignorante" la tomaste > como si fuera ofensiva; en mi, dicha palabra determina un estadío > del aprendizaje y no nos descalifica el reconocernos en ese estado > frente a un dominio que requiere ser entendido. > > > > > ----- Original Message ----- From: "Silvio Quadri" <[email protected]> > To: "Grupo Ruby Argentina" <[email protected]> > Sent: Saturday, November 06, 2010 8:51 PM > Subject: Re: [RubyArg] Ocurirrá algo nuevo? > > > 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 > >
Alejandro: No le doy mucha importancia a estas cosas, pero en este caso, fue indudablemente la descalificación y el uso de términos como "ignorante", "irreflexivo" y "sin compromiso" lo que me molestó. Si bien no fueron atribuidos en forma directa, sí se desprende de la lectura que estaban achacados a quienes están relacionados a estos lenguajes scripting (promociónenlo o no). No digo que lo hayas escrito con esa intención. Además, si bien la definición de ignorante es clara (http://rae.es/ignorante), el contexto donde estaba escrito me resultó muy despectivo (y me hizo saltar la tapa!). Bueno, como decía en el principio de mi texto, tomé el guante, hice mi descargo y luego golpeé bajo. Acusaste el golpe y me invitás a proseguir con términos menos descalificantes. Me parece lo más caballeroso que he escuchado en tiempo, así que me disculpo por haberte molestado (y reconozco que lo he hecho adrede por los motivos ya expresados). Sí, es cierto, no conozco más de Smalltalk de que lo que he leído. Hablé, hablo y hablaré desde mi desconocimiento (que espero que sea cada vez menor). Si me limitara a hablar de lo que realmente sé, mi boca estaría cerrada casi todo el tiempo (y no sería tan divertido). Por otro lado, puedo ser un buen "sparring" confrontando ideas, en el buen sentido. Tomemos la primer parte de mi texto (el "alegato" en favor de los lenguajes scripting como se me ocurrió llamarlo) y sigamos desde allí (no creo que haya algún término fuera de lugar allí y si lo hay, ignorémoslo), si estás de acuerdo. No creo que lleguemos a que un lenguaje, un método o un enfoque es mejor que otro, pero estoy convencido que va a ser constructivo. Si querés seguir en privado o si la discusión ya es más off topic de lo que la lista puede soportar, seguimos en privado, no hay problema por mí. Invoco a un moderador aquí. Saludos! Silvio _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
