On 3/28/07, Marcelo Cortez <[EMAIL PROTECTED]> wrote: > > Hola guillermo,gente > > > > On 3/28/07, Guillermo Schwarz <[EMAIL PROTECTED]> wrote: > > Juan, > > > > Estoy de acuerdo con que GNU Smalltalk es mejor para empezar porque > permite > > aprender el lenguaje sin necesidad de aprendera usar la GUI. > > Creo que GNU esta bastante poco mantenido ademas de que no crecio > historicamente > creo que eso le paso a todo lo GNU ; se lo trago linux ( hace poco vi > un documental contando esto )
Por eso la gente de GNU quiere que se llame "GNU/Linux", ojalà Linux con un font màs chico que GNU, ya que de esa manera pueden en unos 5 años botar el nombre Linux. La explicación de Stallman es que Linux es sólo el kernel, pero todo el resto es GNU, lo cual claro que tiene razón, sin embargo sospecho que RedHat Linux no va a llamarse RedHat GNU, al menos no en un futuro cercano, porque el propósito de RedHat es ganar dinero, y es difícil hacer eso si promocionas tus productos como "no <algo>", que es el caso de lo que significa la sigla GNU. El hecho de que estè poco mantenido implica que es estable, por lo que creo que es ideal para que alguien que no sabe nada de Smalltalk ingrese al mundo de Smalltalk. > > Creo que Java es un pobre copia de smalltalk ,y rapidamente o > lentamente esto tiende a revertirse , Java y casi todos los otros > lenguajes tienden asintoticamente a smalltalk Eso es verdad para el 98% de los lenguajes comerciales, pero en el caso de SML y Haskell es al revés. Recuerdo que alguna vez propuse como memoria de tìtulo crear un Prolog en Smalltalk. Bàsicamente es interesante porque tendrìas acceso a un Prolog embedido en Smalltalk. Me dijeron "ok, pero hazlo en Java." ¡PLOP! > > > Por ese lado Java les lleva la delantera. No importa lo que dice Alan > Kay en > > su presentación de 1997 "The computer revolution hasn't happened yet". > Es > Creo que tiene razon , hoy en dia es "maravilloso y nuevo" lo que hace > 30 años era > innovador > > > cierto que la internet puede crecer de manera orgánica sin necesidad que > la > > bajen, es cierto que puede evolucionar sin tener periodos sin servicio, > > porque el sistema se autodocumenta. Pero fíjate que en Smalltalk aún no > > aprendemos a hacer eso. Creamos un programa y automáticamente cambiamos > de > > versión de Smalltalk y deja de funcionar, porque el programa es incapaz > de > > contener todo lo que se necesita (es incapaz de presentar ante un nuevo > > runtime y decir cuáles son las clases que le faltan). > El cambio de version no afecta a ningun smalltalker medianamente > avezado en smalltak ( valga la redundancia) Pero el punto està en que necesitas al programador => no escala. Es como si para instalar Windows necesitara al lado a Bill Gates. Gates serìa el hombre màs pobre del mundo ;-) Se requiere que los sistemas "no molesten", en el sentido de que no requieran mantenciòn o requieran el mìnimo de mantenciòn. Pero por alguna razòn esa lògica no la siguen, sino todo lo contrario, como si el hecho de que te necesiten hasta para estornudar fuera una buena estrategia comercial. A esa estrategia le llamo "pan para hoy y hambre para mañana". > > > 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. > > > > > Alan defiende el hecho de que debemos tener metaprotocolos y por lo > tanto el > > programa debe poder referirse a sí mismo, en otras palabras, uno siempre > > debe poder modificar array, pero eso implica que necesariamente alguien > > modificará array y mi sistema dejará de funcionar. Claramente es no es > lo > > que queremos, a menos que pensemos que se puede estar constantemente > tapando > > los hoyos que hacen otros porque son descuidados. Admito que de vez en > > cuando hace bien poder hacer y desahacer, porque ayuda a pensar, pero > cuando > > queremos terminar el sistema, tenemos que tener algún nivel de control > de lo > > que se está haciendo, alguna manera de evitar que alguien modifique lo > que > > array significa. Si no es que el compilador tiene en duro lo que es un > > array, entonces que hayan tests unitarios que prohiban que alguien > desarme > > el sistema, o al menos que haya una página web señalando al culpable, > como > > con luntbuild > No menos teniendo proyectos andando como exupery ( un compilador de > methodos para > lenguaje maquina) o sea los compiled methods corriendo en assembler. > Claro todo esto debido al poder de abstraccion y reflexion *verdadera > que tiene smalltalk ¡Què interesante! Debe ser lo mismo GCJ, el compilador de Java para Linux. Està demàs decir que no ejecuta màs ràpido que HotSpot, que es la misma tecnologìa que utiliza VisualWorks para compilar los mètodos màs ejecutados a còdigo de màquina, pero que lo hace el interprete de Smalltalk durante la ejecuciòn. Eso le da acceso a optimizaciones que no tienen lso compiladores como GCJ. De hecho los fabricantes de compiladores de C se defenden diciendo que no tienen acceso a tanta informaciòn como el HotSpot y por lo tanto no puede hacer las optimizaciones que hace HotSpot. En otras palabras, los siguientes comiladores de C debieran correr sobre la màquina virtual de Java!!! . > > > > Voilviendo al tema de los Smalltalks, Smalltalk Express era > impresionante, > > espcialmente Window Builder que no eran más que 20 KB de Smalltalk y > hacía > > lo mismo que Visual Basic para pintar pantallas, pero bien y con código > No creo que lo mismo que VB porque el windows builder es un framework > de gui dinamica. El asunto es que todo lo que podìas hacer en VB se podìa hacer en Smalltalk y màs encima tenìas acceso al còdigo fuente. Es decir podìas hacer tus propias mejoras, en case de necesitarlo. > fuente. Impresionante!!!! Qué lástima que Smalltalk Express ya no corre > en > > estas máquinas. > A noo?, ( acabo de hacer la prueba ) debido a tus comenarios ver attach > Mi maquina es una AMD 64 bits corriendo XP SP2 > o te referias a otra maquina ? porque correr corre. Tengo entendido que no acepta màs de 256 colores y se cae con access violation. saludos > MDC > > > * Java tiene reflexion parcial ( a no desesperar pronto copiara > tambien a smalltalk) > pd: el mercado pide java se labura en java pero a no enganiarse no > significa que sea mejor > Java nacio como una copia de smalltalk porque fueron a pedir smalltalk > pero era caro asi que lo hicieron ellos asi nacio Java. Efectivamente, Sun querìa licenciar Smalltalk para crear el equivalente a lo que hoy es Jini. "Ok, las licenicas son 5.000 dòlares", multiplicado por 1.000 desarrolladores era una pequeña fortuna, desarollaron Oak, que luego se llamó Java. ¿Quièn dice que reinventar la rueda no es negocio? --~--~---------~--~----~------------~-------~--~----~ 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. -~----------~----~----~----~------~----~------~--~---
