Gemstone fue comprado por VMWare
Locked
Re: Gemstone fue comprado por VMWare
 
|
Che que groso, que numero sale en la loteria mañana? :)
2010/5/8 Guillermo Schwarz <[hidden email]>: > Lo que pasa siempre con estas adquisiciones: > Como yo lo veo, los compradores dicen "Nuestro objetivo es ir hacia acá y > esta empresita que se vende por X dinero nos entorpece el paso con su > producto Y, comprémosla y así su producto lo incorporamos/descontinuamos". > Le pasó a Digitalk con su producto Visual Smalltalk para Windows cuando los > compró ParcPlace. El resultado podría haber sido un producto integrado, pero > en realidad ParcPlace tenía el producto caro que era multiplataforma, > mientras Digitalk sólo tenía Visual Smalltalk (y Smalltalk Express que era > una versiòn gratuita para Windows 3.1). > Muchos pensaban que la nueva empresa se llamaría DarkPlaceToTalk ;-) > Pero la visión de ParcPlace fue matar el producto VisualSmalltalk antes de > que fuera muy grande... y lo lograron... matando de paso a ParcPlace que se > quedó con menos dinero y una gran base de usuarios desilusionados que se > convirtieron a Java, ya que el costo de reescribir todo a otra versión de > Smalltalk era ridículamente alto pensando que nada te aseguraba que no > pasara de nuevo. > Ahora tenemos una empresa como SpringSource que se dedica a crear > bibliotecas open source en Java para conectarse a cualquier cosa mediante el > framework Spring, que es adquirida por VMWare y SalesForce (la empresa > resultante se llama VMForce en vez de SalesWare por suerte). VMWare está en > el negocio de cloud computing por el lado de proveedor de IaaS y SalesForce > por el lado de SaaS. Al comprar SpringSource se están metiendo al mundo Java > donde claramente estará el dinero en los próximos años porque todos querrán > correr sus aplicaciones en ambientes altamente escalables (cloud). > ¿Porqué compran GemStone? Desde el punto de vista de Spring no tiene mucho > sentido ya que Spring es un framework para conectarse a cualquier cosa, > GemStone es una base de datos OO que funciona principalmente en Smalltalk y > como todos sabemos en Smalltalk generalmente se desarrollan las ideas y > luego se implementan en Java cuando van a pasar a modo "mainstream" o "ahora > todo el mundo podrá hacer esto también". Eso también se llama, "salgamos del > modo artesanal para pocos clientes especiales (mercado nicho) y entremos en > el mercado de productos masivos (industria)". Ok, los términos no están bien > usados pero es claro que en el mundo Java tiendes que industrializar el > proceso de desarrollo de software, lo que significa que cuando un > programador se equivoca se prende una luz roja, el compilador reclama y el > sistema de control de versiones o LuntBuild no permite que se haga merge de > esa rama en el trunk. > De modo que dudo que la intención de Spring sea colaborar con el mundo > Smalltalk. Lo más probable es que lo vean como un mercado nicho al que no > pueden entrar fácilmente porque hay un producto Smalltalk/GemStone que lo > satisface plenamente y de formas que en el mundo Java no se pueden imaginar. > Al matar GemStone, habrá una migración de clientes desencantados con la poca > estabilidad de la plataforma y que verán como Java podría hacer lo mismo. > Ese no es el objetivo principal de Spring, pero así fue como se dio en 1996, > dudo mucho que ahora pase algo diferente. > Por el lado de GemFire, "GemFire Enterprise is in-memory distributed data > management platform that pools memory (and CPU, network and optionally local > disk) across multiple processes to manage application objects and behavior. > Using dynamic replication and data partitioning techniques, GemFire > Enterprise offers continuous availability, high performance and linear > scalability for data intensive applications without compromising on data > consistency, even under failure conditions. In addition to being a > distributed data container, it is an active data management system that uses > an optimized low latency distribution layer for reliable asynchronous event > notifications and guaranteed message delivery." Creo que eso lo dice > todo. Más adelante dice "native support for Java", "elasticity: nodes can be > added dynamically". > O sea, es un IaaS para implementar Google Application Engine. > El resultado de esto será como alguien ya dijo en este thread, vender o > dejar morir las unidades de negocio que no vayan de acuerdo al modelo de > negocios propuesto. La propuesta de valor de VMForce va por el lado de > proveer cloud computing y claramente se inclinan más por Java que por > Smalltalk. > Antes pensaba que Smalltalk era superior a C++ y a Java y que simplemente el > producto inferior, al tener más mercado, lograba comprarse al producto > superior. Pero no puede ser que no exista una estrategia de negocios que de > alguna manera proteja o encapsule a las empresas que proveen Smalltalk, > sobre todo si la tecnología es superior. > 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. > Siguiendo la analogía es como Apple desarrollando todas estas tecnologías > coolisimas, pero cada cierto tiempo haciendo borrón y cuenta nueva y dejando > a sus fanboys botados y desilusionados, y por detrás Microsoft copiando todo > y quedándose con la mayor parte del mercado porque mantiene su > compatibilidad hacia atrás hasta con DOS. > Saludos, > Guillermo. > > 2010/5/7 Esteban Lorenzano <[hidden email]> >> >> ...y porque a veces las decisiones estratégicas que toma una empresa no >> son las mismas que toma otra, y eso hace que el producto X que antes dejaba >> plata deje de dejarla. >> Yo tengo mis serias dudas de que una empresa que esta concentrada en Java >> (SpringSource) pueda/quiera impulsar una plataforma Smalltalk. Pero dicho >> esto, también creo que eso es puro prejuicio: nos estamos preocupando de >> algo de lo que no tenemos ni idea. Supongo que lo mejor es "desensillar >> hasta que aclare". Ya veremos en unos meses cual es el rumbo real que va a >> tomar gemstone. >> >> Saludos, >> Esteban >> >> El 07/05/2010, a las 2:46p.m., Andres Valloud escribió: >> >> > Pero por ejemplo GemStone/S gana plata, no? Entonces porque tirar >> > plata por la ventana? >> > >> > 2010/5/7 Hernán Galante <[hidden email]>: >> >> Justamente, para mi, esa es la "mala" noticia. GemFire es el interés de >> >> la >> >> compra. El resto, son "unidades de negocio", que a la larga, o me >> >> desprendo, >> >> o las cierro. Ojalá que me equivoque. >> >> Saludos, >> >> Hernán.- >> >> >> >> 2010/5/7 Angel "Java" Lopez <[hidden email]> >> >>> >> >>> Hola gente! >> >>> >> >>> >> >>> >> >>> Recuerden que no es solo VMWare el que compra, van a estar con >> >>> SpringSource y Rod Johnson. De hecho, la portada de Gemstone.com dice >> >>> “nos >> >>> compro SpringSource”. >> >>> >> >>> >> >>> >> >>> La joyita parece que es GemFire (alguien sabe? Parece escrito y >> >>> dirigido a >> >>> Java, desde 0) no parece basado en Smalltalk. Intuyo que la gente de >> >>> SpringSource querra incorporarlo a su framework y productos >> >>> opensource. >> >>> >> >>> >> >>> >> >>> Recien veo que lo nombran asi en: >> >>> >> >>> http://www.springsource.com/springsource-acquires-gemstone-systems >> >>> >> >>> >> >>> >> >>> También lo mencionan asi en el enlace original que enviaron: >> >>> >> >>> >> >>> >> >>> http://www.springsource.com/newsevents/springsource-acquires-gemstone-systems >> >>> >> >>> >> >>> >> >>> Todo apunta a GemFire, cloud computing, y related topics. SpringSource >> >>> adquirio hace poco http://www.rabbitmq.com/ un message queue. >> >>> >> >>> >> >>> >> >>> Leo ahí >> >>> >> >>> “now SpringSource is forging ahead with the infrastructure needed for >> >>> distributed data.” >> >>> >> >>> >> >>> >> >>> Yo interpreto: queremos GemFire, seguiremos soportando otros productos >> >>> de >> >>> GemStone, pero la papa para nosotros esta en GemFire. No por un tema >> >>> de >> >>> dinero en GemFire, sino por su alineacion con la estrategia de la >> >>> empresa. >> >>> VMWare quiere convertirse en la empresa por debajo de gran parte de la >> >>> cloud, o de cualquier cloud que alguien quiera construir. Imagino. >> >>> >> >>> >> >>> >> >>> Nos leemos! >> >>> >> >>> >> >>> >> >>> Angel "Java" Lopez >> >>> >> >>> http://www.ajlopez.com/ >> >>> >> >>> http://twitter.com/ajlopez >> >>> >> >>> >> >>> >> >>> De: [hidden email] >> >>> [mailto:[hidden email]] >> >>> En nombre de Esteban Lorenzano >> >>> Enviado el: viernes, 07 de mayo de 2010 12:58 >> >>> Para: [hidden email] >> >>> Asunto: Re: [clubSmalltalk] Re: Gemstone fue comprado por VMWare >> >>> >> >>> >> >>> >> >>> Si, un oracle de similares dimensiones cuesta un montón también >> >>> >> >>> >> >>> >> >>> El 07/05/2010, a las 12:46p.m., Giuseppe Luigi Punzi escribió: >> >>> >> >>> Hombre, a los niveles a los que se supone que está destinado, no es >> >>> dinero. >> >>> >> >>> Según la Wikipedia: >> >>> After a major transition, GemStone for Smalltalk continues as >> >>> "GemStone/S" >> >>> and various C++ and Java products for scalable, multi-tier distributed >> >>> systems. GemStone Systems, Inc. now develops and markets GemFire, >> >>> which is >> >>> notable for CEP (complex event processing), Event Stream Processing, >> >>> data >> >>> virtualization and distributed caching. >> >>> >> >>> El vie, 07-05-2010 a las 12:31 -0300, Nahuel Silva escribió: >> >>> >> >>> Si tienen otros productos pero me parece que lo que deja la crema es >> >>> gemstone :) >> >>> >> >>> >> >>> >> >>> La versión 64bits par auna empresa no es nada pero nada barata >> >>> >> >>> >> >>> >> >>> Salux >> >>> >> >>> 2010/5/7 Diogenes Moreira <[hidden email]> >> >>> >> >>> y Eso significa que no le van poner mucha pila a mantenerla o darle >> >>> mayor >> >>> funcionalidad... :( >> >>> >> >>> >> >>> >> >>> Igual, por lo que lei en los blog..lo compran por la capacidad >> >>> grosisima >> >>> de escalar con el juego Gems/ Stone... sobre lo que esta basado la >> >>> gran >> >>> parte de los productos.. >> >>> >> >>> >> >>> >> >>> Esperemos que sigan con las mismas personas y que no hagan bosta >> >>> todo... >> >>> >> >>> 2010/5/7 Gabriel Brunstein <[hidden email]> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> Gemstone vende otros productos además de la base de objetos Gemstone, >> >>> me >> >>> equivoco? Quizá no le den mucha bola a la base de objetos, que es lo >> >>> que a >> >>> nosotros nos interesa, no? >> >>> >> >>> 2010/5/7 [hidden email] <[hidden email]> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> Gracias por compartir la noticia. >> >>> Tampoco me queda claro si será bueno, de todas maneras entiendo que >> >>> VMWare está dirigido por Paul Maritz, que es un ex-Microsoft (recuerdo >> >>> hace muchos años que vino a Argentina y se hizo mucho ruido con eso). >> >>> Intentando ser optimista, se podría decir que como Gemstone es un >> >>> Smalltalk y como VMWare es una de las empresas importantes de la >> >>> industria, podría ser bueno . O al menos interesante ver qué hace con >> >>> un Smalltalk una empresa comercialmente importante y dirigida por >> >>> alguien que se cansó de vendernos software exitosamente durante muchos >> >>> años. >> >>> >> >>> Diego Coronel >> >>> >> >>> >> >>> On May 6, 8:18 pm, Hernan Wilkinson <[hidden email]> >> >>> wrote: >> >>> >> >>> >> >>> >> >>>> http://www.springsource.com/gemstone-systems-acquisition-faq >> >>>> >> >>>> No estoy seguro si es bueno o malo, pero la verdad es una sorpresa... >> >>>> shokeante. Esperemos que sea para bien... >> >>>> >> >>>> -- >> >>>> To post to this group, send email to [hidden email] >> >>>> To unsubscribe from this group, send email to >> >>>> [hidden email] >> >>>> >> >>>> http://www.clubSmalltalk.org >> >>> >> >>> -- >> >>> To post to this group, send email to [hidden email] >> >>> To unsubscribe from this group, send email to >> >>> [hidden email] >> >>> >> >>> http://www.clubSmalltalk.org >> >>> >> >>> >> >>> -- >> >>> >> >>> >> >>> >> >>> To post to this group, send email to [hidden email] >> >>> To unsubscribe from this group, send email to >> >>> [hidden email] >> >>> >> >>> http://www.clubSmalltalk.org >> >>> >> >>> >> >>> >> >>> -- >> >>> >> >>> >> >>> >> >>> To post to this group, send email to [hidden email] >> >>> To unsubscribe from this group, send email to >> >>> [hidden email] >> >>> >> >>> http://www.clubSmalltalk.org >> >>> >> >>> >> >>> >> >>> -- >> >>> To post to this group, send email to [hidden email] >> >>> To unsubscribe from this group, send email to >> >>> [hidden email] >> >>> >> >>> http://www.clubSmalltalk.org >> >>> >> >>> >> >>> >> >>> -- >> >>> To post to this group, send email to [hidden email] >> >>> To unsubscribe from this group, send email to >> >>> [hidden email] >> >>> >> >>> http://www.clubSmalltalk.org >> >>> >> >>> >> >>> >> >>> -- >> >>> To post to this group, send email to [hidden email] >> >>> To unsubscribe from this group, send email to >> >>> [hidden email] >> >>> >> >>> http://www.clubSmalltalk.org >> >>> >> >>> No virus found in this incoming message. >> >>> Checked by AVG - www.avg.com >> >>> Version: 8.5.437 / Virus Database: 271.1.1/2859 - Release Date: >> >>> 05/07/10 >> >>> 06:26:00 >> >>> >> >>> -- >> >>> To post to this group, send email to [hidden email] >> >>> To unsubscribe from this group, send email to >> >>> [hidden email] >> >>> >> >>> http://www.clubSmalltalk.org >> >> >> >> -- >> >> To post to this group, send email to [hidden email] >> >> To unsubscribe from this group, send email to >> >> [hidden email] >> >> >> >> http://www.clubSmalltalk.org >> > >> > -- >> > To post to this group, send email to [hidden email] >> > To unsubscribe from this group, send email to >> > [hidden email] >> > >> > http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Gemstone fue comprado por VMWare
|
|
In reply to this post by Manzanos
> "todo lo que se puede hacer con Smalltalk también se puede hacer con Java"
Es una pena que no pueda citar el caso concreto, pero a veces esto de arriba es cierto si y solo si: * multiplicas la cantidad de programadores por 10 * multiplicas la cantidad de tiempo y dinero requerido por 10 * dividis la cantidad de features por 10 Asi cualquiera. Y esto no lo dijeron Smalltalkers, dicho sea de paso... Andres. 2010/5/8 Norberto Manzanos <[hidden email]>: > Muy buenos datos, Guillermo. Hay muchos temas interesantes. > Me quedo con una cuestión. > "todo lo que se puede hacer con Smalltalk también se puede hacer con Java" > > Yo no se si esto es así. Muchas veces he pensado que con un criterio > eficientista, conviene desarrollar con Java. > La cuestión es si el eficientismo, el "se puede hacer igual", el sólo medir > los resultados obtenidos y el costo que implicaron es lo único que importa. > Indudablemente, no se puede esperar otra cosa de una empresa privada. Al > menos, si la ley fundamental es el aumento de la ganancia y su consecuente > reducción de costos. También hay que considerar que el aumento de la > ganancia no tiene un único camino posible, no siempre es tan mecánico. Ahí > está Google con su modelo de negocios bastante más complejo, posicionandose > entre las primeras empresas del mundo. > Pero más allá de que Smalltalk sea una tecnología mejor, y que es una > cuestión muy difícil de explicar cómo puede ser que una tecnología mejor no > se imponga (creo que el gran culpable es la economía de mercado, pero admito > que no es sencillo), me parece que lo que no tenemos que olvidar es nuestra > situación en tanto programadores. Porque no se trata sólo de dos actores: > empresas y consumidores. Se trata también de trabajadores que están en el > medio del proceso. Smalltalk no es una tecnología mejor (o lo sería) porque > produzca código más eficiente, más sustentable, más escalable. Es mejor > porque el trabajo con esa tecnología es más humano, es más placentero, > requiere otras habilidades, además de las que se requieren en otros > lenguajes, se puede explicar mejor a los usuarios, se asemeja más a los > modos de pensamiento generales, etc, etc. > Se que son argumentos que parecen no poder salir del círculo de fans de > Smalltalk, que no se pueden esgrimir en una situación de negocios o de > contratación, etc. > Acaso una de las explicaciones de la "derrota" de Smalltalk frente a Java es > que lo que piensan y sienten los programadores no es tenido en cuenta, si no > sólo la eficiencia y la optimización de la ganancia. > > Saludos > Norberto > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Gemstone fue comprado por VMWare
|
|
In reply to this post by Manzanos
Porque es mejor van Gogh que la mayoria de los pintores del 1400?
Y si te gusta van Gogh, porque te importa estar con la minoria? 2010/5/8 Norberto Manzanos <[hidden email]>: > Muy buenos datos, Guillermo. Hay muchos temas interesantes. > Me quedo con una cuestión. > "todo lo que se puede hacer con Smalltalk también se puede hacer con Java" > > Yo no se si esto es así. Muchas veces he pensado que con un criterio > eficientista, conviene desarrollar con Java. > La cuestión es si el eficientismo, el "se puede hacer igual", el sólo medir > los resultados obtenidos y el costo que implicaron es lo único que importa. > Indudablemente, no se puede esperar otra cosa de una empresa privada. Al > menos, si la ley fundamental es el aumento de la ganancia y su consecuente > reducción de costos. También hay que considerar que el aumento de la > ganancia no tiene un único camino posible, no siempre es tan mecánico. Ahí > está Google con su modelo de negocios bastante más complejo, posicionandose > entre las primeras empresas del mundo. > Pero más allá de que Smalltalk sea una tecnología mejor, y que es una > cuestión muy difícil de explicar cómo puede ser que una tecnología mejor no > se imponga (creo que el gran culpable es la economía de mercado, pero admito > que no es sencillo), me parece que lo que no tenemos que olvidar es nuestra > situación en tanto programadores. Porque no se trata sólo de dos actores: > empresas y consumidores. Se trata también de trabajadores que están en el > medio del proceso. Smalltalk no es una tecnología mejor (o lo sería) porque > produzca código más eficiente, más sustentable, más escalable. Es mejor > porque el trabajo con esa tecnología es más humano, es más placentero, > requiere otras habilidades, además de las que se requieren en otros > lenguajes, se puede explicar mejor a los usuarios, se asemeja más a los > modos de pensamiento generales, etc, etc. > Se que son argumentos que parecen no poder salir del círculo de fans de > Smalltalk, que no se pueden esgrimir en una situación de negocios o de > contratación, etc. > Acaso una de las explicaciones de la "derrota" de Smalltalk frente a Java es > que lo que piensan y sienten los programadores no es tenido en cuenta, si no > sólo la eficiencia y la optimización de la ganancia. > > Saludos > Norberto > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Gemstone fue comprado por VMWare
|
|
In reply to this post by Francisco A. Lizarralde
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 <[hidden email]> Hola Guillermo, -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Gemstone fue comprado por VMWare
|
|
In reply to this post by Manzanos
Norberto,
En realidad yo soy fan de Smalltalk, fan número 1. Trabajo en Java porque nunca he encontrado trabajo en Smalltalk (vivo en Chile), pero siempre resuelvo los problemas en Smalltalk y luego sólo los traduzco mentalmente a Java. Es infinitamente más fácil que pensarlo directamente en Java.
-- Y tan fanático soy que primero aprendí C++ y aprendí las 30 reglas para programar en C++ y luego me percaté que en Smalltalk todo estaba resuelto o en el lenguaje o en su biblioteca y quedé sorprendido de la pérdida de tiempo que era C++ (y eso que es posterior).
Luego apareció Java y me decepcionó por ser un término medio entre C++ y Smalltalk. Pero bueno, es más eficiente que C++ y lo ha desplazado de todo el ámbito "empresarial". Entonces, si Java pudo hacer esto con C++, ¿porque no ocurre lo mismo entre Smalltalk y Java? Primero creo que tiene que ver con que no hay una empresa grande y conocida detrás (esto puede cambiar con Spring...).
Luego creo que tiene que ver con lo que ya dije respecto de que el lenguaje no es "safe", se lo paso a un programador novato y puede arruinar el sistema. Restringirlo mediante un sistema de seguridad simple no debiera ser tan difícil. Agrégale un sistema de unit tests automatizado antes de hacer commit en git y listo.
Finalmente es el problema de fragmentación de la plataforma. Ya lo dije antes en este grupo y no voy a repetir el comentario. Lo bueno de todo esto es que puede ser la oportunidad de Smalltalk de hacerse conocido con GemStone. Habría que ver qué características de GemStone no pueden ser reproducidas por otras bases de datos, luego qué características de esas sólo se pueden usar desde Smalltalk y no desde Java. Creo que es mucho pedir, pero no se me ocurre otra manera.
Eso de que lo que piensan los programadores no se toma en cuenta, està claro. El que toma la decisión mira una planilla Excel y ve costos y beneficios. El punto es que esperaba que efectivamente hubiera beneficios en el caso de Smalltalk que fueran irrefutables.
Me queda claro que JP Morgan evalúa asì sus proyectos. Supe que hace 10 años migrarían todo a Java, pero parece que no les funcionó porque según he sabido todavía usan Smalltalk. Imagino porqué. Debe tener que ver con el hecho de que no saben desarrollar software, pero sí saben de números. Y en un caso sale más caro que en el otro.
El resto simplemente sigue la moda. Es cosa de ver lo que pasó con esos papeles llamados "deuda estructurada". JP Morgan no se quedó con esos papeles "porque los números no daban". ¿Es claro como toman decisiones unos y otros no?
Saludos, Guillermo. 2010/5/8 Norberto Manzanos <[hidden email]> Muy buenos datos, Guillermo. Hay muchos temas interesantes. -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Gemstone fue comprado por VMWare
|
|
In reply to this post by Francisco A. Lizarralde
Hola gente!
Una respuesta rápida: - Java tuvo el respaldo de Sun (mas o menos) - Tuvo una primera penetración muy interesante, de la mano de Netscape - Para cualquiera que viniera de C++, fue relativamente fácil de aprender - Tenia una única especificación de VM (cada Smalltalk en los 90, y creo que ahora también, es un mundo en si mismo) - Java le gana a C++ con eso: única especificación de VM, grandísima portabilidad (con respecto a lo que daba C++, y arriesgo a decir, para lo que daba Smalltalk entonces). - Java le gana a C++ con garbage collector. - Java tiene una librería de clases definida, estándar, muy abarcativa (anios después, lo mismo aportaría .NET) - Java consolida una comunidad, aparecen las JSR, mucho código abierto (Hibernate un caso), incluso "enmendando" los errores de Sun (EJB 1.x, EJB 2.x) - IBM "adopta" a Java, como para tener un lenguaje que ejecute en todo lo que quiere vender y fabricar. - La comunidad se agrupa, con ejemplos como la Apache Foundation. - Smalltalk no tenia eso: una sola implementación, una empresa sola atrás (Sun), un sponsor como IBM. - Smalltalk, que tuvo su ventana de oportunidad en el mercado, en los ochenta, de cruzar "el abismo" no penetro por: costos (compra de software, hardware necesario para ejecutarlo). Ejemplo parecido: Common Lisp. También, falta de representantes comerciales: donde conseguía yo Smalltalk en los 80? O Common Lisp? Era muy raro encontrarlo. De hecho, para practicar, tuve que hacer mis propios interpretes minimos, tipo el TinyTalk que vi después en Buddy - La idea, nacida en Xerox Parc, tipo "yo hago todo, yo dibujo todo, yo manejo toda la ventana, dibujo las fonts.. etc", de Smalltalk, conspiro en el costo de las implementaciones, y en su la adopción (vean como en Java, la actitud Swing, se vio desplazada en gran parte por la actitud SWT de IBM, que en vez de dibujar todo, adopto lo que ya venia en las interfaces graficas de sus anfitriones). - Luego, históricamente se desmembró en muchas opciones (empresas que ofrecían Smalltalk diferentes) - Al llegar los 90, Java apareció, en una situación donde podía hacer pie: hardware y software necesario para desarrollar Java, era prácticamente commodity. No hizo falta representante en cada país, para adoptar Java: todo se encontraba en la red. - Programar en los 80 para Apple? Hmmm... había que ser descendiente directo de alguien que haya desembarcado en el Mayflower, según Apple. Por eso hubo mas desarrollo sobre DOS, y luego sobre Windows. - A fines de los 80, principios de los 90, con la aparición y adopción de Windows, Smalltalk tuvo otra ventana de oportunidad: la programación grafica para PC. Lenguajes como Actor, derivados de Forth, que recuerde, también pelearon ahí. Pero Smalltalk tenia como soporte, empresas relativamente chicas (no un Borland, p.ej.), que cobraban no poco por el entorno. Y la aparición de una interface como Visual Basic, amaino las necesidades de nuevos formas de diseniar la interfaz grafica de una aplicación. Delphi fue la respuesta de Borland a eso (notablemente, mucho de Delphi, luego evoluciona a .NET). - Todo el mundo podía desarrollar en Java, sin tener que pagar licencias. Solo las IDEs, y eso, solo por un tiempo. - Al comienzo del siglo, .NET toma gran parte de esas cualidades, con alguna vuelta de tuerca interesante. - Hoy, lenguajes dinamicos y otros tipos de lenguajes (funcionales, por ejemplo), se implementan sobre VMs Java o .NET. Incluso, Smalltalk. Hay que entender que la adopción de una tecnología, muchas veces no tiene que ver con sus meritos, sino con los problemas que soluciona, y la facilidad o dificultad con que los soluciona. Nos leemos! Angel "Java" Lopez http://www.ajlopez.com/ http://twitter.com/ajlopez -----Mensaje original----- De: [hidden email] [mailto:[hidden email]] En nombre de Francisco A. Lizarralde Enviado el: sábado, 08 de mayo de 2010 11:42 Para: [hidden email] Asunto: Re: [clubSmalltalk] Re: Gemstone fue comprado por VMWare 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 [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.437 / Virus Database: 271.1.1/2863 - Release Date: 05/09/10 06:26:00 -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
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:
[hidden email] [mailto:[hidden email]] En
nombre de Guillermo Schwarz 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 <[hidden email]> Hola Guillermo,
Cuál es la verdadera razón por la cual, no puede decirse: 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 To post to this group, send email to [hidden email]
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
La primera frase debia decir: Smalltalk es seguro, si voy les das la imagen con la que generas
el EXE de tu producto a un “novato” à sos vos el que cometiste el error. Si no tenes imágenes de respaldo à sos vos el (“experto”) que cometiste el error. Si no tenes los packages en el repositorio à sos vos el (“experto”) que cometiste el error. Si no tenes los packages en el disco duro à sos vos el (“experto”) que cometiste el error. Saludos, Bruno De:
[hidden email] [mailto:[hidden email]] En
nombre de Smalltalk 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:
[hidden email] [mailto:[hidden email]] En
nombre de Guillermo Schwarz 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 <[hidden email]> Hola Guillermo,
Cuál es la verdadera razón por la cual, no puede decirse: 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 To post to this group, send email to [hidden email]
-- -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Gemstone fue comprado por VMWare
|
|
In reply to this post by BrunoBB
Dear Smalltalk,
Digo Bruno... Tenès razòn. No sè. Mi opiniòn viene de mi experencia jugando con distntos ambientes (Smalltalk Express, Visual Smalltalk, St/X, Dolphin, etc.) y lo que he leìdo del tema. Tambièn he leìdo acerca de esto como te comentaba y que consideras un error. Ok, poiint taken. Y de que GemStone/S tiene permisos para evitar esto en su "base de datos", lo cuàl tambièn tiene cualquier servidor SQL, pero por tratarse de Smalltalk es màs interesante.
Che, no lo sè todo. Para eso son estas conversaciones, ¿no? No te enojès. Ahora bien tuve la suerte de usar Envy en un proyecto en Java (no preguntès...) y no era tan fantàstico como decìan. Es cierto, puedes tener control de versiones a nivel de clases y mètodos, pero cosas bàsicas como "generar lìneas base" que en CVS es tan smple como crear un tag y en SVN es el nùmero del check-in, en Envy no existe. Y es màs, conversando en el grupo de XP (como debes saber todos los fundadores de XP son Smalltalkers) me indicaron que efectivamente Envy no tiene eso y que habìa un producto (o conjunto de scripts) que lograba eso, pero obviamente tenìa su precio... No estoy en contra de ponerle precio a las cosas, pero a veces si vivimos encerrados en el mundo X no vemos lo que està resuelto en el mundo Y.
Pues bien, volviendo al tema de la adquisiciòn de GemStone, acà hay una entrevista a Rod Johnson, fundador del framework Spring: http://www.theserverside.com/report/Why-Did-SpringSource-Buy-GemStone-An-Discussion-with-Rod-Johnson
Dice que Terracotta (50 mil tx por segundo) y GridGain eran sus preferidos. Pero que compraron GemStone y que es "una fantàstica tecnologìa" pero no dice porquè. Ademàs dice que era más barata y que la decisión no fue por plata... (¿la venderon barata?). Algo no junta ni pega, pero claramente este señor no está diciendo la verdad, porque es un technologist, sus fundamentos tècnicos serían un poco más profundos que "es la mejor tecnología" o "es impresionante" o "está super probado". En especial viniendo del mundo Spring en el que èl mismo declaró que no era necesario usar EJBs para implementar J2EE y lo probó con una implementación llamada Spring, o sea, es un tipo que va directo al hueso y ahora se las está dando de político...
Saludos, Guillermo.
-- 2010/5/10 Smalltalk <[hidden email]>
-- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
a mi de esa entrevista lo que me parece es que va quedando claro que en el largo plazo no les interesa para nada hacer crecer gemstone (mas allá de que no lo maten, no le van a poner foco seguro), porque lo que les importa es gemfire... y hacerlo funcionar con java.
Saludos, Esteban
-- El 13/05/2010, a las 10:20a.m., Guillermo Schwarz escribió: Dear Smalltalk, To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
Guillermo, no se como es eso de de ENVY con java.
Te cuento mi experiencia. Actualmente trabajo todos los días con ENVY en mi trabajo (con smalltalk), también trabajé con SVN y lo sigo usando para otras cosa. La verdad que hay cosas que hacemos que me cuesta entender cómo se harían con svn (quizá me falte imaginación o ver cómo lo usan en otras empresas), el trabajo en equipo es muy organizado y sencillo, integrar cosas a una rama de producción es muy facil (incluso pasando tiempo desde que se hizo el desarrollo), y se puede seguir toda la historia de cambios muy fácil. Incluso se implementó en la empresa un integrador automático que anda muy bien. Pero bueno, las ventajas/desventajas de esto quizá son dificiles de explicar en dos parrafos. No se a que te referís con "generar líneas base". Con respecto a lo del numero de check-in, para nosotros no es un problema, porque tenemos una convención para nombrar cada versión que se commitea y con eso no hay ningún drama. 2010/5/13 Guillermo Schwarz <[hidden email]> Dear Smalltalk, -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Gemstone fue comprado por VMWare
|
|
In reply to this post by Guillermo Schwarz
Hola gente! Guillermo, gracias por el enlace a la entrevista de Rod Johnson. Por lo que entendí, cuando habla de GemStone (empresa) y su tecnología,
apunta a GemFire: no parece interesarle GemStone/S. Por ejemplo, menta la relación de GemStone con JP Morgan http://www.gemstone.com/customers/jpmorgan y Terracotta y GridGain tienen todo que ver como competencia, a
GemFire, no a GemStone/S. Asi que no veo gran interés en GemStone + Smalltalk. Opciones: -
Mantienen GemStone/S con la base que esta -
O la van abandonando -
O hacen un spin off de código abierto, para que tome la posta la
comunidad Nos leemos! Angel "Java" Lopez http://www.ajlopez.com/ http://twitter.com/ajlopez De: [hidden email]
[mailto:[hidden email]] En nombre de Guillermo Schwarz Dear Smalltalk, Digo Bruno... Tenès razòn. No sè. Mi opiniòn viene de mi experencia
jugando con distntos ambientes (Smalltalk Express, Visual Smalltalk, St/X,
Dolphin, etc.) y lo que he leìdo del tema. Tambièn he leìdo acerca de esto como
te comentaba y que consideras un error. Ok, poiint taken. Y de que GemStone/S
tiene permisos para evitar esto en su "base de datos", lo cuàl
tambièn tiene cualquier servidor SQL, pero por tratarse de Smalltalk es màs
interesante. Che, no lo sè todo. Para eso son estas conversaciones, ¿no?
No te enojès. Ahora bien tuve la suerte de usar Envy en un proyecto en
Java (no preguntès...) y no era tan fantàstico como decìan. Es cierto, puedes
tener control de versiones a nivel de clases y mètodos, pero cosas bàsicas como
"generar lìneas base" que en CVS es tan smple como crear un tag y en
SVN es el nùmero del check-in, en Envy no existe. Y es màs, conversando en el
grupo de XP (como debes saber todos los fundadores de XP son Smalltalkers) me
indicaron que efectivamente Envy no tiene eso y que habìa un producto (o
conjunto de scripts) que lograba eso, pero obviamente tenìa su precio... No
estoy en contra de ponerle precio a las cosas, pero a veces si vivimos
encerrados en el mundo X no vemos lo que està resuelto en el mundo Y. Pues bien, volviendo al tema de la adquisiciòn de GemStone,
acà hay una entrevista a Rod Johnson, fundador del framework Spring: http://www.theserverside.com/report/Why-Did-SpringSource-Buy-GemStone-An-Discussion-with-Rod-Johnson Dice que Terracotta (50 mil tx por segundo) y GridGain eran
sus preferidos. Pero que compraron GemStone y que es "una fantàstica
tecnologìa" pero no dice porquè. Ademàs dice que era más barata y que la
decisión no fue por plata... (¿la venderon barata?). Algo no junta ni pega,
pero claramente este señor no está diciendo la verdad, porque es un technologist,
sus fundamentos tècnicos serían un poco más profundos que "es la mejor
tecnología" o "es impresionante" o "está super
probado". En especial viniendo del mundo Spring en el que èl mismo declaró
que no era necesario usar EJBs para implementar J2EE y lo probó con una
implementación llamada Spring, o sea, es un tipo que va directo al hueso y
ahora se las está dando de político... Saludos, Guillermo. 2010/5/10 Smalltalk <[hidden email]> 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: [hidden email]
[mailto:[hidden email]]
En nombre de Guillermo Schwarz
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 <[hidden email]> Hola Guillermo,
Cuál es la verdadera razón por la cual, no puede decirse: 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 To post to this group, send email to [hidden email]
-- To post to this group, send email to [hidden email] --
-- No virus
found in this incoming message. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Lo que me deja en duda eso es esta frase:
“We were very impressed by the due diligence of the GemStone technology. We were very impressed with the extensive conversations we had with existing customers of GemStone, such as JP Morgan." Supongo que con JP Morgan habrán hablado de GemStone/S, me equivoco? 2010/5/13 Angel "Java" Lopez <[hidden email]>
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Gemstone fue comprado por VMWare
|
|
Hola gente! Gabriel, creo que no. El caso de JP Morgan, que envie en mi
email anterior, habla de GemFire: http://www.gemstone.com/customers/jpmorgan Nos leemos! Angel "Java" Lopez http://www.ajlopez.com/ http://twitter.com/ajlopez De:
[hidden email] [mailto:[hidden email]] En
nombre de Gabriel Brunstein Lo que me deja en duda eso es
esta frase: To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Gemstone fue comprado por VMWare
|
|
In reply to this post by Guillermo Schwarz
Guillermo,
Si bien ya te respondieron quería aportar mis 2 centavitos.
Fijate SmallLint en VAST o code critics en VW. Estos define una batería de tests de possibleBugs y cosas por el estilo. Es cuestión de que para poder mandar a integrar algo al baseline siempre tengan todos los tests en verde. Y siempre podés agregar algunos más. Lo interesante de SmallLint (y de Smalltalk en general, eso es sólo un grupo de tests que alguien ya pensó) es que se pueden hacer tests de metamodelo, o sea, cuidar que no redefinan algo en particular, o cuidar que no asignen el resultado de un ifTrue: o que no envíen tal o cual mensaje, etc.
Ah, y en cuanto a los baselines en ENVY, tené en cuenta los configuration maps. Con eso podés especificar qué versión de qué aplication va para cada versión de tu aplicación. Cada vez que cerrás un sprint de desarrollo integrás todos los cambios y cerrás una nueva versión del cm con todas las nuevas versiones integradas de las aplicaciones (u otros configuration maps) y tenés un nuevo baseline.
Y si querés algo para un "chico", E-Toys en squeak tiene algo para evitar que puedan modificar el código de las clases básicas del sistema. No sé bien cómo funciona, pero sé que está ahí.
Saludos! Mariano.
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
| Free forum by Nabble | Edit this page |