Guillermo,
Smalltalk es seguro, si voy les das la imagen con la que generas el EXE de tu producto a tu cliente à sos vos el que cometiste el error. Dale al junior una imagen para que juegue luego que genere versiones de los paquetes, y asunto terminado. à Al manejarnos con imágenes lo único que puede hacer un principiante es arruinar su imagen. Va a destruir la clase Array de su imagen ¡, no la de la aplicación. Por otro lado GemStone/S tiene un sistema de permisos à eso no puede pasar. Ahora una pregunta: ¿ En cuántos proyectos estuviste o conoces que haya venido un novato y haya modificado algo y el proyecto se haya hundido por esto ? Te lo pregunto amablemente pq lo ejemplos que pones son IREALES, nunca sucedieron, son solamente cosas que se dicen en internet generalmente por desconocimiento. Nunca he visto o he escuchado en estos casi 11 años que uso Smalltalk algo parecido a lo que tu mencionas. Saludos, Bruno PD: Smalltalk become: nil Ahora mi imagen se arruino (“maldito novato” es broma) pero: 1. Puedo copiar el respaldo mi imagen de respaldo (12 segundos me lleva) 2. Puedo cerrar todo sin salvar la imagen (de inmediato) 3. Puedo instalar los paquetes de 0 (esto casi llega a los 120 segundos) 4. Puedo levantar el Project del repositorio (otros tantos segundo). De: [email protected] [mailto:[email protected]] En nombre de Guillermo Schwarz Enviado el: Monday, May 10, 2010 4:13 AM Para: [email protected] Asunto: Re: [clubSmalltalk] Re: Gemstone fue comprado por VMWare Hola Francisco, En el Blue Book, si no me equivoco, uno de esos libros donde aparece explicado Smalltalk 80, uno de los capítulos parte diciendo que lo bueno de Smalltalk es que se puede redefinir Array#at:put: y aparece el dibujo de un niño haciendo un castillo de naipes y claro, los naipes se le caen. Creo que eso resume lo que pasa con Smalltalk, podemos hacer de todo, excepto evitar que venga un niño (un recién egresado) y nos destruya el castillo de naipes con algo tan simple como re-definir una función básica. La gran ventaja de Java es que no se pude redefinir Array. También es una maldición si lo que quiero es redefinirla, aunque los más puristas me dirán que use factories y cosas por el estilo para crear una clase que se comporte igual y la reemplace. Ok, todo bien, entiendo. Lo que pasa es que Smalltalk sería mucho mejor, creo, si tueviera un una clase Proxy que evitara que cualquier niño redefina algo básico del lenguaje. Creo que eso haría que mucha más gente se interesara en Smalltalk como algo viable organizacionalmente hablando. Y si hablamos de plata, Sun pidió 10 mil millones de dólares al banco, al año siguiente se compró MySql en mil millones y 6 meses despuñes fue vendida 5 mil millones a Oracle. Creo que no es un problema de plata sino de lo que ofrece. Y si lo que ofreces es "lo mejor del mundo", pero "cuidado que se cae", entonces ya no es lo mejor del mundo. De alguna manera se ha descuidado lo que "el cliente quiere". En el mundo Java primero le dieron los Applets, pero no servían porque se demoraban mucho en cargar, luego los Servlets, que corrían en el servidor y eran más livianos que CGI-BIN, luego los EJBs para tener transacciones distribuidas y ORM, y así cada día más, y en general han sido puros fracasos, pero vuelven a levantarse y a ofrecer algo diferente "porque ahora sí". En el mundo Smalltalk como que eso no se da, es más un proceso de autosaisfacción de hacer las cosas bien que un proceso de encontrar lo que quiere el cliente y ofrecerle justamente eso. Y bueno esta es mi opinión, sientanse a sus anchas para opinar diferente. EMHO, o se hacen cosas como SeaSide que son bonitas pero tardías, o se hacen cosas como los Traits, los patrones de diseño o los Unit Tests que luego se implementan en otros lenguajes y todos se olvidan de donde salieron. Saludos, Guillermo. 2010/5/8 Francisco A. Lizarralde <[email protected]> Hola Guillermo, Me parece muy buena tu reflexión. Y me quedé pensando en esta frase: "Ahora pienso que eso de que la tecnología es superior es sólo una ilusión. Es cierto que el lenguaje es el vehículo del pensamiento y por lo tanto en ese sentido Smalltalk es superior, pero cuando vemos los resultados en la práctica, es decir, en el mercado, todo lo que se puede hacer con Smalltalk también se puede hacer con Java y con Java tengo la ventaja de que no me borran de un plumazo todo el código que tengo escrito y probado." Cuál es la verdadera razón por la cual, no puede decirse: "todo lo que se puede hacer con Java también se puede hacer con Smalltalk y con Smalltalk tengo la ventaja de que no me borran de un plumazo todo el código que tengo escrito y probado." Es decir, qué es lo que hace tan masivo a Java, (el poder económico de las empresas que lo sustentan?, que se parece más a C++ ?, que se pueden hacer muchas cosas, mientras dejamos la máquina compilando ? ), cuando en muchos casos no hace más que reproducir ideas ya implementadas y probadas en Smalltalk. Es una pregunta que siempre me hago, y para la cuál aún no he encontrado respuesta. Saludos, Francisco -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] <mailto:clubsmalltalk%[email protected]> http://www.clubSmalltalk.org -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect -- 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
