On 3/28/07, Andres Poncelas <[EMAIL PROTECTED]> wrote: > > > > Andrés P. Poncelas > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > >>> [EMAIL PROTECTED] 28/03/2007 00:44:30 >>> > > > >Luego el problema es que todas las GUIs son diferentes y las jerarquías > de clases son diferentes. >Algunas >jerarquías han sido depuradas más que > otras y siempre existe la incompatibilidad a nivel de >IDE, sin mencionar > >la incompatibilidad de que la aplicación corre sobre un Smalltalk, no sobre > el resto, >e incluso puede que en >versiones posteriores no corra. > > Esto no es tan así, en cualquier smalltalk grande esto no pasa, es mas, he > hecho migración de una versión a la siguiente de VAST y siguiendo las > instrucciones muy correctas que había para tal fin realizadas por el > proveedor no tuve ningún problema. >
¿Pero se necesitaba un programador para hacer eso o se hacìa automàticamente? Te lo pregunto porque en Windows existe la compatibilidad a nivel de binarios. Es decir, si tienes un binario que fue desarrollado hace 20 años, aùn corre en las màquinas actuales, aunque el proveedor ya no exista. Eso matò a la competencia de la plataforma IBM, que eran los Osbornes, los Atari, los Sinclair, los Amiga, los VIC, etc. > >En Java se toman en serio esto de que las aplicaciones antiguas sigan > corriendo sobre las versiones >nuevas del >runtime, porque las empresas > toman la estúpida decisión de no hacer upgrade cuando se >encuentran con > esos >problemas. Y si lo piensan, tiene sentido que sea así, porque a ellos > no les >importa un rábano que tu OOP esté >más limpio o más lindo en la > nueva versión, quieren que funcione y >punto. > > Por un lado decís que la decisión es estúpida y por otro lado que es > lógica.... > Sì, cuando digo "estùpida" lo digo con sarcasmo, porque por alguna razòn los que desarrollamos software pensamos que nuestros clientes son "estùpidos" porque no hacen lo que les decimos, cuando en realidad ellos lo que quieren es un sistema que les solucione el problema y no tener que gastarse un montòn de tiempo y dinero en algo que podrìa ser automàtico, o aùn mejor, no saber que existe el problema, porque està solucionado y escondido. Hay que encontrar un balance entre lo que quiere el cliente y lo que es > mejor en realidad para el, porque después si se va a quejar cuando quiera un > botón con animación 3D adentro y se pueda hacer porque es smalltalk pero se > tarde 1 semana. > No entendi la analogìa, pero si vamos detràs del cliente como si fuèramos modistos, creo que estamos condenados a entregar productos de baja calidad, porque entender lo que el cliente quiere toma el 90% del tiempo. Luego màs encima, la plataforma cambia o desaparece, lo que significa que estaremos en constante movimiento tratando de entender sobre lo que estamos parados, sin lograr ventajas competitivas nunca. En realidad creo que es mucho mejor sacar productos estàndares sobre los que otros puedan hacer sus consultorìas, de modo que sean otros los que se desgasten con el cliente, que tengan que aprender cómo cambia nuestra plataforma, etc. Si al final los màs ricos del mundo no hacen consultorìas... > > > >Uno podría pensar que todas las clases podrían estar en un repositorio en > la web, de modo que si falta >una >clase, podría bajarse on the fly y > podrían existir mecanismos de conversión de una versión a otra, >pero en > >realidad algo extraño de Smalltalk es que todas las clases están > relacionadas, y si tocas algo >acá se afecta >algo allá, lo que está > documentado hasta en el libro original que describe Smalltalk (blue > >book???). Dice "mira >puedo modificar la clase array" y muestra a un tipo > jugando con cubos de >madera, sacando un ubo y haciendo >que su pirámide se > caiga, es decir, exactamente lo mismo que >dijo Alan en su presnetación "no > construyamos >pirámides, sino catedrales". Se modifica Array y >Smalltalk > deja de funcionar. Me parece que esa es una fuerte >razón para no usar > Smalltalk. > > A mi me parece una fuerte razón para si usarlo. > Osea, smalltalk es un cañon y tan flexible que lo podes usar para matar > tanto mosquitos como elefantes. > Pero como toda arma puede usarse bien o mal. > Pero para proyectos grandes (con mucha gente), es un peligro. Incluso Java es un peligro. Ni hablar de C++ y C#. Por eso apareció J2EE, que es la versión para retrasados mentales de Java, donde no te dejan ni abrir un archivo ni usar threads, para gente que piensa que Java es "difícil". Por algo es así. Conozco sistemas hechos en smalltalk que funcionan hace mas de 10 años con > mucho usuarios y siguen funcionando, y nadie modifico Array, por algo > sera...... > ¿Quizás no saben que se puede o les falta imaginación? Lo que pasa es que estamos acostumbrados a que los "gigantes" del soft > (M$, IBM, etc) nos den herramientas que nos dicen QUE podemos hacer y que > no y como, sin darnos libertad. > Fíjate que para una empresa es una ventaja que los programadores no puedan destruir lo que se construyò. De hecho si tuvieras alguna manera de que no se necesitaran màs programadores, serìas el hombre màs rico del mundo. ¿Què costarà ponerle permisos a Smalltalk? No creo que màs de una semana. De hecho el mismo Alan Kay menciona que en media página de código se puede implementar un intèrprete de Lisp, y eso gracias a que Lisp es un metalenguaje. Habla además de que Squeak lo implementó en 2 semanas. Acá hay un ejemplo similar de Lisp implementado en Awk: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/awk/0.html Saludos, Guillermo. --~--~---------~--~----~------------~-------~--~----~ Has recibido este mensaje porque estás suscrito a Grupo "clubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envía un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups.google.com/group/clubSmalltalk?hl=es. -~----------~----~----~----~------~----~------~--~---
