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
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
