On 8/14/07, Guillermo Schwarz <[EMAIL PROTECTED]> wrote: > > > > On 8/14/07, Alberto Torres Foltyn <[EMAIL PROTECTED]> wrote: > > > > Portar un smalltalk, algo puro de objetos, a java??! que > > caracteristicas son mas deseables de java? el sistema de tipos > > incompleto? o la velocidad?. > > > JA JA JA > > Comparto tu desprecio por Java, pero uno tiene que comer... ;-) > > En todo caso la mayoría de los Smalltalks están implementados en C que es > aún peor.
¿Aun peor? ehhhmmm... me parece que decir que C sea peor que java es una aberracion. Mientras que el primero es un lenguaje con trayectoria(30 años!), realmente portable, desde el pdp hasta ahora(practicamente), si mal no recuerdo; java no. En mas de una oportunidad trabaje con java con windows y aix consumiendo webservices, pero sin usar mi aplicacion en un application server, sino como stand alone y java... no fue de lo mejor. Por otra parte, podemos mencionar las implementaciones mediocres que tiene del mvc no tienen elegancia en su mayoria. En fin, no hare leña del arbol caido. Solo me parece que no podemos comparar a la ligera a C, que corre eficientemente en un pic, una palm, o lo que fuera... con java... que "corre" "eficientemente" en una palm, pero cuando usamos azureus, eclipse, u otra aplicacion sobre una maquina con nada menos 256 megas de memoria!!!!... flaquea... es decir en trayectoria, recursos, etc... c no puede compararse con java, por lo superior. La dificultad de mantener proyectos en C fue atenuada minimamente con C++ decir que C++ no existe en el mercado es ignorar el mercado de los juegos y el mercado de las telecomunicaciones donde, casualmente tambien trabaje y me topé, oh casualidad, con una aplicacion de mediacion telefonica que interactuaba entre aix y windows todo implementado en c++. > > Personalmente opino y he visto Little > > Smalltalk es un experimento, una "demostracion" de lo facil que es > > implementar un Smalltalk y no mas que eso, no tiene intenciones serias > > de ser un smalltalk. > > > Es cierto que no es un Smalltalk completo, pero ¿qué parte le falta en > realidad? > > ¿Hay algo que no sea implementable? > > Eso de que es "un juguete" me parece más un halago que un insulto, porque es > lo mismo que los programadores en C++ decían de Smalltalk 10 años atrás y > hoy en día C++ casi ha desaparecido del mapa. > > > > Por otra parte JAVA no necesariamente es > > portable, cualquiera que lo haya usado seriamente sabe que JAVA tiene > > problemitas de deploy > > > ¿Es broma? Java es portable siempre y cuando se use sólo el código 100% Java > y que se sabe que es compatible. En particular lo que no es compatible son > los threads (los que nadie debería programar directamente, así como tampoco > nadie debe programar en assembler), como así también los EJBs que dependen > del app server, pero se puede crear una capa de abstracción para evitar esos > problemas. Con el problema de los Threads no me enfrente por suerte, sin embargo me he tenido que enfrentar con el deploy de 2500000 librerias para ponera a andar un hola mundo con 3 "frameworks"...lo de que nadie deberia programar directamente con threads es otro thread de discusion... y lo del assembler... es interesante tambien tu punto de vista... con respecto a los EJB, etc me estas contando que "se puede crear..." entonces... estoy "añadiendo trabajo"... bueno, ahi esta el punto... muchas veces tenes que añadir trabajo para que todo ande de una. > > (bueno, la velocidad de java es otro tema > > tambien, y su gc es penoso). > > > Nunca he visto una aplicación Java que funcione mal, seguramente probaste > las primeras versiones que interpretaban el bytecode, pero hoy en día Java > es comparable a C, y a veces gana. Aunque hayq ue reconocer que la > tecnología HotSpot la copió de Smalltalk. Lo de comparativas entre java y c... si hablas de performance seguro que sabes que java no tiene que hacer al lado de c. Si hablamos de tiempos de desarrollo seguramente java sea mas rapido. La copia de HotSpot, por otro lado es un pequeño paso a favor de java... aprendio a reconocer de una cosa buena y la incorporo a su "avanzada tecnologia". > Respecto del GC, nunca he visto que se demore nada. ¿Tú sí? Bueno... si no es el GC no se que sera, en general una app stand alone en java en una pc hace desastres, fuere cual fuere el equipo (mi tope fue un turion 64 mt 37 con 2 gb de ram). > > > Para evitar el "problema de la diversidad e incompatibilidad" se > > puede definir un estandar, ya existe, pero lo que no hace el estandad > > es abarcar algunas cosas que, al no estar especificamente definidas, > > cada uno implementa a su gusto y placer. Creo que con rever el > > estandar alcanzaria. > > > > ¿Cuál es el punto? El punto es que con hacer Smalltalk Open Source, no vas a deshacerte de la diversidad de Smalltalks. > Nuestro equipo desarrolla en Windows y Jonas y nos llevamos esta aplicación > a AIX y WAS y funciona de manera idéntica. Nunca hemos tenido un problema. > > > Recordemos que si bien linux es GNU tiene el > > problema de que muchos binarios corren bien en ciertas distribuciones, > > mas no en otras. > > > Linux usa C. C nunca ha sido portable entre plataformas. Ni siquiera C para > UNIX, ni C para POSIX. > > C es una desgracia, pero ha sido reverenciado por demasiado tiempo. Hoy Java > le está pegando mil patadas en el trasero. A esto ultimo no me queda mucho mas que reirme... todos los sistemas operativos, que conozco salvo uno o dos, estan hechos en C... y java es un trasero, no creo que pueda pegarle a nadie nada... se lo usa por un impulso comercial de la gente de sun e ibm porque los "innovadores" de ahi "descubrieron" el gc y los ide... bueno... si... java es lo mas... de zamora... > Smalltalk también podría si fuera standard. Creo la manera más fácil de > hacerlo es implementar Smalltalk sobre Java, porque Java tiene un problema > que es terrible, y es que el proceso de edición, compilación, > empaquetamiento, deploy, desempaquetamiento, volver a hacer login para > llegar a donde mismo estabas para volver a probar si arreglaste el problema > está bien cuando una aplicación tiene 30 pantallas, pero cuando tiene 300 no > terminas nunca de estabilizar el sistema. Con esto del problema del deploy me estas dando la razon de los mails anteriores y otra respuesta anterior... y smalltalk implementado en java suena tan loco como implementar el motor de vapor... peeero calentando el agua con la corriente alterna que llega por las lineas electricas... > Smalltalk podría tomarse el mercado por sorpresa. > > > Esto indica que la "solucion" de hacerlo GNU no es, > > por lo menos a mi criterio, una autentica solucion (esto no quiere > > decir que este en contra del movimiento GNU, sino que no aplica como > > una solucion a este caso). > > > Hacerlo GPL serviría para eliminar la competencia. Eso es importante, ya que > pasaría lo mismo que con MySql, que se come a todas las bases de datos > existentes porque tiene los mismso features, es más estable y cuesta cero. > > > Los que usamos dolphin alguna vez seguimos lamentando la > > descontinuacion de este excelente producto. > > > Bueno cuando se les pase el luto (y la sorpresa de algo que era obvio), > miremos el futuro. Si Java es capaz de montarse a Smalltalk es porque Java > es gratuito. Es muhco más inteligente asumir que Java ganó y montarse encima > de Java. Java es el futuro... tinelli tambien... y otros productos de semejante talla lo son... si pensamos en un futuro apuntemos un poquito mas alto... pensando con inteligencia y no siguiendo "rebaños" ... > 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. -~----------~----~----~----~------~----~------~--~---
