Hola Elvio,
>>" Es evidencia que debemos explorar, pues conocemos muy bien
>>(en carne propia) el costo que tiene producir software pensando...
>>y que est emodelo no alcanzaría para cubrir las exigencias que
>>impondrá sobre nosotros el desarrollo de la nanotecnología
>>(el poder interactuar y dirigir el devenir de millones de máquinas
>>por centimetro cubico)
>No es la tecnología de objetos la que tiene que hacer frente
>a ese desafío?"
>>y que est emodelo no alcanzaría para cubrir las exigencias que
>>impondrá sobre nosotros el desarrollo de la nanotecnología
>>(el poder interactuar y dirigir el devenir de millones de máquinas
>>por centimetro cubico)
>No es la tecnología de objetos la que tiene que hacer frente
>a ese desafío?"
Creo que tendremos (nosotros) que hacer frente a ese desafío,
seguramente antes de que se logren desarrollar alternativas
superadoras al trabajar sumando objetos a objetos...
De ser así será otra crisis de software la que seguramente
veamos desarrollarse en ese momento.
>Hace poco lei algo del concepto de atractor, nada muy profundo,
> solo para interiorizarme algo en el tema. Recuerdo que la charla
> de Andres Valloud (asi se escribia?) en la UNLP el nombro este
> tema.
Es un elemento muy usado, casi siempre con intensionalidad,
para imponer una politica/plan de convergencia.
Por ejemplo, en contextos de desarrollo de GUIs usando
encapsulamiento (como principal instrumento) es mas que seguro
que en todas las oportunidades donde participe al menos
una persona con experiencia previa, todo el equipo deriva hacia
un consenso unico respecto de cómo modelar los elementos
de la interfáz. Al ocurrir esto en reiteradas oportunidades, es
mas "económico" pensar en que "hay algo" que punga por que
los diseños converjan a un "diseño único"...
Esta economia (a menudo relacionada con la convergencia de los
modelos) produce el deleite de quienes les gusta
hacer modelos abstractos y pensar que nadie puede escapar
a repetir lo mismo; y de quienes gustar de coleccionar (modelos
/ patrones u otras cosas).
Más allá de lo castrador y cruel que resulte el método, a quienes
les gusta producir rapido y/o piensan en que cuanto mas barato
es mejor, estos efectos les encantan :-)
al punto de forzar a que no pueda generarse algo alternativo.
>La formacion en la facultad promueve a la idea de que el
>La formacion en la facultad promueve a la idea de que el
> desarrollador decide los "como", los "cuando" en el
> tratamiento del "computo" (no se como decirlo de manera
> general) en el momento que se esta pensando la
> construccion del soft.
Otra forma de decirlo, es hablar de "escribir programas",
que aunque sean dibujados con cajas, siempre estarán
evaluados respecto de lo "que hacen" (y no, lo que son),
y en ese punto es el que se relacionan con el computo,
la acción, el método (objeto "comportamiento").
> Se piensa de antemano los flujos de informacion, las interacciones,
> las relaciones de las partes, como se van a tratar la cadena
> de sucesos o acontecimientos que tomaran lugar en la
> vida (el accionar, el funcionar) del sistema, etc.
Se considera a la información como si fuera un objeto.
>¿Como van a hacer para acercarse cada vez mas a la gran
> cantidad de variantes que tiene la realidad con la tesitura
> que hasta ahora se viene manejando?
>No digo que en un futuro esto se deba hacer sobre TO
>No digo que en un futuro esto se deba hacer sobre TO
> especificamente, pero lo que si me pareciera que seguir
> con la vieja tesitura propone un callejon sin salida.
si si, en todas las direcciones en desarrollo ocurre lo mismo.
>¿Seria posible aplicar atractores?
>No se si es el mejor ejemplo pero bue...
>No se si es el mejor ejemplo pero bue...
jajaja! es una formula (formula como en "formula politica",
sirve para asegurar que casi siempre pasa lo mismo,
no para generar un cambio)
>¿En el ejemplo tuyo del cardumen que mostraste en la reunion
> no estabas definiendo (encontraste?) implicitamente un atractor?
> Digo, aunque no haya sido tu intencion.
No. Si lo enconcontraste, fuiste vos;
yo no necesite encontrarlo. ;-)
>En relacion al tema de sistemas complejos, y con mi nocion
> baga de atractores, no parece algo trivial encontrarlos,
> y peor aun tocarlos.
Un atractor es una función, no esta en el espacio del sistema
sino en el espacio de ideas de quien reflexiona sobre un sistema.
Si lo podes ver, lo podes "programar"... en cualquier lenguaje.
( pienso luego escribo )
hasta pronto, :-)
Ale.
----- Original Message -----From: Elvio FernandezTo: smalltalking@...Sent: Tuesday, October 02, 2007 7:32 PMSubject: [objetos] Pienso luego existoHola Ale,
En el hilo "Smalltalk con lenguaje?" en unas de tus respuestas a Carlos decias
" Es evidencia que debemos explorar, pues conocemos muy bien
(en carne propia) el costo que tiene producir software pensando...
y que est emodelo no alcanzaría para cubrir las exigencias que
impondrá sobre nosotros el desarrollo de la nanotecnología
(el poder interactuar y dirigir el devenir de millones de máquinas
por centimetro cubico)
No es la tecnología de objetos la que tiene que hacer frente
a ese desafío?"
Hace poco lei algo del concepto de atractor, nada muy profundo, solo para interiorizarme algo en el tema. Recuerdo que la charla de Andres Valloud (asi se escribia?) en la UNLP el nombro este tema.
La formacion en la facultad promueve a la idea de que el desarrollador decide los "como", los "cuando" en el tratamiento del "computo" (no se como decirlo de manera general) en el momento que se esta pensando la construccion del soft. Se piensa de antemano los flujos de informacion, las interacciones, las relaciones de las partes, como se van a tratar la cadena de sucesos o acontecimientos que tomaran lugar en la vida (el accionar, el funcionar) del sistema, etc.
Hace poco estaba viendo unos screencast donde mostraban unas mejoras en determinados engine 3D. Se veia la tipica escena de un personal shooter lanzando un objeto contra un especie de pared de madera. Se hacian varios lanzamientos desde angulos levemente distintos y la pared de madera nunca se rompia igual (al menos asi lo parecia a grosso modo).
A medida que pasa el tiempo vemos que los engine 3d intentan cada vez mas emular los destalles mas infimos de la realidad.
¿Como van a hacer para acercarse cada vez mas a la gran cantidad de variantes que tiene la realidad con la tesitura que hasta ahora se viene manejando?
No digo que en un futuro esto se deba hacer sobre TO especificamente, pero lo que si me pareciera que seguir con la vieja tesitura propone un callejon sin salida.¿Seria posible aplicar atractores?
No se si es el mejor ejemplo pero bue...
¿En el ejemplo tuyo del cardumen que mostraste en la reunion no estabas definiendo (encontraste?) implicitamente un atractor? Digo, aunque no haya sido tu intencion.
En relacion al tema de sistemas complejos, y con mi nocion baga de atractores, no parece algo trivial encontrarlos, y peor aun tocarlos.
Saludos
Elvio
Sin conexión 
Enviar correo