Algunos puntos, tal vez alejado del tema de este thread, pero no tanto de Smalltalk, en este sabado de frio aqui en Buenos Aires.
Creo que algo ya habia planteado en esta lista, en un breve thread con @HernanWilkinson: - Los objetos envian mensajes. Deberia habiar la posibilidad de enviar mensaje "fire and forget", sin esperar retorno - Los objetos pueden ser como celulas: no cobran vida cuando llega un mensaje, siempre "estan haciendo algo". Podemos llamarlos agentes? actores? No tienen que ser todos los objetos asi. - Los objetos "estan" en cualquier lugar y se levantan en cualquier lugar. Que esten en esta computadora o en aquella, seria un accidente - No es facil, y no siempre es deseable, tener esa "location transparency", un punto a discutir. Habria que conseguir que los objetos que mas conversen entre si, se vayan "amuchando" en una maquina/s cercanas. - Deberia haber algo como en los 70/80 era el Sistema Pick (de Richard Pick): todo estaba en algun sector: estado de registros, memoria de trabajo, datos de un archivo. Y los sectores vivian en memoria de acceso rapido (una RAM p.ej.), o en disco, indistintamente. Expandir eso a memorias y cpus de varias maquinas, trabajando en conjunto. - Por ejemplo, en los 90 lei un articulo en la Dr. Dobb's que proponia que todo elemento tuviera un GUID: objeto, archivo, metodo, etc... Habia que resolver como recuperar un elemento por el GUID, y como almacenarlo (tal vez en varias maquinas/discos/memorias). - Sino se puede eso, habria que investigar NoSql y soluciones parecidas. Tener todo en memoria (en varias memorias/maquinas) ir grabando con consistencia eventual, solo por si se corta la luz :-) - Vi con interes que aca se trato el tema SSD (Solid State Disks). Un camino a usar. - En HPC (High Performance Computing) vi memoria de acceso rapido compartida entre varias maquinas/cpus. Lo vi tambien en procesamiento en paralelo sobre GPU, pero me parece eso mas orientado a algunos algoritmos en particular. - De alguna forma, todo esto propone: la disolucion de "memoria para una maquina", "cpu en una maquina", etc. Juntando todo eso, no hay temas a resolver como "salvar la imagen a disco". The network is the application. The living image is everywhere ;-) Jeje, no digo que sea facil ;-) Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 2011/6/25 Javier Burroni <[email protected]> > > > > Bueno, todos estos problemas no existirian si la imagen no se > > estuviera ejecutando mientras se carga el codigo. O si tuvieramos > > divisiones al estilo Newspeak. Pero... aqui estamos... la esencia del > > problema es que un ente no se puede observar a si mismo excepto > > dividiendose en la parte que observa y la parte observada. Meter todo > > en la imagen hace dificil (y en algunos casos sospecho que imposible) > > que el sistema reflexione acerca de si mismo, simplemente porque no se > > puede observar a si mismo con claridad. > Que buenas las problematicas narcisisticas de la imagen (ups, esto se > resignifico). Digamos que la VM se queda fascinada mirando su propia > imagen. > > Muy bueno el thread, y la tesis! > Ahà estaré con los trapos de SqueakNOS > > jb > -- > " To be is to do " ( Socrates ) > " To be or not to be " ( Shakespeare ) > " To do is to be " ( Sartre ) > " Do be do be do " ( Sinatra ) > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
