Mariano, Te felicito por tu motivación. Creo que te servirá para aprender mucho. Te recomiendo que lo hagas sólo o en un grupo pequeño, así por lo menos lo hice yo y aprendí mucho. En grupos grandes es difícil aprender.
Sin ánimo de tirar a matar ;-D 2008/6/2 Mariano Abel Coca <[EMAIL PROTECTED]>: > 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). En realidad los threads nativos son una mala idea. Las tareas (tasks) en Smalltalk son mucho màs limpias porque no se ponen a ejecutar a menos que les des la pasada (yield). Al menos conozco un profesor universitario que prefiere este modelo de multitasking que los threads de Java (ya sean green o black) y tiene su propia biblioteca de tasks en Java para programar más decentemente y con más desempeño (en mi escuela de ingeniería están todos obsesionados con el desempeño). Yo estoy en un punto opuesto a todo lo anterior: Olvìdate de los threads y deja que el sistema los maneje por ti (a la EJB y como lo hacen las bases de datos). En realidad todo sistema que estè programado linealmente es màs simple que un sistema con multitareas y por lo tanto tiene más oportunidades de optimización (sin mencionar que es más fácil probar que no tienen bugs). Programar con threads es difícil, y es muy fácil agarrar un programa que estaba funcionando y echarlo a perder. Pedirle a todos los programadores que sepan threads antes de tocar un programa es poco razonable y va contra la intuición, ya que cada día entra más gente a programar y cada vez tienen menos tiempo de aprender. Por ende, lo razonable es evitar la programación con threads completamente y desarrollar un core pequeño que lo maneje bien, realizando todas la optimizaciones que se te ocurran. Lo más chistoso es que si divides las responsabilidades de manera adecuada, los sistemas se simplifican y esto es especialmente verdad cuando se trata de threads. > > > 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? ¿Para quién? A menos que tengas un ejemplo de algo que no se pueda hacer con el resto y sean 5 lìneas de Smalltalk, nadie lo va a comprar. En general las soluciones hoy en día tienen demasiado código y hacen muy poco. Supongo que el principal problema es que hay demasiados programadores principiantes que piensan "más código es mejor" y hacen copy and paste como enfermos, de manera descuidada, y ahí es dónde Smalltalk no les ayuda. Ahora fíjate que eso es uan ventaja a la hora de programar en Smalltalk, porque sólo aquellos que son cuidadosos pueden entrar, al encontrarse con un lenguaje simple, son más productivos. Pero aún así ese "baggage" (pesada carga) de pensar que todo tiene que estar "pesadamente optimizado" y con "muchos threads nativos para poder utilizar los multicores" sólo los confunde. Unos de los tipos de XP (creo que fue Jeffries) decía que el sistema primero debe funcionar, luego el ´codigo debe poder leerse y finalmente el código debe correr suficientemente rápido. En otras palabras: optimisa al final. Si no necesitas threads, no los uses. Asegúrate que el sistema funciona 100% de acuerdo a las especificaciones (usando pruebas unitarias), asegúrate que el código se entienda y sea modificable y finalmente realiza pruebas de desempeño para ver si funciona adecuadamente. Según este tipo casi nunca necesita optimizar y debo reconocer que es verdad, los sistemas desarrollados de esta manera generalmente son tan rápidos que sorprenden a todos y a mí me pasa que aún me sorprendo. Y en los casos que se necesita optimizar, acá me aparto de las prácticas de XP, siempre prefiero optimizar a nivel de las bibliotecas. ¿Porqué? Si lo haces a nivel funcional, le estás pasando el problema al desarrollador, que se tiene que preocupar de la parte funcional, de modo que se confunde resolver el problema de negocio con las optmizaciones que está haciendo. Luego cambian las reglas de negocio (o el desarollador entendíó mal) y las optimizaciones hay aque deshacerlas y rehacerlas con una estrategia diferente, pero están repartidas por todo el código y se empieza a escuchar los "no se puede". Si las optmizaciones están en las bibliotecas, las puedo hacer pasar por las pruebas unitarias y saber que no dependen de alguna regla de negocio que probablemente esté mal o cambie. Esto pasa todo el tiempo, de modo que la aplicación no debe saber de optmizaciones y las bibliotecas deben incorporar las optmizaciones de manera que sean genéricas y aplicables a una amplia gama de problemas. > 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? El browser no interpreta jsp. No veo la necesidad de hacer que el código Smalltalk funcione sobre Apache y Tomcat, pero si tú piensas que es bueno, hazlo, en una de esas sí es interesante. A mí me parece más interesante que Smalltalk funcione sobre Java, porque de esa manera Smalltalk funcionaría sobre cualquier plataforma que funcione Java de modo "bit identical". Este Smalltalk sobre Java es un invento de Tim Budd, el creador de Little Smalltalk: http://web.engr.oregonstate.edu/~budd/SmallWorld/ReadMe.html > > > 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. :) Creo que vas bien encaminado. Saludos, Guillermo. > > > > 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. > > > > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect --~--~---------~--~----~------------~-------~--~----~ 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. -~----------~----~----~----~------~----~------~--~---
