Creo que la gran carencia que sigue teniendo smalltalk es la de no utilizar threads nativos del sistema operativo (si los utiliza disculpen mi ignorancia e ilústrenme amablemente, no me tiren con nada).
Si estoy en lo cierto, entonces sigan leyendo. A lo que voy es que si pudiera generar un stack overflow en un debugger y que no se me cuelgue la imagen entera, sólo el debugger... Si, ya se, está el paquete de Stack Overflow en VW o el "interrupt excecution" en VAST... Pero siguen siendo "parches" feos para salir del paso sin solucionar el problema de raíz. Y les guste o no, conozco a más de un programador que por ese simple problema, no se dedica a realizar ninguna aplicación comercial "seria" (citando textualmente sus palabras) en Smalltalk (por otro lado, hay muchos ejemplos en el mercado que contradicen esto y lo podrían tildar de ignorante demostando que es posible, pero siguen sin solucionar el problema de fondo). También están las soluciones a no colgar la imagen con un i/o, generando éstos en un thread independiente. Pero es simplemente un parche más a un problema secundario generado por otro más de fondo, nuevamente, sin solucionarlo. Las computadoras están tendiendo, desde hace ya varios años, a tener procesadores de varios núcleos, y no cada vez más rápidos. Con lo cual Smalltalk va a comenzar a perder cada vez más pérformance en comparación con otras soluciones del mercado. En mi opinión, Smalltalk trae muchos más beneficios aparejados ante cualquier otra tecnología, y ese es simplemente un "mal necesario"... Pero es una pena que deba serlo... Lo cierto es que Smalltalk hace tiempo pudo haber desarrollado una VM que utilice threads nativos, pero no vi a ninguna empresa desesperándose por hacerlo... Digamos que, siendo que smalltalk existe hace muchos años, pudo haberse anticipado... O, ni bien se habló de dual core, intentado ponerse al día sabiendo que tarde o temprano lo iba a tener que hacer... Por favor, no me malinterpreten, no soy defensor ni de java, ni de .net ni nada por el estilo. Es más, trabajo desarrollando en smalltalk porque es lo que me apasiona y pienso que es así como se debería trabajar, creo que la vida sería más sencilla sin tanta basura dando vueltas... Pero me enfrento día a día a situaciones que podrían mejorarse y que tal vez desde la comunidad open source lleva muchísimo tiempo el cambio, y provoca que smalltalk pierda terreno contra las soluciones "alternativas" que ofrece el mercado. A modo de nota anecdótica y para simplemente dejar volar la imaginación: En cuanto al GNUSmalltalk, si la forma de desarrollar con scripting pudiera reemplazar al javaScript o php, no sería algo maravilloso? Hay veces en que se quieren desarrollar páginas web sin tener un servidor smalltalk detrás, simplemente un par de formularios... Eso se puede hacer con smalltalk?, únicamente con smalltalk? además, no debería tarde o temprano traducirse a jsp/htm/etc... para que lo interprete un browser? Hasta ahí con mi pensamiento. Repito, si estoy muy equivocado conténganse y no tiren a matar. Soy humano y obviamente no lo se todo. :) 2008/6/2 Gabriel <[EMAIL PROTECTED]>: > Si, jeje, y ademas: > - una sintaxis muchisimo mas clara e intuitiva. > - una imagen y un metamodelo modelado en el mismo ambiente lo que implica > utilizar verdadera reflexion (y no la bosta que llaman reflexion en java). > - tipado dinamico. > - pureza en el paradigma, java arrastra mil cosas de la programacion > procedural: estructuras de control, tipos nativos, etc. > > Totalmente de acuerdo con eso Gabriel :) Un abrazo! > > > 2008/6/2 Esteban Lorenzano <[EMAIL PROTECTED]>: > > Hay otra cosa que tiene smalltalk (y no solo smalltalk) y no tiene java, y >> para mi es mucho más importante que eso que vos decís: Late binding >> El 02/06/2008, a las 4:00p.m., Guillermo Schwarz escribió: >> >> Creo que lo que están confundiendo es quién tiene la mejor tecnología (en >> el sentido de tecnología más avanzada) y quién tiene mejor marketing. Si >> tienes la mejor tecnología pero tus clientes potenciales no lo saben, >> entonces no tendrás una buena cuota del mercado. >> >> En el caso de Xerox, tenían productos de 5000 USD, como la Xerox Alto, y >> como era demasiado lento, desidieron perder el tiempo portando el ambiente >> Smalltalk a Mesa que es el precursor de Object Pascal, ya que suponían que >> reimplementándolo en un lenguaje con tipos estáticos el programa ejecutaría >> más rápido, lo que se logró después de varios años (Alan Kay decía que si >> hubieran dedicado el mismo tiempo a mejorar Smalltalk lo hubieran logrado >> antes). >> >> Steve Jobs se dio cuenta que podrían reimplementar el mismo ambiente en >> una máquina más pequeña y se llevó a un par de ingenieros de Parc para crear >> el Apple Lisa. En otras palabras, no basta con tener la mejor tecnología, >> hay que saber qué precio están los consumidores dispuestos a pagar, inundar >> el mercado con tus productos e influir en los líderes de opinión (ahí es >> donde entra el marketing). >> >> El caso más revelador probablemente es el caso de Microsoft. Le vendió a >> IBM el sistema operativo DOS que era un clon de CP/M que había sido >> inventado por Gary Kildall, pero Gary se mostró arrogante con IBM y por eso >> IBM prefirió hacer trato con Microsoft (por cierto Bill Gates retuvo el >> derecho de vender DOS por su cuenta, lo cual significa que también era >> arrogante). >> >> ¿Porqué Kildall fracasó y Gates tuvo éxito? >> >> Creo que la razón es que a los ojos de los ejecutivos de IBM, Gates no era >> una amenaza, ya que obviamente su producto era simplemente un clon, debía >> ser peor y por lo tanto de esa manera lo "mantendrían controlado". >> >> Y así fue durante un buen tiempo, hasta que Microsoft sacó Windows 3.0, y >> luego empeoró cuando el proyecto OS/2 se dividió en Windows NT y OS/2. >> >> ¿Vemos que IBm siga haciendo tratos con Microsoft? >> >> De hecho MIcrosoft se quedó sola con .NET, mientras que IBM se alió con >> Sun, Oracle y BEA para competir contra .NET usando Java (aunque >> históricamente se dio al revés). >> >> Si fuera por la tecnología más fácil y más capaz, todos estarían usando >> Smalltalk en vez de Java y .NET, es cosa de mirar como está hecho >> WindowBuilder. >> >> ¿Porqué eligen Java y .NET a Smalltalk? >> >> En el caso de las empresas las decisiones en este momento son copia de las >> deciones de otras, pero inicialmente: >> >> 1. Hay un tema de quién controla la tecnología. ¿Hay empresas con fuertes >> recursos financieros detrás? >> 2. Hay empresas de prestigio detrás. Si fallas, por lo menos ten una >> disculpa. >> 3. Las empresas que respaldan esta tecnología, ¿tienen alguna manera de >> asegurarse del system lock-in? Si no, el negocio puede significar para ellos >> una pérdida. >> 4. ¿Hay sufientes profesionales entrenados en este tecnología? >> >> Smalltalk falla en todas las anteriores. >> >> Algo que me parece que ayuda a Smalltalk es que cada tecnología nueva que >> aparece se aproxima más a Smalltalk. Por el momento lo ùnico que hace >> diferente a Smalltalk de Java es el ambiente interactivo y los bloques. Una >> vez que aparezca un lenguaje parecido a Java pero con bloques e interactivo, >> nadie tendrà algùn pretexto para seguir usando Smalltalk. >> >> Saludos, >> Guillermo. >> 2008/5/31 Andres Valloud <[EMAIL PROTECTED]>: >> >>> > no alcanza con solo SER LOS MEJORES. >>> >>> Tal cual. Es mas... eso que lo digan los otros. Mientras tanto, mas >>> alla de lo que se escuche o no, hay que hacer lo mejor posible todo el >>> tiempo. Por lo menos para mi, las exigencias mas importantes siempre son >>> las propias. >>> >>> Andres. >>> >>> 2008/5/31 Gustavo Ibarra <[EMAIL PROTECTED]>: >>> >>> gracias por la respuesta! >>>> >>>> Buena pregunta. >>>>> >>>>> Un artista cumple varios roles en un equipo de desarrollo. Dibuja >>>>> íconos, diseña la disposición de elementos en pantalla, etc. Además >>>>> ilustra los documentos que escriben los technical writers, el help, >>>>> dibuja storyboards para mostrar avances de nuevas funcionalidades. En >>>>> nuestro caso, además de diseñar y dibujar, prepara material fílmico, >>>>> como por ejemplo películas con cursos para nuevos programadores, >>>>> demos, etc. Eso, claro está, no lo hace sólo sino con la ayuda de un >>>>> director de cine, iluminadores, etc. En todo caso, las consideraciones >>>>> estéticas están bajo su responsabilidad. Te diría que el rol del >>>>> artista es super amplio, aún cuando dejes de lado tareas más >>>>> tradicionales como las de marketing o la web. >>>>> >>>> >>>> supongo, no debe ser los mismo trabajar en una empresa que define el rol >>>> de documentador, en aquella que define el rol de artista. Con suerte (1 >>>> sola!), en las empresas que participe tenian en el equipo documentadores, >>>> por eso lo de supongo. sutil diferencia, que marca entre otras cosas, cuan >>>> bien se quiere desarrollar los productos ....potenciado con desarrolladores >>>> smalltalkers, rodeado de directores de cine, iluminadores y pochoclos, se >>>> ve >>>> la verdadera filosofia de la empresa, y no morir en un panfleto marketinero >>>> ( como un delivery de empanadas) subido al sitio corporativo >>>> >>>> por el tema en discusion que se armo, quiero decir que: >>>> para llegar al publico con esa historieta de la masividad o >>>> reconocimiento popular, y estar "en la boca todos", pudiendo salir del >>>> gueto de todos los dias para jugar en otras calles con nuevas caras, no >>>> alcanza con solo SER LOS MEJORES. >>>> >>>> Saludos, >>>> Gustavo.- >>>> >>>> >>>> >>> >>> >>> >> >> >> -- >> Saludos cordiales, >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> >> >> >> "Querer es suscitar las paradojas" >> Camus - El mito de Sísifo >> >> >> > > > > > -- Mariano. --~--~---------~--~----~------------~-------~--~----~ 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. -~----------~----~----~----~------~----~------~--~---
