Ok, no soy Alan Kay ni Craig Latta si a eso te refieres, (a todo esto gracias por el link de Spoon, es increíble), pero por otro lado yo también pensaba que todo era increíblemente complicado porque programé en C++ por 7 años.
Luego conocí Smalltalk y al hacer unas pruebas para demostrarme a mí mismo que no funcionaba (o que funcionaba igual de mal que C++), y pensaba yo, con arduo esfuerzo implementar lo mismo que tenía en C++, entonces me di cuenta para mi sorpresa que: 1. Todo lo que sabía de C++ era innecesario. En Smalltalk todo es simple y todo funciona. En particular alguien mencionó que serializar los bloques no es simple, puede ser, pero ¿porqué? ¿Porque hace referencias a variables fuera del scope del bloque? Potencialmente sí, pero en la práctica los bloques en Smalltalk (y las expresiones lambda en Lisp) son "closures" (cerraduras), de manera que no debiera ser tan difícil: http://live.exept.de/doc/online/english/programming/stForLispers.html 2. En C++ debes tener cuidado cuando serializas un objeto recursivo, ya que puedes caer en un loop infinito. En Smalltalk eso estaba resuelto. http://www.cincomsmalltalk.com/blog/blogView?entry=3293342418 No sé si está resuelto actualmente en Pharo, pero bueno, no creo que sea más que colocar "markers" cada cierto rato o de cuando en vez... ;-) Podría seguir pero en realidad ahora pienso al revés. Hay un montón de cosas que están resueltas en Java, como por ejemplo los EJBs como servicios remotos de alto desempeño, los proxies que se comportan como EJBs, los builds automatizados que corren todas las pruebas automatizadas de un proyecto cuando se hace check-in en Mercurial, la generación de SQL dinámico a partir de una representación de la base de datos, ejecutar sobre Google App Engine, tener componentes Java que se comportan como Swing pero sobre HTML, etc. y que en Smalltalk al parecer no lo están o están en una fase de creación o son productos comerciales (y sabemos que Smalltalk no se caracteriza por lo barato, de hecho fue gracias a su precio que Sun decidió crear Java). Tampoco es que en Java todo sea color de rosas. Aún los constructores no hacen dynamic dispatch, ni los métodos estáticos, ni los métodos privados, etc. Ni hablar de tener bloques o lambda expressions. Las propuestas de closures son aún más feas que las anotaciones (@ejb). ¿Cómo es posible que en Java aún no existan operadores definidos por el usuario? Yo encontraba que leer XML era feo, pero resulta que ahora con los templates (generics le dicen en Java), con las anotaciones y con los tag libraries de Struts y con JSF, leer una aplicación Java es casi como leer Chino pero con comentarios en Sumerio. Indescifrable. Y encuentra un defecto en alguna biblioteca y te quiero ver debuggeando por semanas. No es que en C++ no pasara lo mismo, sólo que pasaba con tu propio código 8-( Ahí inventé las pruebas unitarias semi automáticas en 1993, pero decidí no contarle a nadie. Mala decisión. (Siempre me he topado con que las pruebas automatizadas las venden como pruebas de métodos en vez de probar el protocolo de la clase, y más encima el "protocolo" ahora se refiere al "method category")... Creo que tener EJBs en Pharo sería bueno. Hacer un sistema distribuido, con objetos distribuidos y transaccionales me parece bonito sólo en el papel, no necesito que automáticamente un objeto de mi imagen viaje a tu imagen y haga algo, todo lo contrario ¿para qué? ¿No debería haber un servicio en tu imagen esperando mensajes de la mía, cierto tipo de mensajes, con cierto protocolo? Me parece mucho más interesante resolver algo pequeño y bien, el resto, si alguien lo necesita lo puede construir de manera trivial, pero IMHO partir por "cada objeto es un thread" es un suicidio a nivel del uso de recursos. Ok, pero tampoco quiero hacerlo sólo porque la verdad es que ya casi y todo lo he hecho y salió bien, ¿hay alguna motivación para hacer todo de nuevo? Naahhh. (ok, no he implementado un intérprete de bytecode, pero no veo la dificultad de hacer eso, hacía intérpretes cuando estaba en el colegio). Y más encima a nadie le importó cuando hice un Smalltalk que conversaba con un servidor en C++, o cuando hice un servidor en C que ejecutaba un SQL que enviaba una aplicación cliente y que era generado en tiempo de ejecución. En general mi experiencia es que la gente pide, pero no porque quiera eso, sino simplemente por pedir, como los nenes, ¿o las nenas? ;-) Luego no saben qué hacer con lo que pidieron. Simplemente si alguien se sienta 5 minutos y sale con un sistema distribuido, el resto asume que es trivial y que por lo tanto no importa. Me he dado cuenta con el tiempo que si realmente a alguien le importa contribuye con su tiempo (o su dinero) pero idealmente con su tiempo y de esa manera se produce algo que al resto sí le importa, de modo que no queda tirado en un rincón y luego se pierde. Además casi no uso Smalltalk hace mucho tiempo y quedaría todo el código botado rápidamente porque sinceramente no tengo casos de uso en los que requiera Smalltalk distruido. Hoy en día todos los sistemas son distribuidos. Hasta un niño de 15 años puede hacer páginas web y construir un sistema distribuido en PHP sin necesidad de hacer que viajen objetos con proxies ni tener garbage collection distribuido, simplemente usa HTTP y HTML. De hecho si los sistemas distribuidos eran la gran panacea en los 90's, hoy en día es cloud computing. Al parecer Smalltalk ya se retiró de toda polémica y va más bien tratando de alcanzar a reproducir lo que había 20 años atrás debido a la tremenda fragmentación del mercado que implica que algo está en un vendor y no en otro. Por lo que veo Pharo es la alternativa más seria a tener un Smalltalk estándar sobre el cuál se pueda (re)construir lo que había hace 20 años. Puedo estar equivocado, pero es la misma sensación que me dio Eclipse, un IDE open source que terminó siendo la base de todos los IDEs modernos en Java. Supongo que con Pharo va a pasar lo mismo en el mundo Smalltalk. Prefiero hacer algo que el resto use y que por lo tanto le sirva para algo. La gran ventaja, IMHO, de crear un EJB en Smalltalk es que como Smalltalk no es tipado, al decir ok, este objeto se serializa y se envía, automáticamente lo hiciste para todos los objetos serializables. La verdad es que no recuerdo si Smalltalk tiene una convención respecto de los objetos serializables, pero espero que no. Supongo que al llegar a un objeto no serializable como podría ser un socket por ejemplo, simplemente lo ignora o bien tira un error. Fíjense que lo msimo debe ocurrir si tengo un socket abierto y se me ocurre guardar la imagen. Si se guarda una representación de un socket abierto en un archivo, cuando se rescate ese objeto debiera estar en un estado inválido, simplemente o no se guardó o lo que se guardó no sirve. Bueno, siempre es un gusto conversar con ustedes, aunque no lo crean, me hacen recordar buenos tiempos. ;-) Saludos, Guillermo. On Tue, 2010-10-12 at 08:46 -0300, andres wrote: > Guillermo, todavía no me queda claro si sos un troll o simplemente un > charlatán que conoce un set de buzzwords y las tira al aire, así que > cortemos por lo sano: yo te hago una lista de las dificultades de hacer > el famoso punto 3) del que tanto hablamos y vos te comprometés a filmar > la pantalla de tu ordenador mientras lo implementás en 16 horas, > arrancando de la versión 1.1.1 de Pharo one-click y sin usar un > framework de distribución ya implementado. Después distribuís el > changeset y los que quieran lo prueban. > > Saludos, > Andrés > > > Guillermo Schwarz escribió: > > unlp > > > > Me dijeron que era la mejor universidad de Argentina... parece que > > no ;-) > > > > Y si es tan complicado, ¿porqué no los cuentas dónde están las > > complicaciones? > > > > ¿O no saber cómo hacerlo te convierte en experto como para decir que > > nadie más lo puede hacer o cuál es el camino equivocado? > > > > Sos genial!!! > > > > No sabes cuánto me hacés reir. :)) > > > > En todo caso es una falacia típica. Lo mismo que hace Alan Turing cuando > > dice que si su máquina es indecidible entonces todas lo son. Primero > > encuentra el problema equivocado, luego plantéalo de la manera > > equivocada, luego presenta una solución que no lo resuelve y que es la > > solución más general posible... ¿No se han preguntado porqué todos > > estudiamos la indecibilidad de la máquina de Turing universal? Si eso no > > es crear the "dark ages", no sé lo que es. > > > > Ejemplos hay muchos: > > > > http://cssbl.com/frases-01.htm > > > > Ahora yendo específicamente al tema de los objetos distribuidos, no veo > > porqué sería complicado si puedes: > > > > 1. Serializar un objeto (convertirlo en String). > > 2. Enviarlo por un socket. > > 3. Deserializarlo al otro lado. > > > > Quizás te imaginas que el problema es que las transacciones distribuidas > > no podrían funcionar. Eso lo resuelven las bases de datos con 2 phase > > commit. Si estamos hablando de transacciones en memoria (todo en > > Smalltalk, como me imaginaría a GemStone, sin una base de datos como > > Oracle por debajo), existe memoria transaccional. Y bueno se puede > > seguir escarbando, todas esas cosas están resueltas, pero nótese que > > J2EE (y por ende EJB) sólo llega a la base de datos, no hace ninguna > > transacción en memoria y esa es la razón por la que los EJB deben ser > > stateless y no stateful. > > > > Si son stateful entonces no hay manera de hacer participar a esos > > objetos de las transacciones de la base de datos. Ok, si tenemos memoria > > transaccional e implementamos 2 phase commit en memoria se podría, pero > > ¿para qué? ¿qué caso de uso lo requiere realmente? Generalmente todas > > las transacciones se pueden resolver a nivel de base de datos, y por lo > > menos a mí nunca me ha tocado que sea necesario hacerlo a nivel de RAM. > > > > De hecho prefería implementar un SQL en Smalltalk con transacciones y > > todo que tener que generar engendros que no son ni una cosa ni la otra. > > (De hecho SQL está implementado en C y en Java, no veo ninguna razón > > para no poder implementarlo en Smalltalk). > > > > Saludos, > > Guillermo. > > > > On Mon, 2010-10-11 at 17:50 -0300, andres wrote: > >> Guillermo Schwarz escribió: > >>> Por lo visto ustedes tienen tan claro como yo como implementar todo > >>> esto. > >> No, para nada! Justamente por eso esperaba que vos me mostraras cómo; > >> todo lo que vos considerás trivial yo lo considero complicadísimo y que > >> lleva meses de implementación, de ahí mi curiosidad. Una pena que no te > >> sirva de mucho hacerlo :( > >> > >>> Bueno, al menos lo que mencionaba respecto de thisContext está > >>> implementado en Pharo. > >>> > >>> Basta con imprimir: > >>> > >>> thisContext sender > >>> > >>> y se ve que funciona. > >> Si, tal cual! De ahí ya estamos a un pasito nomás. Grosso, no? > >> > >> Bueno, creo que este thread ya no da para mas. > >> > >> Saludos! > >> Andrés > >> > > > -- Simplex Veri Sigillum -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
