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 <[email protected]> > 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 [email protected] > To unsubscribe from this group, send email to > [email protected]<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
