>Qué opinan sobre:
  >1.- la necesidad de educar adultos en el abordaje
  >de sistemas abiertos.
  >2.- la posibilidad de educar adultos con Smalltalk.
  >3.- que es recomendable hacer para tal fin?

Primero quisiera que definas el contexto:
Que edad son adultos?? (a que rango de edad)
Que es un sistema abierto??

Hola,

>>"Y que perjudicial es el aplicar esto en niños
>>para instruirlos en ciencias duras (x. ejm. usar Squeak
>>para enseñar a "descubrir" leyes de gravedad u otras).
>>Bueno... abrí quizás, una lata de serpientes :-) [...]"
>uuuuuuhhhhh que bombazo tiraste!! :-)

Elvio, creo que el párrafo, tal como lo cortaste se lee
  mucho mas duro de lo que quería ser, incluso, creo
  que se focaliza la atención sobre un punto que no
  juzgo útil dialogar hoy en día.
Lo que había dicho era:
----------------------
tratar temas que tienen que ver con
  nuestro objeto; y si me permiten, sirve también
  para analizar que sentido tiene el educar (con Smalltalk)
  a adultos en la construcción de sistemas abiertos...
Y que perjudicial es el aplicar esto en niños
  para instruirlos en ciencias duras (x. ejm. usar Squeak
  para enseñar a "descubrir" leyes de gravedad u otras).
Bueno... abrí quizás, una lata de serpientes :-)
----------------------

Para decirlo mas claro: me interesa
"analizar que sentido tiene el educar (con Smalltalk)
  a adultos en la construcción de sistemas abiertos..."
y luego, después de hacer ese análisis, si les interesa,
  extenderlo a "que perjudicial es el aplicar esto
  en niños para instruirlos " [*]

Qué opinan sobre:
1.- la necesidad de educar adultos en el abordaje
  de sistemas abiertos.
2.- la posibilidad de educar adultos con Smalltalk.
3.- que es recomendable hacer para tal fin?

ideas?

hasta pronto,
Ale.
[*] sobre el tema de los niños, me interesa pero no
  quiero abordar el tema sin que antes hayamos avanzado
  algo sobre el análisis respectod e los adultos.
Lo único que quiero agregar a este punto es que no
  todos los niños son iguales y los métodos eficientes
  en un contexto pueden generar estragos en otros; los
  niños absorben fácilmente lo enseñado y los resultados
  se ven amplificados en pocos años.

----- Original Message -----
From: "Elvio Fernandez" <elvio.fernandez@...>
To: <smalltalking@...>
Sent: Tuesday, November 28, 2006 5:54 PM
Subject: Re: [SPAM] Re: [objetos] Aplicaciones web?


Hola gente,

Ale decia:

"Y que perjudicial es el aplicar esto en niños
para instruirlos en ciencias duras (x. ejm. usar Squeak
para enseñar a "descubrir" leyes de gravedad u otras).
Bueno... abrí quizás, una lata de serpientes :-) [...]"

uuuuuuhhhhh que bombazo tiraste!! :-)

Pero qué educador dice que Squeak es beneficioso para los niños? Algun
Smalltalker... me imagino.
Intuyo que gran parte de esto debe venir de esta nota a Alan Kay (
http://www.squeakland.org/school/HTML/essays/dynabook_revisited.htm, la
version en español es: http://swiki.agro.uba.ar/small_land/243) donde el
chavon habla del Dynabook. Especialmente el apartado " *The Music of Ideas*"
en esa nota.

Mi primera aproximacion a una computadora fue asi como dice Alan Kay, a los
9 años (año 83) por casualidad me tope con una Texas Instruments con un LOGO
y pude aplicar algo de lo que estaba aprendiendo en la escuela: angulos.
Pero de ahi a aseverar que todos los chicos pueden asimilar y comprender la
idea de un angulo con un computadora hay mucho trecho. No?

Una cosa es Leon Trotsky y otra cosa son los Troskistas... ( la lista se
volvio subversiva jejej )

Los de America del Norte tienen mucho de esto. Como pensar que un enfermo
adicto solo se puede recuperar en una especie de institucion en un regimen
de premio y castigo (no hay lugar para repensar, reflexionar, indagar en la
problematica particular de cada cual,etc, solo premio o castigo) no es
castrador?. Para agregar a la anecdota de los "leoncitos"  [equipito de
hokey? :) ] que comentaba Ale, vieron la pelicula "Belleza Americana"? . Uno
de los protagonistas es un adolescente que "aparentemente" esta descarriado.
Le da a los narcoticos, pareciera que es medio gay (no se sabe bien), anda
en cualquiera. Y en una parte el padre ya enloquecido medio lo mata a piñas
y desesperado le dice: "hijo... lo que te hace falta es estructura".

De que "estructura" esta hablando? de la estructura programada que comenta
Ale y que beneficia "aparentemente" al individuo. Preguntas retoricas: ¿Esa
"estructura" beneficia (en algun sentido) al individuo en cuestion? ¿Cada
individuo elabora su propia "estructura", o la elabora otro?

"Creo que hay muchas comunidades...
Asociarlas porque usan el mismo soporte creo que
no es una forma correcta de clasificar este tipo de
grupos humanos, es poner el foco en las herramientas
y no en las personas ni en las actividades que desarrollan
ni en sus motivantes "

Es cierto Ale... me salio la "estructura" de adentro :)

Saludos

Elvio

Hola,

>No... no lo digo en ese sentido. Lo dije de manera grotesca
> para que se entienda la falsa idea de que "lo que hay"
> es lo que "debe ser" y que entre toda la locura del desarrollo
> terminamos confundidos por los espejismos.
>Terminamos justificando temas técnicos, terminamos
> coercionados a determinados rumbos. Y por esa coercion
> poderosisima que recibimos en el día a día (porque no
> somos marcianos y vivimos en un ambiente que
> ineludiblemente esta relacionado con el mercado) se nos
> mutila de alguna manera. Se entiende?

Es mas apropiado, a mi entender, el decir:
     "nos mutilamos de alguna manera"
Mi mail anterior quería decir justamente
   que no es necesario que exista el malo que
   nos corta las piernas, solo hace falta llenar
  el mercado de serruchos, poner en los kioscos
  revistas sobre los mejores serruchos -del mercado-
  y luego decirnos que ser libre es quien se corta
  las piernas por propia voluntad... (la libertad del
  serrucho/software... no la nuestra)
He encontrado que para compartir estas reflexiones
  es muy importante la educación que uno tenga
  y la instrucción que uno tenga; la conjunción entre
  una y la otra hacen posible o no compartir lo que
  comento arriba.
En la mayoría de las personas existe (de forma reprimida
  a mi entender) el uso de la percepción de lo que nos
  está ocurriendo a los que tenemos relación con el
  software (antes eramos influenciados por matemáticos
  y otras personas de las ciencias duras y hoy por quienes
  están vinculados a lo mas blando, los negocios y el dinero)
  a quienes aun intentan usar la percepción (he observado)
  les aparece ese "fantasma" que esta en contra y evita
  que se pueda trabajar con menos sufrimiento.
(muy) Pocos reconocen que ese fantasma esta dentro
  de cada uno y que nos dice a diario que debemos
  ser todos iguales (millones de moscas... como si "ser
  mejor" fuera ser mas parecido a ser un insecto o tuviera
  relación con algún numero, cantidad de individuos
  o de licencias... y no con el sufrimiento).
Cuento ahora algo que esta relacionado a mi entender
  no con el software, pero si con la "programación";
  y es anecdótico pero sirve para ejemplificar lo
  de arriba.
Resulta que este año, mi hijo (Guido, de 4 años)
  actúa en el colegio en una obra del jardín...
  allí los niños son leones y las niñas otro animalito;
  es curioso el hecho de que todos los niños deban
  ser el mismo animal; pero lo mas curioso aún fue
  que las "seños" pidieron que todos los leones
  sean parecidos! si es posible, iguales (el mismo traje).
Esto fue rápidamente abordado por las madres
  para armar un grupo y encargar todas el mismo
  traje a alguien que lo hace...
Se entiende desde que momentos somos programados
  para destruir nuestras características individuales?
Cómo podríamos pensar en ser distintos al vecino?
Eso es posible, a mi entender, solo por auto-educación
  (no importa los padres, que han sido desvalorizados
  en los últimos años e incluso se los mutila -en los términos
  que decía Elvio y sin querer- para que los efectos de
  un hogar sean sobreescritos por códigos escolares
  planificados por personas que año a año desean que
  todo sea mejor -y de hecho lo ven así- sin reflexionar
  sobre los resultados obtenidos, o peor aún criticando
  a los que han hecho lo mismo en años anteriores,
  sin reconocer que el año próximos serán ellos
  mismos).
Perdón por el chorro este que parece ser de otro
  ámbito, pero confío que es una expresión del
  mismo origen y que podríamos hacer nuestro
  análisis lo ssuficientemente amplio como
  para entender que tratar estos temas es tratar
  temas de ambiente y de educación en ambiente.
Es decir, tratar temas que tienen que ver con
  nuestro objeto; y si me permiten, sirve también
  para analizar que sentido tiene el educar (con Smalltalk)
  a adultos en la construcción de sistemas abiertos...
Y que perjudicial es el aplicar esto en niños
  para instruirlos en ciencias duras (x. ejm. usar Squeak
  para enseñar a "descubrir" leyes de gravedad u otras).
Bueno... abrí quizás, una lata de serpientes :-)
(en otros lugares hubo personas que se ofendieron
  cuando hice comentarios como este pese a ser personas
  que justamente estaban preocupadas por la enseñanza,
  si a´hora ocurre lo mismo, ruego que me traten de
  dar argumentos para pensar distinto o ver cómo no
  se aplica lo que dije, ya que antes no he recibido ayuda
  alguna de parte de esos que se ofendieron)

>se me hace muy difícil de explicar... No contamos con
>las herramientas técnicas para llevarlo acabo?
>No tenemos aire ni lugar?

El mundo es tan amplio que hay lugar para todo,
  es tan simple como cortar el vinculo que disipa
  nuestras energías.
Ese cortar el vínculo nunca debe ser para dejarnos solos,
  sino que hay que lograr hacerlo construyendo un
  espacio (al menos celular) para compartir la experiencia
  con otros.
Esto genera segregación de comunidades (como ocurrió
  en varias oportunidades en comunicades de Smalltalk
  y en Argentina) cosa que es muy positiva si esa segregación
  produce algo mas que envidia, no entendimiento de diferencias
  y tratos injustos e infantiles.
Enuncio esto y lo enfoco en Argentina porque es lo que
  conozco pero estoy seguro que esto ocurre hoy en todos
  lados, porque estamos comunicados y porque hay argentinos
  casi por todos lados :-P
[en el caso de los Argentinos en otros lados podemos
  sentirnos orgullosos de haberles dado ese "pasaporte"
  para que puedan aprovechar lo que han sabido aprender
  aquí sobre objetos, y el buen reconocimiento que logran al decir
  que son Smalltalkers Argentinos]

>La comunidad Smalltalk cuenta con pocos recursos

Creo que hay muchas comunidades...
Asociarlas porque usan el mismo soporte creo que
  no es una forma correcta de clasificar este tipo de
  grupos humanos, es poner el foco en las herramientas
  y no en las personas ni en las actividades que desarrollan
  ni en sus motivantes (muchas veces ocultos en una
  estructura y en la herramienta misma -otro tema "difícil
  de tocar"-).
hoy estoy tocando demasiados nervios ... :-)

> y sin embargo hace muchisimo a todo nivel.

mmm... mucho barullo... si.
Poco en lo que respecta a objetos (muchos han notado
  esto en los últimos 10 años).

>Esto es algo que he visto al acercarme a todos uds.
>Y es algo que no se encuentra en otras comunidades.

Mis comentarios no tratan de diluir el esfuerzo que todos hacemos,
  sino que trata de ser un análisis crítico que pretende incitar al diálogo
  y motivar a identificar dónde/como poner foco en lo que nos interesa.

hasta pronto,
Ale.



----- Original Message -----
From: "Elvio Fernandez" <elvio.fernandez@...>
To: <smalltalking@...>
Sent: Monday, November 27, 2006 5:14 PM
Subject: Re: [SPAM] Re: [objetos] Aplicaciones web?


Hola Angel, gente,

La charla esta tomando varios rumbos.

" Elvio, me temo que no comparto la idea de que alguien vino y "corto las
piernas"

y esta genial !!
De la charla van saliendo cosas positivas. No perdamos de vista esto. El
intercambio de idea es positivo. Y si de la confrontacion de ideas no sale
nada, es positivo tambien porque al menos nos permite ver que es lo que los
demas piensan.
Todos comprendemos que es un tema complejo.

" Pero el tema nacio por tu reaccion contra la web, creo entender tu
reaccion
contra PHP (veria algo de PHP5 y Prado, igualmente)"

Aunque mezcle PHP8 con symfony, o utilice Seaside. La heterogeneidad esta
ahi.
Disculpas muchachos, me voy a citar:

"Mi intencion fue preguntar si no existiria otra posibilidad para hacer eso
que llaman "Aplicacion Web" con algunos mecanismos que ya existen en
Smalltalk y trate de fundamentar por qué crei que era necesario una
homegeneidad en el desarrollo. Y los beneficios de esa homogeneidad.
Inclusive una invitacion a que imaginemos las posibles consecuencias de esa
homogeneidad.
En esto ultimo entra los que vos decis Ale sobre: el termino de "Aplicacion"
no cuadraria ya. Smalltalk abre otros caminos."


Angel decia:

"No es que alguien viene y corta las piernas... Solamente que no nos
crecieron, o si nos crecieron, no las hicimos notar... No carguemos las
culpas en otro."

No... no lo digo en ese sentido. Lo dije de manera grotesca para que se
entienda la falsa idea de que "lo que hay" es lo que "debe ser" y que entre
toda la locura del desarrollo terminamos confundidos por los espejismos.
Terminamos justificando temas tecnicos, terminamos coercionados a
determinados rumbos. Y por esa coercion poderosisima que recibimos en el dia
a dia (porque no somos marcianos y vivimos en un ambiente que
ineludiblemente esta relacionado con el mercado) se nos mutila de alguna
manera. Se entiende? se me hace muy dificil de explicar... No contamos con
las herramientas tecnicas para llevarlo acabo? No tenemos aire ni lugar?
pues bien, al menos podemos reflexionar caminos alternativos. Y el intentar,
tantear como ciegos, otras formas nos hace que inevitablemente replantiemos
cosas y tengamos que descubrir en qué lugar estamos, entre todo este
despelote.
La comunidad Smalltalk cuenta con pocos recursos y sin embargo hace
muchisimo a todo nivel. Esto es algo que he visto al acercarme a todos uds.
Y es algo que no se encuentra en otras comunidades.

Saludos
Elvio

PD: voy a buscar "Crossing the chasm" parece interesante.

Hola Mariano,

>  >Si aceptamos ese rol, no podemos pensar en ser reconocidos
>  >por algo mejor que unir las partes que otros eligen...
>  >un buen pegador de piezas que unos pocos diseñan
> Creo entender lo que decís, y según entiendo es inevitable y necesario.
> Necesario porque no podemos pretender empezar de cero siempre,
> necesitamos basarnos en el avance de otros para hacer nuestro propio
> avance, caso contrario estaríamos diseñando software con tarjetas
> perforadas.

mmmm ni una punta ni la otra... no?
Usar lo de otro implica evaluar antes si se aplica a nuestro contexto.
Tomar como valido lo que es no evaluado por millones no es
  una buena política a la larga, si uno ya ha elegido una dirección
  poco frecuente.
Que quiero decir con esto?
Que si uno ya eligió (o esta evaluando) algo útil para
  cosas que no están en el frente de la mayoría,
  es poco feliz intentarlo usar para cosas que hace
  la mayoría.
Digo poco feliz, porque he visto muuucha gente que se frustra
  e incluso se enferma al ver que no puede aplicar cosas como
  Smalltalk en ámbitos dónde se aplican cosas menos "elaboradas".

Cuando elegimos usar lo de otro y ese algo es cerrado por su
  definición (en términos del otro), elegimos perder la posibilidad
  de escapar de los limites impuestos por ese otro (por lo general
  dados por limitaciones del contexto para el que las diseñó
  y en el pasado).

> Lamentablemente los investigadores no eligen los estándares de la
> industria, los estándares los eligen los capitales ( y no suelen basarse
> en lo técnicamente mejor), por lo que  los desarrolladores tienen, la
> mayoría de las veces, adaptarse a lo que otros eligen.
> Por supuesto que no estoy de acuerdo con conformarse con las limitantes
> que nos imponen, pero muchas veces no queda otra.

Siempre te queda otra (si apuntas la flecha aparece el venado).

hasta pronto,
Ale.



----- Original Message -----
From: "Mariano Wahlmann" <mariano.wahlmann@...>
To: <smalltalking@...>
Sent: Sunday, November 26, 2006 8:25 PM
Subject: Re: [objetos] Aplicaciones web?


> Hola Ale,
>
>  >Si aceptamos ese rol, no podemos pensar en ser reconocidos
>  >por algo mejor que unir las partes que otros eligen...
>  >un buen pegador de piezas que unos pocos diseñan
>
> Creo entender lo que decís, y según entiendo es inevitable y necesario.
> Necesario porque no podemos pretender empezar de cero siempre,
> necesitamos basarnos en el avance de otros para hacer nuestro propio
> avance, caso contrario estaríamos diseñando software con tarjetas
> perforadas.
> Lamentablemente los investigadores no eligen los estándares de la
> industria, los estándares los eligen los capitales ( y no suelen basarse
> en lo técnicamente mejor), por lo que  los desarrolladores tienen, la
> mayoría de las veces, adaptarse a lo que otros eligen.
> Por supuesto que no estoy de acuerdo con conformarse con las limitantes
> que nos imponen, pero muchas veces no queda otra.
>
> Saludos,
>
>
>
> Para más información sobre la Asociación escribir a info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
desarrollo en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm
>
> Enlaces a Yahoo! Grupos
>
>
>
>
>

kiko,
profiling....
Medí donde se va el tiempo.
Considerá el hacer lo que es lento una de tantas veces.
Ale.


----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Monday, November 27, 2006 9:40 AM
Subject: [objetos] Genesis3D: RenderLoop


> Hola Ale
>
>   Quería hacerte una consulta sobre el renderLoop.
>   Se trata de la lectura del teclado con DirectX. Lo implemente, pero
tengo dudas de donde hacer dicha lectura.
>   Por un lado probé tomando el estado dentro del renderLoop que limita el
frameRate y luego fuero.
>   Los resultados fueron distintos como se podría esperar, dentro del
renderLoop es más lento el efecto visible en los objetos que son afectados.
>   Mientras que por fuero el efecto es más rápido, es decir las cosas se
mueven mas rápido.
>
>   La pregunta es esto debería hacerlo dentro o fuero del renderLoop ¿?
>   Se me ocurre que debería ser dentro. No??
>   El renderLoop te impone de este tipo de limitaciones a la hora de hacer
algo ¿?.
>
>   Saludos kiko
>
>  __________________________________________________
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

----- Original Message -----

From: Germán Arduino

To: smalltalking@...

Sent: Monday, November 27, 2006 9:43 AM

Subject: [SPAM] Re: [SPAM] Re: [objetos] Aplicaciones web?

Hola Angel:

Me han parecido interesantes tus comentarios:

> lo que cuenta es que el cliente final lo encuentre util.

> Y eso es lo que ha pasado. No ha
> habido, ni de la comunidad de Java con applets, o de Smalltalk (aunque no
> conozco todas las alternativas planteadas), una respuesta que haya hecho que
> la gente que toma las decisiones y tiene que responder por las inversiones,
> tomara una alternativa. No niego que en algun contexto, momento, la gente de
> tecnologia se vea arrastrada por el "mainstream", y elija la tecnologia que
> se conoce, pero tampoco he visto que se haya producido y ADOPTADO una
> solucion alternativa.

> No carguemos las culpas en otro.

> Smalltalk y su comunidad ha tenido decadas de oportunidad
> de cruzar el abismo, en algun ambito lo habra cruzado, pero no en otros....

Esto último particularmente........en muchos aspectos el abismo no se ha cruzado.

Con respecto al libro ("Crossing the chasm") se consigué en Argentina (no lo vi en Cúspide...o mejor, se consigue en pdf o algo asi?

Saludos.

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Hola gente!

Elvio, me temo que no comparto la idea de que alguien vino y "corto las
piernas". Lo que paso es que la killer application ha sido la web. El
cliente, la empresa, quiere retorno sobre la inversion. He visto
aplicaciones web basadas en browser (muchas en las que tambien he
trabajado), y han cumplido con las expectativas. Creo que desde el punto de
vista de la tecnologia, solo afecta a la parte de presentacion, y de
recoleccion de eventos del usuario. Luego, por abajo podrias tener lo que
quieras, llamese PHP con transaction scripts, como un GemStone, o lo que
quieran.

Pero el tema nacio por tu reaccion contra la web, creo entender tu reaccion
contra PHP (veria algo de PHP5 y Prado, igualmente). Insisto: lo que cuenta
es que el cliente final lo encuentre util. Y eso es lo que ha pasado. No ha
habido, ni de la comunidad de Java con applets, o de Smalltalk (aunque no
conozco todas las alternativas planteadas), una respuesta que haya hecho que
la gente que toma las decisiones y tiene que responder por las inversiones,
tomara una alternativa. No niego que en algun contexto, momento, la gente de
tecnologia se vea arrastrada por el "mainstream", y elija la tecnologia que
se conoce, pero tampoco he visto que se haya producido y ADOPTADO una
solucion alternativa.

No es que alguien viene y corta las piernas... Solamente que no nos
crecieron, o si nos crecieron, no las hicimos notar... No carguemos las
culpas en otro.

De nuevo, por tercera vez, "no cruzamos el abismo".... leer Crossing the
chasm, de Moore. Smalltalk y su comunidad ha tenido decadas de oportunidad
de cruzar el abismo, en algun ambito lo habra cruzado, pero no en otros....

Como siempre, son solo (y nada menos) que opiniones personales.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/



----- Original Message -----
From: Elvio Fernandez
To: smalltalking@...
Sent: Sunday, November 26, 2006 11:53 PM
Subject: Re: [SPAM] Re: [objetos] Aplicaciones web?


Hola Angel que tal?

"> 3) Browser de internet no existe. El Smalltalk no le tiene que decir a
> nadie
> qué debe hacer. No es contenido por nadie. La imagen es autosuficiente. No
> es un browser de HTML, es de aplicaciones.

Que imagino como por lo menos una ventana donde el Smalltalk deje su parte
visual, y una imagen corriendo. Ahora, en la practica (dejando de lado
alguna disquisicion sobre cantidad de ventanas y su manejo), esto podria
asimilarse a la 2:

> 2) Un plugin en el browser de internet, la tesitura de Flash. El browser
> es
> un contenedor, el plugin se encarga de todo o casi todo.

(yo podria traducir como "la tesitura de Java con Applets de hace 11
anios")"

Veo que vas un paso adelante y ya lo vas imaginando. Pero esa es una
interpretacion de la idea. Como implementaria la idea segun mi? No tengo la
mas minima idea :) eso es un camino que habria que discutirlo, pensarlo y
repensarlo. Sobre todo si seria algo distinto (esa es la idea) a lo que el
mercado nos insiste en que debemos usar.

(yo podria traducir como "la tesitura de Java con Applets de hace 11 anios")

totalmente de acuerdo con la 2). Pero lo loco es que estemos discutiendo
esto ahora a finales del 2006. Que paso durante esos 11 años?? Alguien nos
corto las patas!! que paso? Alguien vino con una motosierra y nos dijo:
"bueno hoy me llevo tus piernas pero te doy una silla de ruedas buenisimas
eh!! esto es lo que dicen todos que es la entrada al futuro. Esta silla te
permite reusar y es la evolucion de las sillas de ruedas. En el futuro nadie
va a usar las piernas. Va a doler un poquito pero con el tiempo ya no duele
y uno se acostumbra a la silla..." y nos llevo las piernas!! Lo digo para
que se entienda en el contexto hasta historico en el que hablamos. Hay un
vacio muy grande con respecto a alternativas en lo que conocemos como web
desde hace bastante.

Es un poco odioso entrar en comparaciones entre Java y Smalltalk es muy
dificil comparar una cosa con la otra. Yo en un principio utilice la idea de
Applet para que se entienda la idea pero ahora me retracto de esa
comparacion porque no se parece. Simplemente porque uno es Java y otro
Smalltalk.

Saludos
Elvio

Perdón, me faltó el saludo!

2006/11/27, Germán Arduino <garduino@...>:
> Hola Angel:
>
> >    Hmmmm... He visto a gente que lo encarado de esta forma: destina parte
> de
> >    sus recursos (personales, o de su empresa) al tema investigacion, para
> >    lograr algo nuevo. Y si eso nuevo puede transformarse en una solucion a
> un
> >    problema, podra alcanzar el paso de investigacion a algo en produccion.
>  >   Claro que no es facil, pero puede ser un camino, que no queria dejar de
>  >   comentar.
>
> Si, estoy de acuerdo, sólo hago dos comentarios:
>
> 1) En el ámbito de pequeño emprendimientos como el mío, es tal como vos
> decís, no es fácil, no es nada fácil. Es un tema de recursos, que casi
> siempre son escasos.
>
> 2) En ámbitos que SI tienen los recursos (personas, tiempo, dinero) es una
> práctica (la investigación) cada vez menos usada, al menos en los casos de
> las empresas que conozco. Creo que esto está muy relacionado con lo que
> comenta Ale en otro mail, el tema de la gente que dirige sin saber de un
> tema, sin haber recorrido camino en ese rubro, sin poder de ninguna manera
> "sentir" estas cosas.
>
> Salen despavoridos bajando líneas de "no investigación" y en forma paralela,
> "tercerización" con la fantasía que podrán comprar el
> conocimiento.........sin entender que no se puede comprar la experiencia,
> pero bueno, ya me fui por las ramas.
>
> > Creo que para que algo realmente importe en su ambito, debe
> >   producir efecto. Y en software, ese efecto es su uso. Debe haber en
> algun
> >    momento el paso de la idea a la distribucion, esa es la medida del
> "exito"
> >    de una idea de software.
>
> Si, esto es claro, si se usa es exitoso, si decimos que éxito es igual a uso
> masivo.
>
> No se si para todo el mundo significa lo mismo esa palabra, quizás por
> ejemplo, para alguien un éxito podría haber sido resolver un problema
> interno de su empresa con algo investigado/desarrollado, sin haber alcanzado
> un uso masivo.
>
>
> Bueno, es todo por ahora, saludos!
>
>


--
Germán S. Arduino
http://www.arsol.biz
http://www.arsol.net

Hola Ale,

  >Si aceptamos ese rol, no podemos pensar en ser reconocidos
  >por algo mejor que unir las partes que otros eligen...
  >un buen pegador de piezas que unos pocos diseñan

Creo entender lo que decís, y según entiendo es inevitable y necesario.
Necesario porque no podemos pretender empezar de cero siempre,
necesitamos basarnos en el avance de otros para hacer nuestro propio
avance, caso contrario estaríamos diseñando software con tarjetas
perforadas.
Lamentablemente los investigadores no eligen los estándares de la
industria, los estándares los eligen los capitales ( y no suelen basarse
en lo técnicamente mejor), por lo que  los desarrolladores tienen, la
mayoría de las veces, adaptarse a lo que otros eligen.
Por supuesto que no estoy de acuerdo con conformarse con las limitantes
que nos imponen, pero muchas veces no queda otra.

Saludos,

Hola gente!

Algunos comentarios al mensaje de German:

>>>
Por otro lado el condicionante de los demás, a veces es el del mercado o la
industria o como quieras llamarlo que un
simple productor de software (como yo) dificilmente pueda romper.
>>>

Creo que algo se puede hacer. Se puede plantear el desarrollo de algo que
sea diferente y se pueda implementar como solucion. Recomendaria (nuevamente
en la lista) la lectura de libros como Crossing the chasm de Moore. Debe
haber algunos mas que explican la adopcion de nueva tecnologia, y con otras
ideas (discutibles, pero interesantes).

>>>
A ver si me explico mejor, si un cliente quiere una aplicación web,
dificilmente yo pueda ofrecerle algo diferente (que por el momento no sabría
siquiera que es ese algo diferente). Eso luego, también se relaciona con
temas tan .....gruesos, como tener que vivir, con lo cual, muchas veces no
es tan fácil pensar en cosas nuevas, casi de laboratorio, o de
investigación, con el riesgo (de no tener clientes, de no poder vender, de
no poder facturar) que eso implica.

Si uno se pudiera poner a divagar solamente, sin necesitar trabajar, quizás
sería muy distinto todo, o yo pensaría diferente, no lo se, pero en el día a
día se hace difícil, al menos para mi.

>>>

Hmmmm... He visto a gente que lo encarado de esta forma: destina parte de
sus recursos (personales, o de su empresa) al tema investigacion, para
lograr algo nuevo. Y si eso nuevo puede transformarse en una solucion a un
problema, podra alcanzar el paso de investigacion a algo en produccion.
Claro que no es facil, pero puede ser un camino, que no queria dejar de
comentar. Creo que para que algo realmente importe en su ambito, debe
producir efecto. Y en software, ese efecto es su uso. Debe haber en algun
momento el paso de la idea a la distribucion, esa es la medida del "exito"
de una idea de software.

Correcion a un mensaje mio anterior: era el bueno de Leandro (no Alejandro)
Caniglia al que hacia referencia..... Hace anios que no lo veo, me alegro
verlo mencionado en el prologo del ultimo libro de Adrian Paenza....

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

----- Original Message -----
From: Germán Arduino
To: smalltalking@...
Sent: Sunday, November 26, 2006 3:49 PM
Subject: [SPAM] Re: [objetos] Aplicaciones web?


Hola Ale:

>    Hola Germán,

>    Concuerdo con vos en los argumentos sin sustento técnico....

Hola Germán,

>Como muchas veces me ocurre intercambiando ideas con vos,
> siento que hablamos de cosas diferentes.

Si, soy de mezclar las cosas... perdoname, no puedo evitarlo.

>Bueno, aún corriendo ese riesgo y mi quizás estrechez para
> no ver lo que vos ves o a lo que vos apuntás voy a dejar mis
> opiniones.

Te aseguro que al leer el mail de Elvio, me propuse
  enumerar(me) las ventajas que tenía una "aplicación web"
  relacionada con el browser, y no encontré puntos
  relevantes/claros... por eso tiré la pregunta, derivandome
  después en otros temas.

>Hoy en día, a mi particularmente me resulta mucho más fácil
> y productivo resolver problemas de una aplicación en un
> sólo lugar, en el server (como lo era en los viejos tiempos
> de los mainframes)

Si, sin lugar a dudas es mejor tener "una sola aplicación"...

> que deambular por n equipos cliente viendo que cosa falla
> en cada uno,

Lo que decía, y que creo que compartirás, es que
  si una aplicación es distriuida, cada lugar dónde
  se vea reflejada es un lugar que presenta la posibilidad
  de presentar emergentes/situaciones particulares...
  y es de la naturaleza de un sistema distribuido el
  que presente diversidad (mas aun en sistemas usados
  por gente muy distinta).

El reducir esas diferencias a "una sola aplicación"
  es un ideal...

>peor aún si esos equipos usan esa
>montaña de elementos que no funcionan llamada Win....

:-) o cualquier otra cosa heterogénea.
No importa que marca de cascotes uses, el efecto
  resulta de tener una arquitectura y prentender
  un modelo de construcción universal
  (me recuerda algunos artículos sobre patrones
  haciendo mención a que siempre
  hay arcadas/puertas/ventanas,como si eso las
  hiciera mas similares).

>>>y hacer deploy fácilmente y algunas otras.

>> El deploy de "aplicaciones" hechas con ambientes
>> siempre fue muy simple/fácil.
>> A que facilidad haces referencia?
>> Con respecto a que lo comparamos?
>Hmmm, quizás deploy no es la mejor palabra.........
>me refiero a poner en producción o meter cambios
> en algo que está corriendo en un sólo lugar,
>versus n máquinas diferentes (lo mismo del párrafo anterior).

Si te entiendo, pero el punto que quería mencionar pasa
  por lo que decías "en ALGO que esta corriendo"...
  como si fuera UNA sola cosa en distintos lugares.
Creo que cuando pensamos en "una" aplicación
  que se instancia en distintos lugares como si fuera
  un solo sistema, estamos abstrayéndonos de la realidad,
  estamos perdiendo (adrede) las diferencias particulares
  de cada lugar no porque no sean manejables con objetos,
  sino porque no son manejables de forma tradicional
  (y heredamos ese miedo a lo diverso por conocer
  el costo que tiene abordarlo de forma tradicional).

>> Con esto que estoy comentando, no deseo en absoluto
>> desmotivar ningún emprendimiento (sería torpe desear
>> que otros no hagan), sino solamente motivar a la
>> reflexión sobre que genera esa energía invertida en
>> "ir hacia atrás"; y motivar la inversión de energías
>> en temas mas prometedores en términos de TO
>> (aunque sean temas que no tengan tantos seguidores)
>Creo imaginar a lo que te referís, pero sin embargo pienso
> que ese tipo de avances (de los cuales solo alcanzo a pensarlos
> como "algo muy diferente" ) no están al alcance la mayoría
> de nosotros.

Creo que están al alcance, pero nos distraen los
  problemas que nos plantean los demás y veo que
  esto ocurre mucho mas hoy que hace apenas 5-10 años.

>Por otro lado el condicionante de los demás, a veces es
> el del mercado o la industria o como quieras llamarlo
> que un simple productor de software (como
> yo) dificilmente pueda romper.

Las cosas que son periféricas sirven justamente para
  abordar lo marginal.

>A ver si me explico mejor, si un cliente quiere una aplicación
> web, dificilmente yo pueda ofrecerle algo diferente
> (que por el momento no sabría siquiera que es ese algo diferente).

Si él/ella te dice que quiere "una aplicación"....
Vos empezas haciendo la clase Aplicación ?
mmm :-)

>Eso luego, también se relaciona con
>temas tan .....gruesos, como tener que vivir,
> con lo cual, muchas veces no es tan fácil
> pensar en cosas nuevas, casi de laboratorio, o de
> investigación, con el riesgo (de no tener clientes,
> de no poder vender, de no poder facturar)
> que eso implica.

Es muy difícil si los demás te dicen que es lo que
  vos tenes que hacer.
Incluso, creo que si los demás nos dicen también
  como se hace... no sería honesto percibir valores
  por solo "codificarlo".

Creo que hoy en día la gente de sistemas
  esta mas acostumbradaA/preparadaPara que
  quienes no saben le digan que desean que les hagan...
Esta actitud es muy común y se refleja en razonamientos
  como "todo el mundo quiere algo web" (antes era
  "algo en VBasic", etc :)
Si aceptamos ese rol, no podemos pensar en ser reconocidos
  por algo mejor que unir las partes que otros eligen...
  un buen pegador de piezas que unos pocos diseñan
  para todo el mundo (y no estoy hablando de M$ que
  ya es historia en esto)

hasta pronto,
Ale.


----- Original Message -----
From: "Germán Arduino" <garduino@...>
To: <smalltalking@...>
Sent: Sunday, November 26, 2006 3:49 PM
Subject: Re: [objetos] Aplicaciones web?


Hola Ale:

>    Hola Germán,

>    Concuerdo con vos en los argumentos sin sustento técnico
>   sobre las bondades del desarrollo de aplicaciones usando
>    browser(s) de Internet, y es muy frecuente escuchar esos
>    argumentos en casi todos los medios usados para
>    promocionar esta alternativa de soporte de sistemas
>    en varios lugares.

>    Sobre las características:
  >   >como la posibilidad de centralizar

>    Esta característica siempre estuvo presente, creo
>    que ha sido (y es hoy) la única forma a la que se
>    atreve la gente de informática a dar soporte...
>    Es decir, solo nos atrevemos a dar soporte a algo
>    en dónde la diversidad está ausente... damos
>    soporte así a piezas únicas, y para ello es
>    eficiente/suficiente el trabajo declarativo y formal.

Como muchas veces me ocurre intercambiando ideas con vos, siento que
hablamos de cosas diferentes. Bueno, aún corriendo ese riesgo y mi quizás
estrechez para no ver lo que vos ves o a lo que vos apuntás voy a dejar mis
opiniones.

Hoy en día, a mi particularmente me resulta mucho más fácil y productivo
resolver problemas de una aplicación en un sólo lugar, en el server (como lo
era en los viejos tiempos de los mainframes) que deambular por n equipos
cliente viendo que cosa falla en cada uno, peor aún si esos equipos usan esa
montaña de elementos que no funcionan llamada Win....

>>y hacer deploy fácilmente y algunas otras.

> El deploy de "aplicaciones" hechas con ambientes
> siempre fue muy simple/fácil.
> A que facilidad haces referencia?
> Con respecto a que lo comparamos?

Hmmm, quizás deploy no es la mejor palabra.........me refiero a poner en
producción o meter cambios en algo que está corriendo en un sólo lugar,
versus n máquinas diferentes (lo mismo del párrafo anterior).

> Aunque usando ambientes podamos ambicionar más
> nosotros mismos muchas veces pensamos con los
> condicionantes que existen para quienes no usan
> objetos y nos hacemos cargo de sus objetivos como
> si fueran limitantes para nosotros.
> Esta afinidad casi constante a la que nos sometemos
> (nos hacemos cargo de las limitaciones de los otros)
> no es una característica única de los desarrollos
> para web, sino que se puede observar el mismo
> proceso involutivo en temas como persistencia (de
> datos!), GUI (como por ejemplo la vuelta a
> propuestas como morphic) o prototipos (como
> descomposiciones atómicas del comportamiento
> sin ambicionar estructuras de mayor nivel).

> Hoy es muy frecuente escuchar planteos y ver estructuras
> montadas sobre objetos (usando Smalltalk) para resolver
> problemas que anteriormente se rechazaban de plano
> por identificarlos como problemas inexistentes.
> Los efectos de esta actitud que hoy se observa,
> debe ser analizados con mas cuidado que años atrás,
> y observar que se produce en la(s) comunidad(es)
> Smalltalk...

> Con esto que estoy comentando, no deseo en absoluto
> desmotivar ningún emprendimiento (sería torpe desear
> que otros no hagan), sino solamente motivar a la
> reflexión sobre que genera esa energía invertida en
> "ir hacia atrás"; y motivar la inversión de energías
> en temas mas prometedores en términos de TO
> (aunque sean temas que no tengan tantos seguidores)

Creo imaginar a lo que te referís, pero sin embargo pienso que ese tipo de
avances (de los cuales solo alcanzo a pensarlos como "algo muy diferente" )
no están al alcance la mayoría de nosotros.

Y por lo que se ve en general, no están al alcance de la mayoría, ya que
como vos dijiste, se siguen viendo esas mismas soluciones con nuevos
nombres.

Por otro lado el condicionante de los demás, a veces es el del mercado o la
industria o como quieras llamarlo que un simple productor de software (como
yo) dificilmente pueda romper.

A ver si me explico mejor, si un cliente quiere una aplicación web,
dificilmente yo pueda ofrecerle algo diferente (que por el momento no sabría
siquiera que es ese algo diferente). Eso luego, también se relaciona con
temas tan .....gruesos, como tener que vivir, con lo cual, muchas veces no
es tan fácil pensar en cosas nuevas, casi de laboratorio, o de
investigación, con el riesgo (de no tener clientes, de no poder vender, de
no poder facturar) que eso implica.

Si uno se pudiera poner a divagar solamente, sin necesitar trabajar, quizás
sería muy distinto todo, o yo pensaría diferente, no lo se, pero en el día a
día se hace difícil, al menos para mi.

Saludos.

Hola gente!

Quisiera comentar sobre la frase de Alejandro:

> 3) Hacer lo que siempre hemos hecho; los objetos hacen
> la "suya" y se montan sobre una plataforma transparente.

Entiendo que Alejandro se refiere en esto a la opcion 3) de Elvio:

> 3) Browser de internet no existe. El Smalltalk no le tiene que decir a
> nadie
> qué debe hacer. No es contenido por nadie. La imagen es autosuficiente. No
> es un browser de HTML, es de aplicaciones.

Que imagino como por lo menos una ventana donde el Smalltalk deje su parte
visual, y una imagen corriendo. Ahora, en la practica (dejando de lado
alguna disquisicion sobre cantidad de ventanas y su manejo), esto podria
asimilarse a la 2:

> 2) Un plugin en el browser de internet, la tesitura de Flash. El browser
> es
> un contenedor, el plugin se encarga de todo o casi todo.

(yo podria traducir como "la tesitura de Java con Applets de hace 11 anios")

Podriamos plantear

23) La imagen se obtendria del servidor, correria en el cliente, via el
cliente y se guardaria en el servidor. No seria una forma de llegar a las
opciones 3)? Veo un paralelismo con:

La imagen se obtendria de X, correria en el cliente, albergado en el sistema
operativo cliente, y se guardaria en X.

Lo que hacemos hoy con

La imagen la obtengo de mi maquina, corre en mi maquina, albergado en el
sistema operativo de mi maquina, y se guarda en mi maquina.

Tambien podriamos considerar alguna forma de utilizar el browser como un
visor remoto de alguna imagen corriendo en la red (visor de la parte grafica
que la imagen quiera mostrar), a la Citrix o XWindow....

Siguiendo y extendiendo la idea, entonces, el sistema Smalltalk con su
imagen o imagenes asociadas, podria estar corriendo en una maquina (remota
si quieren verla asi) o en un grid, o lo que quieran inventar, y luego el
(browser/plugin/aplicacion cliente) solo mostraria lo que el sistema
Smalltalk quiere mostrar para ese cliente conectado.

La interaccion con el cliente seria solamente una parte, una punta de un
iceberg, de un sistema ejecutandose en algun lado de la red, hoy en
Smalltalk, o en lo que sea que se adecue a esta funcionalidad. No seria como
en la opcion 3 de Elvio "la imagen es autosuficiente", porque supongo que en
esa opcion Elvio suponia la imagen en el cliente. Aca la imagen esta en otro
lado. Podriamos discutir si la aplicacion cliente es Smalltalk, un plugin en
C++, Flash (para reaprovechar el browser), o lo que sea,  la idea es que la
imagen este ejecutando en otro lado, el cliente ve lo que necesita ver y
envia sus eventos/gestos a quien corresponda.

De hecho, muchas aplicaciones (sea como sea que definan aplicacion) siguen
la pauta:

- La aplicacion corre en un servidor de aplicaciones
- El cliente interactura via alguna tecnologia, ya sea formularios graficos,
ventanas SWING, paginas web, Flash, applets en el browser, etc....

Recuerdo aun a Alejandro Caniglia, mostrandome varios clientes Smalltalk que
se comunicaba con un servidor Smalltalk.... Pero no estoy seguro que lo que
habia implementado se adecue a esto que estoy describiendo....

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/


----- Original Message -----
From: Alejandro F. Reimondo
To: smalltalking@...
Sent: Saturday, November 25, 2006 12:40 PM
Subject: [SPAM] Re: [objetos] Aplicaciones web?


Hola gente,

El "pasar" por el browser... que beneficios trae ?
quizás sea bueno aclarar/estudiar ese punto (ante nuestra
óptica, es decir, construcción de un sistema de objetos
en espacios físicamente discontinuos)....

Hola Germán,

Concuerdo con vos en los argumentos sin sustento técnico
  sobre las bondades del desarrollo de aplicaciones usando
  browser(s) de Internet, y es muy frecuente escuchar esos
  argumentos en casi todos los medios usados para
  promocionar esta alternativa de soporte de sistemas
  en varios lugares.

Sobre las características:
>como la posibilidad de centralizar

Esta característica siempre estuvo presente, creo
  que ha sido (y es hoy) la única forma a la que se
  atreve la gente de informática a dar soporte...
Es decir, solo nos atrevemos a dar soporte a algo
  en dónde la diversidad está ausente... damos
  soporte así a piezas únicas, y para ello es
  eficiente/suficiente el trabajo declarativo y formal.

>y hacer deploy fácilmente y algunas otras.

El deploy de "aplicaciones" hechas con ambientes
  siempre fue muy simple/fácil.
A que facilidad haces referencia?
Con respecto a que lo comparamos?

Aunque usando ambientes podamos ambicionar más
  nosotros mismos muchas veces pensamos con los
  condicionantes que existen para quienes no usan
  objetos y nos hacemos cargo de sus objetivos como
  si fueran limitantes para nosotros.
Esta afinidad casi constante a la que nos sometemos
  (nos hacemos cargo de las limitaciones de los otros)
  no es una característica única de los desarrollos
  para web, sino que se puede observar el mismo
  proceso involutivo en temas como persistencia (de
  datos!), GUI (como por ejemplo la vuelta a
  propuestas como morphic) o prototipos (como
  descomposiciones atómicas del comportamiento
  sin ambicionar estructuras de mayor nivel).

Hoy es muy frecuente escuchar planteos y ver estructuras
  montadas sobre objetos (usando Smalltalk) para resolver
  problemas que anteriormente se rechazaban de plano
  por identificarlos como problemas inexistentes.
Los efectos de esta actitud que hoy se observa,
  debe ser analizados con mas cuidado que años atrás,
  y observar que se produce en la(s) comunidad(es)
  Smalltalk...

Con esto que estoy comentando, no deseo en absoluto
  desmotivar ningún emprendimiento (sería torpe desear
  que otros no hagan), sino solamente motivar a la
  reflexión sobre que genera esa energía invertida en
  "ir hacia atrás"; y motivar la inversión de energías
  en temas mas prometedores en términos de TO
  (aunque sean temas que no tengan tantos seguidores)

hasta pronto,
Ale.


----- Original Message -----
From: "Germán Arduino" <garduino@...>
To: <smalltalking@...>
Sent: Sunday, November 26, 2006 9:45 AM
Subject: Re: [objetos] Aplicaciones web?


2006/11/25, Elvio Fernandez <elvio.fernandez@...>:
>
>   Ale, muy piola lo que decis. Fue como un baldazo de agua fria para mi :)
> [ y es muy bienvenido ]
>
> > " El "pasar" por el browser... que beneficios trae ?"
> > A mi entender ninguno, solo limitaciones
>
>
>


Yo creo que si trae beneficios, quizás no en lo técnico pero si en aspectos
como que todas las PC tienen al menos un browser, como la posibilidad de
centralizar y hacer deploy fácilmente y algunas otras.

Aqui me parece importante separar las cosas, porque los beneficios o no,
ventajas o desventajas, de ningún modo pueden considerarse de manera
absoluta, sino que siempre son relativas al contexto y a las necesidades del
que opina.

Me parece perfecto explorar posibilidades como las que Elvio sugiere, pero
no me parece realista ignorar la importancia (para objetivos comerciales)
que hoy tiene el browser. Sino, basta con mirar las aplicaciones de Google
(que llegaron al mundo gracias al browser).

Repito, no estoy hablando de temas técnicos e insisto con el hecho que si
tengo que trabajar acorde a necesidades actuales, de clientes reales que
pagan por un sistema, no veo nada de malo en aguzar el uso y posibilidades
de los ambientes como Smalltalk (aunque sea via un browser) antes que
ponerme a hacer PHP, Perl, o cualquiera de esas cosas.

Saludos.

--
Germán S. Arduino
http://www.arsol.biz
http://www.arsol.net

Se sigue usando. Hay muchas aplicaciones que simplementen ponen un
enlace en una web (con extensión .jnlp) y Java WebStart se encargar de
hacer lo demás. pero, a excepción del enlace en la web, no deja de ser
un "squeakmap".

Germán Arduino escribió:
> Hola Elvio:
>
> 2006/11/24, Elvio Fernandez <elvio.fernandez@...>:
>>
>>   Parece que hay tres tesituras para dicernir:
>>
>> 1) Utilizar el browser de internet como una especie de API a bajo nivel.
>> El Smalltalk con algun mecanismo le dice al browser (en el lenguaje que
>> entiende el browser) qué debe hacer y qué debe mostrar.
>>
>> 2) Un plugin en el browser de internet, la tesitura de Flash. El browser
>> es un contenedor, el plugin se encarga de todo o casi todo.
>>
>> 3) Browser de internet no existe. El Smalltalk no le tiene que decir a
>> nadie qué debe hacer. No es contenido por nadie. La imagen es
>> autosuficiente. No es un browser de HTML, es de aplicaciones.
>>
>> La (3) es la proto-idea que planteo. Pero el tema es medio faraonico e
>> idealista, y aparentemente poco aplicable por la generalidad de los
>> desarrollares y poco accesible para el usuario final (por el tema que
>> browser ya lo tiene todo el mundo).
>>
>>
>
>
>
>
> Me parece que el (3) es un camino más que no estaría mal explorar. Si
> mal no
> recuerdo existía algo que se llamba Java Web Start que hacía algo asi. Es
> decir, desde un programita inicial que corría como desktop (apoyado en la
> JVM, claro)  se bajaba por demanda lo que se necesitaba, no existía el
> browser. No se qué repercusión habrá tenido ni si se usará aún, pero en su
> momento lo había visto.
>
> Saludos.
>


--
Giuseppe Luigi Punzi
Linux User: #370919
Skype: glpunzi
http://www.lordzealon.com

Hola gente,

El "pasar" por el browser... que beneficios trae ?
  quizás sea bueno aclarar/estudiar ese punto (ante nuestra
  óptica, es decir, construcción de un sistema de objetos
  en espacios físicamente discontinuos)
  para poder evaluar (luego) el costo que esto implica
  y que cosas nos impide realizar (que grado de
  protagonismo nos permite).

Me parece incorrecto intentar un análisis dónde
  no es relevante el concepto de "aplicación" (respetando
  antetodo el titulo de este track) y aquí encuentro (antes
  de llegar a la primer ventaja) un condicionante fuerte de
  índole pseudo-cultural (insuperable por definición).

En un marco dónde la "Aplicación" define los limites
  del desarrollo, concuerdo con Elvio en las posibilidades
  que se nos presentan:
1) montar nuestra "aplicación" SOBRE una API (es decir,
  describir la relación como determinadas por capas
  con limites fuertes).
2) vincular nuestra aplicación al mismo nivel que otras
  (componentes oscuros, dónde las responsabilidades parecen
  estar acotadas, y están si, fuertemente definidas), que, creo
  es otra forma de dibujar a (1) o una extensión de esta
  dónde se reconoce otros actores/componentes de igual
  importancia (e incumbencia) que nuestra aplicación.
3) Hacer lo que siempre hemos hecho; los objetos hacen
  la "suya" y se montan sobre una plataforma transparente.

Creo que (1) y (2) son lo mismo, porque nos hace padecer
  las restricciones (siempre fuertes) de los componentes
  y nos ubican en el rol de usuarios de piezas de software
  (en el mejor de los casos) que no podremos cambiar
  ni elegir si las usamos o no (ejemplos de esto ultimo
  tenemos muchisimos, para dar uno, tenemos el usar
  la representación XML para "objetos", donde en lo formal
  parece ser suficiente, pero en la práctica vemos aplicarse
  solo la forma mas berreta y equivalente a la utilizada en
  Smalltalk en los tiempos del #storeOn: ).
El aceptar esquemas de este tipo nos fuerza a volver atrás
  más de una década en temas que habían sido resueltos
  y que por más que queramos no podremos evitar ni
  esquivar sus consecuencias.
Esto no es nuevo ni característico del tema Web, sino que
  ocurre siempre que usamos componentes (interfaces fuertes
  como puentes a tecnologías anteriores a objetos);
  lo que me sorprende (en realidad no tanto :) es que
  la experiencia hecha en las últimas décadas no se haga
  valer y sea ignorada por completo (aquí encuentro una
  relación con lo que les comentaba sobre el efecto de
  gente nueva en Smalltalk... y cómo se pierden elementos
  de valor ya obtenidos dado que no hay posibilidad de
  enseñar antes de "mostrar" lo que se hace).

Con lo de arriba parecería que me motiva muuuucho mas
  la opción (3); cosa que no es tan así, pues soy consciente
  que pese a ser la mas usada (por smalltalkers) hoy no
  hay capacidad técnica suficiente como para realizarlas en
  la práctica (son muy pocos los que se embarcan en
  soluciones como esta, y quizás en el corto plazo siga
  disminuyendo el número).
Con respecto a (3).. es la forma "rosa" de resolverlo,
  es muy inocente y de difícil aplicación por la presión
  del contexto técnico-social a la que todos nos sentimos
  afectados.
Esa presión es el mayor inhibidor de emprendimientos
  de este tipo, y tiene éxito porque por lo general quienes
  desean hacer su "primera" experiencia de esta forma (en
  un contexto de producción... no como ensayo personal
  ni como un hueso para roer en grupo...) no cuentan
  con el soporte técnico (ni aliento) suficiente para dar
  confianza a otros. Una forma de tener éxito, esta vinculada
  con que exista el aval de alguien que ya lo haya hecho
  y sea respetado técnicamente o tome responsabilidad
  en el tema; pero para ser sincero, debo decir que no
  hay mucha posibilidad hoy de tener ese aval (creo que
  en gran medida por lo que decía arriba y porque hace
  ya mas de una década que arrancó este proceso de
  desmantelamiento de alternativas).

Smalltalk, como soporte para la construcción de software
  tiene características inobjetables para permitirnos crecer
  en una dirección que es definida por lo popular como
  "marginal".
La utilización de Smalltalk (en todo su potencial y con decoro)
  en alternativas populares siempre esta condicionada (por
  definición) y es de carácter sufrido.
El tratar de disolver esa marginalidad o el integrar Smalltalk
  con herramientas que proponen modelos mas atómicos no es
  suficiente, a mi entender, e incluso alientan a pensar que todo
  da lo mismo... (razonamiento equivalente al plantear que algo
  abajo o al costado puede ser transparente). Cuando nos
  encontramos con la refrescante esperanza de que puede
  ser así, debemos seguir ese camino por un rato; pero luego
  reflexionar sobre la importancia que tienen los años
  y el riesgo que tiene (a nivel humano y no solo técnico)
  el alentar vínculos con cosas sin una robustez mínima dada
  por los años de uso y cambio contínuo.
El hacer un vinculo entre Smalltalk con una plataforma distinta
  se justifica si tenemos que hacerlo (por necesidad practica
  en un proyecto, y en ese caso el mérito es justo ese), pero
  de ninguna manera lo justificaría el hecho de hacerlo
  porque "podemos hacerlo"... no?

hasta pronto,
Ale.



----- Original Message -----
From: "Elvio Fernandez" <elvio.fernandez@...>
To: <smalltalking@...>
Sent: Friday, November 24, 2006 6:11 PM
Subject: Re: [objetos] Aplicaciones web?


Parece que hay tres tesituras para dicernir:

1) Utilizar el browser de internet como una especie de API a bajo nivel. El
Smalltalk con algun mecanismo le dice al browser (en el lenguaje que
entiende el browser) qué debe hacer y qué debe mostrar.

2) Un plugin en el browser de internet, la tesitura de Flash. El browser es
un contenedor, el plugin se encarga de todo o casi todo.

3) Browser de internet no existe. El Smalltalk no le tiene que decir a nadie
qué debe hacer. No es contenido por nadie. La imagen es autosuficiente. No
es un browser de HTML, es de aplicaciones.

La (3) es la proto-idea que planteo. Pero el tema es medio faraonico e
idealista, y aparentemente poco aplicable por la generalidad de los
desarrollares y poco accesible para el usuario final (por el tema que
browser ya lo tiene todo el mundo).

La (1) y (2) son caminos mas realistas y aplicables y seguramente
funcionalmente similares a lo mio. Es momento de que cierre el pico con este
tema, investigar mas y probar las cosas que me comentan.

Saludos gente y gracias.

Elvio