Aplicaciones Web?

*
*Voy a hacer una intro para que se entienda desde qué lugar voy a hacer mi
planteo.
Despues de transitar por unos cuantos lenguajes, empece a preguntarme,
estrictamente desde
el punto de vista del lenguaje, por que se pueden hacer las cosas que se
hacen en Smalltalk
y en otros lenguajes se puede hacer, lo mismo, con el triple de trabajo (en
algunos casos no se puede hacer
en otro lenguaje).
Asuminedo que en otros lenguajes se pueden aplicar los patterns, tambien me
parece que es para destacar,
que a medida que muchos desarrollos crecen, en Smalltalk las cosas son
relativamente simples
mientras que en los demas se pone todo cuesta arriba.

Tendria que ponerme a revisar la gramatica del lenguaje Smalltalk para
hablar con propiedad, pero como
todos sabemos, en Smalltalk los elementos que existen son objetos y
mensajes. A un nivel un poquito
mas abstracto: clases y metodos. Toda isntruccion esta definida en terminos
de objetos y mensajes
a excepcion de algunas construcciones como:*

":="  asignacion
"^"   retorno
"[]"  bloque literal
"()"  parentesis y arrays literales

*etc. Seguramente alguno me falta.
El Smalltalk es un lenguaje minimalista y absolutamente coherente, uniforme,
homogeneo. Esto posibilito que las
instrucciones de control e iteracion esten definidas en terminos de mensajes
por ej:
*
Boolean>>ifTrue:
Boolean>>ifFalse:
Boolean>>ifTrue:ifFalse:

*y permiten que el programador siga definiendo instrucciones de control a
necesidad*

Dictionary>>at:ifAbsent:
Collection>>ifEmpty:ifNotEmpty:
Object>>ifNil:ifNotNilDo:

*y asi una infinidad de ejemplos...
En otros lenguajes con orientacion a objetos las estructuras de control son
una entidad a parte definidas en el
lenguaje. Un "if" no es ni un objeto ni un mensaje, son una expresion, un
mecanismo incrustado
en el nucleo del lenguaje, un remanente de una orientacion procedural. Esta
claro en este punto que para modificar
esto es necesario modificar el lenguaje en si mismo.*

*A continuacion enumero la lista de keywords de Java:*
abstract,continue,for,new,switch,assert,default,goto,package,synchronized,boolean,do,if,private,this,
break,double,implements,protected,throw,byte,else,import,public,throws,case,enum,instanceof,return,
transient,catch,extends,int,short,try,char,final,interface,static,void,class,finally,long,strictfp,
volatile,const,float,native,super,while

*Podria poner ejemplos de C#, Delphi, Objective-C, etc. pero no van a ser
muy distintos.*

*Aunque no todos los keywords son estructuras de control, todos son
mecanismos empotrados en el nucleo del
lenguaje.
Supongamos que yo defino la clase Individual asi:*

Object subclass: #Individual
    instanceVariableNames: 'name'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'Test'

*con dos accesors como:*

Individual>>name:aValue
    name:=aValue.

Individual>>name
    ^name.

*si evaluamos lo siguiente en el Workspace*

|a b|

a:= Individual new.
b:= a name:'Elvio'.
b inspect.

*lo que obtenemos es la inspeccion de la instancia de Individual. En ningun
momento defini que en el setter
Individual>>name:  retorne algun valor. En Smalltalk todo metodo retorna un
valor. Si no se especifica, se retorna
el objeto receptor del mensaje. Ahora, que pasa con otros lenguajes? hay que
especificar explicitamente
que ese objeto va a retornar algo y si no lo hace, el valor de retorno debe
ser declarado void. En Smalltalk
no importa qué retorna un metodo, lo que importa es que siempre retorna
algo. Que objeto retorna? no importa, es un objeto!!
Esto es homogeneo y uniforme. Por tanto dependiendo de la implementacion de
un mensaje, este puede retornar
distintas clases de objetos. Esto en la mayoria de los lenguajes no se puede
hacer.
La cosntruccion de grandes jerarquias en Smalltalk es algo natural,
transparente. En otros lenguajes es necesario
declarar metodos virtuales, final, public, private, etc,etc.
La implementacion de patterns como el Observer, de una manera consistente y
bien funcional como se tiene en
Smalltalk, en otros lenguajes es realmente un desafio (gasto de energia)
tecnico. Por que? porque la
implementacion hecha en un lenguaje NO puro, NO es absolutamente homogenea.
La consistencia del Smalltalk en
gran parte obedece a su uniformidad en los mecanismos. Esto permite una
continuidad de esa uniformidad cuando
se utiliza el lenguaje.
En el momento de implementar no es necesario hacer rodeos ni bifurcaciones
en el tratamiento del computo,
por ejemplo: cómo implementar en Java un metodo que podria retornar
distintas clases de objetos?
Esto es un pequeño ejemplo. Hay un monton. Pero tener un lenguaje que
complica la construccion de grandes
jerarquias y ademas sin tratamiento homogeneo (deberia detenerme a hablar
del binding dinamico pero ahora no lo
voy a hacer) ya es suficiente como para obstaculizar las cosntrucciones de
grandes frameworks.*

*Cuando se tiene un dominio del problema que es realmente complejo, el
ejercicio de plasmar, modelar y diseñar
reflejará esa complejidad. En una resolucion hecha en Smalltalk el
protagonista es la complejidad del modelo en si,
para reflejar la complejidad del problema. El protagonista es el modelo, la
resolucion.

En otros lenguajes, el diseño deja de ser protagonista para ir a un segundo
plano. El protagonista es el lenguaje y sus
complicaciones tecnicas. Esto, en mi opinion, va directamente en detrimento
de la conclusion y la factibilidad del
desarrollo.*

*Ahora abandonando la intro sobre la homegeneidad y su potencia, el planteo
en si, tiene que ver con la
heterogeniedad en las aplicaciones Web. Me declaro un ferviente militante de
la abolicion de las aplicaciones web
como se las desarrolla hoy.
Despues de tanto trabajar sobre ese tipo de aplicaciones me pregunto por qué
hay que lidiar con tanta complejidad.*

*Supongamos una tipica aplicacion Web en internet, de esas que hay por
miles. Por cuántas tecnologias debe andar el
desarrollador en ese tipo de desarrollos. El tipico bloque de tecnologias
que implican (en orden desde el cliente
hacia el servidor) son:
HTML-CSS-Javascript->Apache->PHP->Modelo->Persistencia->BD. Si se quiere
algo
mas sofisticado del lado del servidor pueden entrar algunos frameworks de
presentacion y persistencia convietiendose
en:*

HTML-CSS-Javascript->Apache->PHP->engine de templates->Modelo->engine de
persistencia->BD

*si se quiere estar al dia, AJAX entra en el medio.*
*En Java algo tipico hoy en dia es una disposicion como:*
HTML-CSS-Javascript->TOMCAT->Java->JSP->Modelo->Hibernate->BD mas Ajax

*ni hablar de los sistemas que como capa de presentacion utilizan el
framework Tapestry que mete miedo
por su complejidad.*

*Por qué hay que gastar tanto tiempo en los detalles de las otras capas en
detrimiento del modelo en si?
(ahora en tono jocoso) si Smalltalk no es para cualquiera, las aplicaciones
web tampoco!!! :)
Y si el modelo es complejo? Si suponemos por un momento que el desarrollo no
es Web y solo hablamos
de la implementacion en algun lenguaje hibrido tenemos ya la friccion que
nombré en la intro de arriba.
Ahora imaginemos ese panorama (web) con algunos de los tandem de tecnologias
de arriba...

Esta critica no es nueva, la gente de Java esta realmente viendo que este
esquema es un callejon sin salida.
Sin embargo para SUN hay que seguirle destinando esfuerzo a lo Web, hay que
mantener la maquinita de
hacer billetes.*
*(ver http://weblogs.java.net/blog/evanx/archive/2006/05/swing_trounces.html)
*

*Segun Wikipedia una aplicacion web es:*

"En ingeniería de software una aplicación web es aquella que los usuarios
usan accediendo a un servidor web
a través de Internet o de una intranet. Las aplicaciones web son populares
debido a la practicidad del
navegador web como cliente ligero. La habilidad para actualizar y mantener
aplicaciones web sin distribuir
e instalar software en miles de potenciales clientes es otra razón de su
popularidad. Aplicaciones como
los webmails, wikis, weblogs, MMORPGs, tiendas en línea y la Wikipedia misma
son ejemplos bien conocidos de
aplicaciones web."

*En mi opinion (y en la de muchos) el problema radica en que el HTTP es un
protocolo sin estados, que fue
pensado para traspaso de datos que son hipertexto. El segundo problema
radica en utilizar el browser de internet
parcialmente como plataforma de desarrollo.*

*El Seaside permite wrappear todo esto. Ponerle una gran cascara encima y
manejarlo a un nivel mas alto. Pero no
soluciona la heterogeneidad del desarrollo. El HTML-CSS-Javascript esta alli
aunque no lo queramos ver
(piensen en Seaside con Ajax). No me malinterpreten no estoy atacando al
Seaside, de hecho me parece un verdadero
paso adelante. Yo veo al Seaside como un framework que viene a cubrir la
necesidad, tal cual las cosas como estan.

Cuando veo las complicaciones en el desarrollo en general, y veo cómo
Smalltalk las ha solucionado (me refiero
al lenguaje) siempre veo soluciones radicales, soluciones que atacan a la
medula del asunto.
Seaside en algun sentido ataca a la medula, pero en forma relativa, quizas
parcial.
Por ejemplo el tema de la persistencia de objetos (en Smalltalk) tiene
soluciones y soluciones...
Las del tipo mapeo Objeto-Relacional, solucionan de manera heterogenea el
asunto (GLORP, etc). Y eso tiene
sus consecuencias.
Soluciones que realmente atacan a la medula son Gemstone/S, Magma, GOODS. BD
orientadas puras a objeto.
La utilizacion de este tipo de herramientas no es intrusivo y permite un
desarrollo uniforme, consistente y transparente.*

*Cuando empece a explorar el VW, una de las cosas que queria ver  era que
pasaba cuando
uno terminaba de escribir un metodo y desplegaba el menu contextual y elegia
"Save". Lo que sucedia, era que se
disparaba un mecanismo donde la mensajeria terminaba en una sentencia
diciendo algo como:*
Smallatlk>>compile:aClass with:aMethod

*o algo por el estilo.
Algo similar sucedia con el mecanismo de "FileIn".
La VM de Smalltalk se la puede ver como un gran browser, no importa de qué,
de internet, de clases, de recursos,etc.
La VM es una gran metafora de un browser de internet. Conceptualmente un
interprete de un lenguaje consolidado, con
manejo de E/S a todo nivel, con capacidad (sobrada) de manejo de
interface,etc. Tiene lo que un browser de internet
y mucho mas!
*
*Hay algo que se podria aprovechar y no se esta aprovechando.
Como se implementaria? No lo se exactamente. Si, me puedo imaginar dos
Imagenes (asimetricas) corriendo en distintos puntos de una red. En una
imagen (tomando el rol de un especie de cliente) el usuario a traves de la
UI indica que quiere ejecutar una aplicacion que esta publicada en alguna
otra imagen (imagen que tendria el rol de servidor). El servidor le responde
un  paquete de codigo que es en si la aplicacion cliente. Al llegar al
cliente se habre ese paquete y se hace un especie de "fileIn". La aplicacion
se ejecuta e interactua remotamante con la misma imagen o quizas con otra
imagen en otro punto en la red.
En escencia es casi el mismo concepto de APPLET de Java, con la diferencia
que la aplicacion remota es smalltalk y
que en vez de correr en un browser de internet corre sobre otra imagen local
Smalltalk. En realidad la aplicacion no es
remota dado que viaja desde el servidor hasta el cliente. Y luego se
instancia completamente en la imagen local,
sin embargo la logica de la aplicacion y la persistencia esta en la imagen
servidor.
Hay algo parecido a este mecanismo en Squeak y se llama Monticello. Lo que
yo planteo es que la imagen cliente en
escencia seria una gran metafora de un Monticello, un browser de
aplicaciones, no de HTML.
*
*Desconozco si existe algun proyecto de la comunidad Smalltalk que este
trabajando sobre esto. Si lo hay
por favor avisenme que me gustaria leer algo.

Que hay un monton de complicaciones en la implementacion? Si, me lo imagino.
Pero tambien hay un sinfin de
consecuencias beneficiosas. El desarrollo es uniforme y homogeneo. El
desarrollador puede trabajar sobre una
imagen preparada para desarrollo en donde puede trabajar sobre el servidor y
el cliente y probarlo in situ
en un mismo entorno.
Usando las palabras de Edgar, cuando el usuario pida ejecutar una aplicacion
desde el servidor hasta el cliente
viaja un universo con todo un zoologico temporal, que es contenido en el
multiverso temporal que es el cliente.*

*Cuales son las argumentaciones de los desarrolladores al momento de
argumentar por qué una aplicacion debe ser
web, en el sentido de la definicion de Wikipedia que transcribi arriba?*

(1) -Si la aplicacion no es web (cliente pesado por ej: Outlook) tengo el
cliente desparramado en un sinfin
de lugares, cuando se necesite modificarlo hay que hacer el deploy de todo
eso.
(2) -Una solucion web pasa a traves de todos lo firewalls.
(3) -Si alguien se enferma, puede seguir trabajando desde su casa a traves
del browser.
(4) -Una solucion web permite una modificacion en caliente. Se tocan los
scripts y sigue andando.
(5) -El browser de internet esta disponible en todas las maquinas.

*De todos estos argumentos el unico que es una complicacion es el (5). Los
demas no son obstaculo para
lo que estoy planteando. Podria haber muchas maneras de plantear la capa de
comunicacion...
*
*Por ultimo desde el punto de vista de la estrategia de interaccion entre lo
que llame la imagen servidor
y la cliente, exactamente no responderia a un modelo Cliente/Servidor, sino
mas bien a una estrategia
Peer-2-Peer (pares interactuantes) asimetrico. Cada imagen tiene
responsabilidades distintas.*

*Para ir terminando, quisiera repetir que esto no es un ataque a Seaside.
Desde mi punto de vista los entornos
Smalltalk (desde hace al menos 30 años) han estado en la punta de la
tecnologia y tienen todavia un potencial
enorme inexplorado. No es tiempo de pasar a otra etapa y salir
definitivamente del yugo procedural?*


*Saludos

Elvio
*
*

Edgar :) Avi no me hizo nada. Creo que vos te das cuenta hacia donde apunta
mi planteo. Vos sabes que en este grupo yo encarno el rol no-academico. En
consecuencia yo aspiro a poder trabajar en Smalltalk y ganarme la vida con
Smalltalk pero falta tanto...
Y lo que plasmo Avi, en algun punto es un paso mas hacia adelante. Pero,
como poder mejorar si no es a través del ejercicio critico y la evaluacion
de lo previamente construido?

Mi preocupacion tambien es el rumbo de Smalltalk y a veces me parece que se
desatiende un poco la brujula. Como lo se? mirando codigo Smalltalk viejo y
viendo sus estrategias de resolucion. Los ladrillos fundamentales para
construir tu idea y por otro lado mi planteo, ya existen (hace tiempo que
existen) nosotros no somos iluminados y a algun otro tambien se le habra
ocurrido. Por eso es que me deja un poco perplejo el rumbo (que quizas) tome
el Seaside.

Se entiende lo que quiero plantear? El Seaside en algun punto se compromete
a perpetuar lo heterogeneo y en un futuro habrá que hacerse cargo de esto.

Elvio

Edgar :) Avi no me hizo nada. Creo que vos te das cuenta hacia donde apunta
mi planteo. Vos sabes que en este grupo yo encarno el rol no-academico. En
consecuencia yo aspiro a poder trabajar en Smalltalk y ganarme la vida con
Smalltalk pero falta tanto...
Y lo que plasmo Avi, en algun punto es un paso mas hacia adelante. Pero,
como poder mejorar si no es a través del ejercicio critico y la evaluacion
de lo previamente construido?
Mi preocupacion tambien es el rumbo de Smalltalk y a veces me parece que se
desatiende un poco la brujula. Como lo se? mirando codigo Smalltalk viejo y
viendo sus estrategias de resolucion. Los ladrillos fundamentales para
construir tu idea y por otro lado mi planteo, ya existen (hace tiempo que
existen) nosotros no somos iluminados y a algun otro tambien se le habra
ocurrido. Por eso es que me deja un poco perplejo el rumbo (que quizas) tome
el Seaside.
Se entiende lo que quiero plantear? El Seaside en algun punto se compromete
a perpetuar lo heterogeneo y en un futuro habrá que hacerse cargo de esto.
Elvio
__._,_.
Claro que te entiendo.
Habrán decidido que si no pueden vencer , hay que unirseles =)
Pero al fin de cuentas, la maravilla de Squeak, a diferencia de otros
Smalltalk ³mas serios², es que es tuyo, mío, de Alan Kay, de los chicos que
recién empiezan, etc.
Yo voy a seguir jorobando mucho tiempo, como decía el querido (y necesitado)
Tato Bores.
En cuanto arme un equipo confiable de gente aquí en Rosario, podremos
intentar algún sistema comercial.
No creas que no me gusta la plata...

Edgar

"No creas que no me gusta la plata..."

jajaja!!
Si entiendo, a mi me gusta la plata sobre todo para sobrevivir y me imagino
que algo por el estilo te pasa a vos.
Mas alla de eso Edgar realmente estoy podrido de tener que trabajar con C#,
Java, PHP y demas cosas retrogradas. Lamentablemente es con lo que me toca
bailar, lo que no quiere decir que sea asi por siempre. Especialmente veo
que Smalltalk es un territorio que pareciera recien colonizado, hay tanto
por hacer! hay tanto por discutir y sobre todo si mi intencion es usarlo en
mi vida profesional es necesario contribuir a la comunidad para arrimar un
granito de arena.

En esta altura del año estoy con poco tiempo, asi que lo que me queda lo
dedico a explorar el Squeak y el Dolphin y a leer todo lo que pueda.
Probablemente a partir de mediados de Noviembre (y es mi deseo) pueda
contribuir a los desarrollos que se hacen. Las dos areas que mas me
interesan estan en lo que venimos hablando y la parte de Morphic.

Al margen de esto, cada tanto me vas a ver saltar con algun planteo alguna
critica, y como te habras dado cuenta la intencion es la de sumar, y la de
reflexionar.

Saludos

Elvio

Hola Elvio,

> Mas alla de eso Edgar realmente estoy podrido de tener que trabajar
> con C#, Java, PHP y demas cosas retrogradas. Lamentablemente es con lo
> que me toca bailar, lo que no quiere decir que sea asi por siempre.

Un "truquito", que me permitió usar Smalltalk en esos contextos, es
hacer generadores de código.  Mucho del código de aplicaciones
comerciales (y sobre todo en esos entornos) es repetitivo, aburrido de
escribir y (por la repetición) muy difícil de mantener.

Hacer (en ST) un pequeño generador de código es una tarea bastante
entretenida y, a mediano plazo, económicamente sostenible.

La idea es bien simple: Hacer un pequeño modelo de objetos donde se
declare (lo que se pueda) los objetos de tu negocio, sus atributos, sus
relaciones, etc.  Si querés que la herramienta pueda ser usada por
programadores que no sepan (o no quieran usar) Smalltalk, podés hacer un
pequeño parser que levante el modelo desde un archivo XML.

Algo así:

        <object name="Direccion">
           <attribute name="calle" type="string">
        </object>
       
        <object name="Cliente" superclass="Foo">
           <attribute name="nombre" type="string">
           <attribute name="apellido" type="string">
           <attribute name="direccion" type="Direccion">
        </object>
       
Lo interesante de este approach es que podés ir evolucionando el
generador conforme lo necesites.

Otra opción es que te crees un "lenguaje del dominio".  Una especie de
lenguaje declarativo donde puedas volcar más información que sólo
"Entidades y relaciones".

Te recomiendo que le pegues un vistazo al libro "Pragmatic Programmers".

Saludos,

-- Diego

--
==========================================
 Diego Gomez Deck
------------------------------------------
 http://www.consultar.com/DiegoGomezDeck/
 http://diegogomezdeck.blogspot.com/
 http://smalltalk.consultar.com/
==========================================




correo electrónico a: [hidden email]


correo electrónico a: [hidden email]

 
Enlaces de Yahoo! Grupos

<*> Para visitar el sitio web del grupo, andá a:
    http://ar.groups.yahoo.com/group/squeakRos/

<*> Para cancelar tu suscripción a este grupo, enviá un mensaje a:
    [hidden email]

<*> El uso de Yahoo! Grupos está sujeto a las:
    http://ar.docs.yahoo.com/info/utos.html
 

Gracias a Elvio y a Diego.
Vamos mejorando con estos mails, a ver si se prenden los demás, que esto es
de todos.

Edgar

Interesante Diego.

Busque el libro y hay un monton con ese nombre ahora me estoy bajando dos.
Encontre otro en book.google.com "The *Pragmatic*
Programmer<http://books.google.com.ar/books?vid=ISBN020161622X&id=4QhMjgEZhj4C&pg=PA1&lpg=PA1&ots=Eo3ZERQExM&dq=Pragmatic+Programmers+book&sig=waLP-Ktjfyt06jhtbn8NU_GlhZg>"
by Andrew Hunt, David Thomas.
Será este el que vos decis?

Elvio

El día 22/08/06, Diego Gomez Deck <[hidden email]> escribió:

Hola Elvio:

Me resultó muy interesante tu mail y me tomé el tiempo para leerlo y re-leerlo.

> Cuando se tiene un dominio del problema que es realmente complejo, el ejercicio de
> plasmar, modelar y diseñar
> reflejará esa complejidad. En una resolucion hecha en Smalltalk el protagonista es la
> complejidad del modelo en si,
> para reflejar la complejidad del problema. El protagonista es el modelo, la resolucion.

> En otros lenguajes, el diseño deja de ser protagonista para ir a un segundo plano. El
> protagonista es el lenguaje y >sus complicaciones tecnicas. Esto, en mi opinion, va
> directamente en detrimento de la conclusion y la factibilidad >del desarrollo.


Estoy absolutamente de acuerdo con este comentario, y he podido
comprobar fehacientemente que es así. Cuando me ha tocado trabajar con
lenguajes (espero no se repita) en las listas el gurú era el que sabía
que . o que ; había que poner o con qué flag había que compilar. El
sistema? Bien gracias.

> Ahora abandonando la intro sobre la homegeneidad y su potencia, el planteo en si, tiene > que ver con la
> heterogeniedad en las aplicaciones Web. Me declaro un ferviente militante de la abolicion > de las aplicaciones web
> como se las desarrolla hoy.
> Despues de tanto trabajar sobre ese tipo de aplicaciones me pregunto por qué hay que
> lidiar con tanta complejidad.

> Esta critica no es nueva, la gente de Java esta realmente viendo que este esquema es un > callejon sin salida.
> Sin embargo para SUN hay que seguirle destinando esfuerzo a lo Web, hay que >mantener la maquinita de
> hacer billetes.

Entiendo el punto que planteás sobre la complejidad de las diferentes
cosas a usar en una aplicación web, y también coincido en el tema de
la maquinita de hacer billetes, aunque cada uno tiene la suya, Sun por
su lado, pero MS por el suyo, por eso es que valoro tanto a Smalltalk,
porque está fuera de esos círculos afortunadamente.

Respecto de abolir las aplicaciones web, creo que las mismas hoy se
imponen por varias cuestiones pero me parece que la más importante es
por la visibilidad, me pregunto como habría Google llegado a ser lo
que es sin la web?

Obteniendo esa visibilidad global, creo que cualquier tecnología
podría usarse y de hecho que si se puede tener algo que evite el
circulo de complejidad que vos bien describiste
(HTML-CSS-Javascript->Apache->PHP->engine de templates->Modelo->engine
de persistencia->BD) sería excelente.

Vos mencionaste más adelante algunos factores que intervienen para
decidir si una aplicación es web o no (con las tecnologías que hoy
disponemos):

> (1) -Si la aplicacion no es web (cliente pesado por ej: Outlook) tengo el cliente desparramado en un sinfin
> de lugares, cuando se necesite modificarlo hay que hacer el deploy de todo eso.
> (2) -Una solucion web pasa a traves de todos lo firewalls.
> (3) -Si alguien se enferma, puede seguir trabajando desde su casa a traves del browser.
> (4) -Una solucion web permite una modificacion en caliente. Se tocan los scripts y sigue andando.
> (5) -El browser de internet esta disponible en todas las maquinas.

y creo que no son temas menores, sino que tienen su peso y han logrado
que hoy mucha gente se plantee el uso de aplicaciones web, en
particular los puntos 1 y 3 en empresas o corporaciones con miles de
puestos de trabajo, es algo que tiene un valor muy significativo. El
punto 3, no hablemos sólo de cuando una persona necesita trabajar de
su casa, hablemos de una corporación que abre sucursales, no necesita
invertir fortunas en enlaces dedicados, sino que contrata un enlace
ADSL y trabaja por Internet, en fin....hay muchos factores a favor de
las aplicaciones web (como también los habrá en contra).

Sin embargo me parece bárbaro tu enfoque de buscar algo más. A favor
del Seaside, te puedo decir, luego de usarlo un tiempo y haber hecho
varias aplicaciones, que te achica las complejidades del desarrollo
web tradicional (php y demás cosas) en un gran gran porcentaje,
haciendo mucho más fácil el debugging, la reparación en vivo y unas
cuántas cosas más y creo (como vos bien decís) que es un gran paso
adelante.

Sin embargo no me parece que se apunte a reemplazar nada ni se
encamina a soluciones como las que vos estás buscando/planteando, sino
que más bien se "asocia" a lo que hoy es el estado del arte de la web.

Como experiencia personal, puedo comentar que hace unos 5 años me
propuse dejar todas las herramientas tradicionales en mi
emprendimiento personal ArSol Software y si bien me ha llevado mucho
esfuerzo, faltas de facturación (que aún hoy sufro) estoy finalmente
trabajando sólo en Smalltalk con 3 productos (por ahora) orientados a
mercados distintos (Promoter, ClavesPC y A1). Creo, como vos, que hay
mucho por hacer con/en Smalltalk, por ahora mi granito de arena es
usarlo, hacer pequeñas mejoras en los frameworks que uso, y si puedo
contribuir con algo a la comunidad, con gusto lo haré.

Como dice una publicidad, respecto de otras cosas: "Trabajar en
Smalltalk......no tiene precio".

Saludos.

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



correo electrónico a: [hidden email]


correo electrónico a: [hidden email]

 
Enlaces de Yahoo! Grupos

<*> Para visitar el sitio web del grupo, andá a:
    http://ar.groups.yahoo.com/group/squeakRos/

<*> Para cancelar tu suscripción a este grupo, enviá un mensaje a:
    [hidden email]

<*> El uso de Yahoo! Grupos está sujeto a las:
    http://ar.docs.yahoo.com/info/utos.html
 

Hola Germán,

las app como se las desarrolla hoy en dia, van seguir existiendo por mucho
tiempo. En realidad a lo que yo apuntaba es que el problema radica en
utilizar el browser de internet parcialmente como plataforma de desarrollo.
Que quiere decir esto? Que el flujo de datos que escupe el Seaside o
cualquier otra tecnologia se va a ejecutar en el browser de internet. Solo
ese hecho te quiebra la homogeniedad y en la mayoria de los desarrollos, eso
se vuelve invasivo. En algun punto aunque utilices Seaside (pelado sin Ajax)
te vas a encontrar laburando e inspeccionando HTML-CSS-Javascript. No hay
manera de evitarlo porque desde su genesis el Seaside no plantea solucionar
eso.
Avi y la comunidad que ayudo a desarrollar el Seaside debe haber invertido
mucho pero mucho esfuerzo para construir una capa de alto nivel para
manipular y generar streams de datos HTML y relacionarlos con la logica del
dominio del problema.
No se si ya a esta altura estoy fuera de foco, pero veo las cosas de otra
manera. Rompamos la logica que nos impone de alguna manera el mercado. Les
propongo que, aunque sea por un ratito, abandonen la perspectiva que tienen
del Seaside y el desarrollo de aplicaciones web como esta hoy en dia...
Si se llegara a implementar lo que esta en discucion, Ajax, Flash, Applet y
un monton de otras tecnologias empesarian a dejar de tener sentido. Con al
potencia de Squeak realmente se pueden hacer clientes mas potentes, mas
sofisticados, con representacion de la informacion infinitamente mas
amigable y mucho mas compleja. Y todo esto de manera mas transparente y
consistente. Imaginen el potencial de esto y el espaldarazo que podria
llegar a tener la comunidad de Smalltalkers.

Los puntos que enumere, "las argumentaciones de los desarrolladores para
construir una app web" (por favor no te sientas atacado German ni nigun otro
que lea el mansaje) son las argumentaciones que metio en el mercado SUN y MS
para fundamentar su maquinita de hacer billetes. La otra vez me vi un
webcast de la gente de SUN y era, una por una, sus argumentaciones. Me senti
timado :)

"...hablemos de una corporación que abre sucursales, no necesita
invertir fortunas en enlaces dedicados, sino que contrata un enlace
ADSL y trabaja por Internet."

Lo que yo planteo seria una app web pero no en el sentido que la conocemos.
El que serviria la aplicacion que viaja hasta el cliente seria un servidor
web (smalltalk). La  diferencia es que se ejecutaria en otra imagen
smalltalk.
En una seguna fase de esta ejecucion la app cliente interactua, quizas con
otra imagen en otro punto de la red, que muy probablemente como plataforma
de comunicacion sea tambien HTTP. No seria necesario ningun enlace dedicado.

Elvio

Continuando la ultima respuesta, el tema de la capa de comunicacion ya es un
asunto mas tecnico de implementacion. Si interesa, podriamos empezar a
pensar una hipotetica capa de comunicacion: Que debria brindar? sobre que
protocolo? objetos dsitribuidos? como implementarlo? etc,etc. Hay muchas
cosas para plantearse y elaborar.

De todas maneras a mi me gustaria destacar que el resultado de esta
hipotetica construccion deberia ser algo transparente y homogeneo. El
desarrollador que utilizara esto deberia poder usarlo como un mecanismo mas
de todos los que existen en Smalltalk. No deberia ser intrusivo en ningun
punto. Deberia ser usable y el desarrollador no deberia tener que
convertirse en un usuario experto para hacer un "hello world".
A mi me parece que la compelijidad deberia estar del lado del framework que
provee este mecanismo, no del lado de "uso" del framework.

Hoy en dia se estan viendo muchos frameworks producidos del lado de Java de
una complejidad extrema en su uso. Intuyo que es por la misma precariedad
del lenguaje en que se produce. Nuevamente miremos hacia atras y veamos los
lineamientos generales que se han planteado cuando construyeron los primeros
intepretes/compiladores Smalltalk. La complejidad esta en el interprete no,
en el lenguaje. El desarrollador deberia tener una herramienta expresiva y
homogenea y uniforme para poder dedicarle tiempo a lo que verdaderamente
importa: observar y entender la complejidad del mundo real y poder plasmarlo
en el desarrollo.

Elvio

Hola:

2006/8/23, Elvio Fernandez <[hidden email]>:
>
>
>    Hola Germán,
>
> las app como se las desarrolla hoy en dia, van seguir existiendo por mucho tiempo. En realidad a lo que yo apuntaba es que el problema radica en utilizar el browser de internet parcialmente como plataforma de desarrollo. Que quiere decir esto? Que el flujo de datos que escupe el Seaside o cualquier otra tecnologia se va a ejecutar en el browser de internet. Solo ese hecho te quiebra la homogeniedad y en la mayoria de los desarrollos, eso se vuelve invasivo. En algun punto aunque utilices Seaside (pelado sin Ajax) te vas a encontrar laburando e inspeccionando HTML-CSS-Javascript. No hay manera de evitarlo porque desde su genesis el Seaside no plantea solucionar eso.

Si, interpreto lo que vos decís, pero también lo que luego vos
afirmás, este tipo de aplicaciones van a seguir existiendo por mucho
tiempo y ahi van a estar los negocios (o digamos el trabajo para
muchos).

Entre tener que hacer ese trabajo con las porquerias usuales o hacerlo
con Smalltalk, ni dudo que elegir.

Ello no quita que se puedan ir pensando/desarrollando soluciones como
las que vos proponés.

> Los puntos que enumere, "las argumentaciones de los desarrolladores para construir una app web" (por favor no te sientas atacado German ni nigun otro que lea el mansaje) son las argumentaciones que metio en el mercado SUN y MS para fundamentar su maquinita de hacer billetes. La otra vez me vi un webcast de la gente de SUN y era, una por una, sus argumentaciones. Me senti timado :)
>
> "...hablemos de una corporación que abre sucursales, no necesita
>
>   invertir fortunas en enlaces dedicados, sino que contrata un enlace
>
>  ADSL y trabaja por Internet."
>

No me siento atacado,para nada. Y por más que sean argumentaciones de
esas empresas, hoy son bastante difíciles de refutar. Uno también
tiene que ver la realidad.


> Lo que yo planteo seria una app web pero no en el sentido que la conocemos. El que serviria la aplicacion que viaja hasta el cliente seria un servidor web (smalltalk). La  diferencia es que se ejecutaria en otra imagen smalltalk.
> En una seguna fase de esta ejecucion la app cliente interactua, quizas con otra imagen en otro punto de la red, que muy probablemente como plataforma de comunicacion sea tambien HTTP. No seria necesario ningun enlace dedicado.


Bárbaro! Yo no estoy en contra, todo lo contrario, pero hoy no existe.
Con esto te quiero decir que no hay un camino alternativo al punto
anterior. O, si lo hay, yo no lo veo :(

Saludos.



correo electrónico a: [hidden email]


correo electrónico a: [hidden email]

 
Enlaces de Yahoo! Grupos

<*> Para visitar el sitio web del grupo, andá a:
    http://ar.groups.yahoo.com/group/squeakRos/

<*> Para cancelar tu suscripción a este grupo, enviá un mensaje a:
    [hidden email]

<*> El uso de Yahoo! Grupos está sujeto a las:
    http://ar.docs.yahoo.com/info/utos.html
 

Disculpas German si mi tono es un poco arrebatado. Quizas estoy un poco
cabezoneado con el asunto... Hace tiempo que lo vengo pensando y quizas
cuando empece a jugar con el Seaside termine de comprender que habria que
apuntar los cañones en otro rumbo.

De todas maneras esta buenisimo tener la oportunidad de someter la idea al
juicio critico de los demas. No tiene precio.

Bárbaro! Yo no estoy en contra, todo lo contrario, pero hoy no existe.
Con esto te quiero decir que no hay un camino alternativo al punto
anterior. O, si lo hay, yo no lo veo :(

Es temprano y estoy un poco dormido no se si te interpreto.
Me estas preguntando como se haria la capa de comunicacion sobre HTTP? Cual
seria la alternativa a usar un browser de internet?

Lamentablemente lo mas viable seria usar HTTP. Cosa que no seria lo mas
adecuado para esto. No sé exactamente como se llevaria a cabo, pero habria
que pensar una manera de realizar pasaje de mensajes arriba de los request y
response de HTTP. Ya existe algo de eso (XML-RPC), un poco primitivo y
orientado a lo procedural, pero se podria darle una vuelta de rosca mas. De
todas maneras es una opcion tirada al vuelo. Habria que pensar.

Cual es la opcion a usar un browser de internet? usar una imagen minima de
Squeak como las que desarrolla Edgar.

Discupas no se si te interprete bien.

Elvio

Hola Elvio:

2006/8/24, Elvio Fernandez <[hidden email]>:
>
>
> Es temprano y estoy un poco dormido no se si te interpreto.
> Me estas preguntando como se haria la capa de comunicacion sobre HTTP? Cual seria la alternativa a usar un browser de internet?
>

Lo que quise decir es mucho más simple, es que hoy en día eso que vos
querés desarrollar (que me parece muy loable) u otras alterantivas,
aún no existen. Entonces no quedan muchas opciones más que usar las
que tenemos.

Saludos.,



correo electrónico a: [hidden email]


correo electrónico a: [hidden email]

 
Enlaces de Yahoo! Grupos

<*> Para visitar el sitio web del grupo, andá a:
    http://ar.groups.yahoo.com/group/squeakRos/

<*> Para cancelar tu suscripción a este grupo, enviá un mensaje a:
    [hidden email]

<*> El uso de Yahoo! Grupos está sujeto a las:
    http://ar.docs.yahoo.com/info/utos.html
 

Cual es la opcion a usar un browser de internet? usar una imagen minima de
Squeak como las que desarrolla Edgar.

Vos estas hablando de un server que atienda n clientes y que se use HTTP
para pasar la info entre las imagenes ?
O es otra cosa ?

Edgar

Edgar en realidad no lo se. Es una posibilidad. Pero realmente no se si sea
la mejor. El asunto es complejo y es para pensarlo. Seguramente emprender un
desarrollo de estos requiera de mucha gente. Implicaria capa de comunicacion
(sea lo que sea). Desarrollo de una imagen minima. La capa que permita usar
el mecanismo de comunicacion. Y algo asi como un browser de aplicaciones,
algo parecido al Monticello.

La idea en si, es la que arranco toda esta rama de la discucion. Ahi esta
explicado el mecanismo deseado. Exactamente cómo se implementaria no lo
tengo claro todavia. Lo que si te puedo decir es que apunta a evitar usar el
browser como plataforma de desarrollo y en vez de eso usar una imagen.

Saludos