On 8/14/07, Alberto Torres Foltyn <[EMAIL PROTECTED]> wrote: > > 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.
Probablemente no se dieron cuenta, pero el compilador de Java de IBM genera código que no es compatible con la JVM de Sun. No sé si el problema son las clases que compila, las que linkea o qué, pero siempre hay que obtener el fuente y recompilar para la VM en la que vas a correr. Una manera de evitar este problema es siempre usar la JVM target. <es decir si vas a correr en IBM, compilas con IBM, etc. Lo otro es siempre usar el compilador y la JVM de Sun, si al fin y al cabo es la que corre mejor. BEA siempre publica que tiene la más rápida, pero no alcanza a ser ni un 20% más rápida de modo que me parece irrelevante. Digo si ya resuelves 5 mil transacciones por segundo, para qué quieres 6 mil??? > Por otra parte, > podemos mencionar las implementaciones mediocres que tiene del mvc no > tienen elegancia en su mayoria. Te apoyo, pero nótese que yo hablaba de correr Smalltalk sobre la JVM, de modo que nunca verías la implementación de MVC en Java... No ha lugar... > 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... La compatibilidad a nivel de fuentes en C no existe. Te cambias de sistema operativo y deja de funcionar. Has visto el software GNU? Los tipos se esfuerzan por hacer que el software GNU sea compatible a nivel de fuentes en todos los sabores y versiones de UNIX, pero tienen la media capa de abstracción y realmente es un enredo. Muy inteligente, pero sigue siendo un enredo. Necesitas un CI de 500 para hacer un sólo programa que sea GNU y unos cuantos años perdidos construyéndolo. Mientras que haces lo mismo en Java y funciona al tiro, cero esfuerzo. Es un tema de enfoque superior. > 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... No sé cual es el problema de Eclipse pero realmente se queda pegado. Asumo que el problema es que están preocupados más de agregarle features que de escribir código limpio. Eso te lleva rápidamente a un límite de cuánto código es capaz de correr simlutáneamente. Es una pena, pero Eclipse lleva mucho tiempo sin avances relevantes, y estoy seguro que se debe a que los tipos no saben programar (puro copy paste). Echarle la culpa a Java porque Eclipse es un producto mediocre es exactamente lo mismo que pasó a principios de los noventa con C++. Hubo montones de empresas con proyectos en C++. El 90% fracasó en menos de un año, porque el enfoque que tienen siempre es hacer copy & paste. Eso no funciona ni en Smalltalk. > c no puede compararse con java, por lo superior. La dificultad de > mantener proyectos en C fue atenuada minimamente con C++ Qué dolor. Tratar de programar orientado a objetos usando un C mejorado llamado C++ es como tratar de crear un pulpo poniéndole 4 patas adicionales a un perro. decir que C++ > no existe en el mercado es ignorar el mercado de los juegos y el > mercado de las telecomunicaciones Lo lamento, pero C++ ya está en retirada. Hay gente que se da cuenta antes y gente a la que le toma un par de décadas darse cuenta. Yo me di cuenta el 2001, y te aseguro que me siento mucho mejor ahora. Es increíble la cantidad de código inmantenible que se escribe en C++. Estoy seguro que el mundo estaría mucho mejor si Stroupstrup nunca hubiera creado C++. Ahora estaríamos usando Objective C y Smalltalk en vez de sus primos menores C++ y Java. 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++. Sí, yo hice una. No me siento orgulloso de eso, pero me titulé con el temita. > > 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"... Los frameworks en Java son asquerosos. De partida te piden montones de librerías como dices tú, y además asumen que quieres poner todo en duro, escribir 5 archivos para sólo poner una página web. Por eso lo primero que hago en mis proyectos es sacar toda esa mugre y poner mis porpios frameworks. ;-D Esa técnica la aprendí en C++: Mete todo el código en bibliotecas y así elimina todo el código repetido. Esconde los frameworks que usas en tus bibliotecas, de modo que sólo expreses lo que quieres hacer en tu programa, el cómo queda en las bibliotecas. Funciona de las mil maravillas, aunque al principio es un poco lento, con el tiempo pudimos construir hasta 7 caso de uso al día, lo que representa 140 casos de uso al mes. Si. ya sé que todos sabemos multiplicar, lo interesante es que con un equipo relativamente pequeño se puede construir aplicaciones gigantes y que funcionan más rápido que lo normal. Imagina lo que podrías hacer con tu software factory de 200 personas... 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... En realidad es lo mismo. Si todos trabajan a bajo nivel, adiós proyecto. Algunos tienen qu ededicarse a construir bibliotecas (y probarlas) y unos pocos a construir la aplicación con el mínimo de líneas. Las optimizaciones por ejemplo, se hacen todas a nivel de bibliotecas. Usando la filosofía de XP, todas las optimizaciones se hacen al final, y sólo en caso de ser encesarias. Desde el 2005 no he optimizado durante más de 10 minutos. Es más durante este año no he optimizado nada. Sale eficiente al tiro sin siquiera haber diseñado una solución óptima. El cliente no sabe qué hicimos pero no puede creer lo rápido que funciona. con respecto a los EJB, etc me estas contando que "se puede > crear..." entonces... estoy "añadiendo trabajo"... Se hizo en apenas 2 semanas y nos ahorramos 2 tercios del proyecto, porque nunca nadie más escribió un EJB. bueno, ahi esta el > punto... muchas veces tenes que añadir trabajo para que todo ande de > una. Creo que eso de "añadir trabajo" no es un criterio que te sirva para saber cuando aplicarlo y cuando no. La regla que aplico es que no debemos enredarnos en tecnologías, sino que debemos esconderlas dentro de bibilotecas, así usamos de la tecnología lo justo y necesario. El resto se puede obviar. > > (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. http://www.idiom.com/~zilla/Computer/javaCbenchmark.html http://www.kano.net/javabench/ La principal ventaja es que los proyectos en Java terminan en un décimo del tiempo en que terminan los proyectos en C++, básicamente porque: 1. Un ingeniero Java con 6 meses de entrenamiento es tan competente com un ingeniero C++ con 3 años de entrenamiento. 2. Java no requiere que corrijas los defectos en el manejo de la memoria. 3. Java tiene una sintazis más simple. 4. Existen más bibliotecas en Java. 5. Java compila más rápido. 6. Mediante los proxies en Java puedes ahorrarte mucho código inutil que en C++ no puedes evitar. 7. En Java existe las collections que son estándares, mientras que en C++ existe STL que es fácil de escribir pero imposible de debuggear. 8. Los problemas de classpath en Java son demasiados simples comparados con los problemas de linkeo en C++. 9. Compilar un proyecto grande en Java toma un décimo del tiempo del que toma compilar un proyecto similar en C++. De las universidades todos los días salen nuevos ingenieros en Java, mientras que en C++ está pasando lo mismo que alguna vez pasó en COBOL. Están desapareciendo. Las empresas que tienen o tuvieron proyectos en C++ juran que nunca más tendrán proyectos con ese lenguaje. Las que no aprenden la lección, desaparecerán porque se las comerán las que desarrollan en Java. 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". Sí, y tengo entendido que los Smalltalkers que implementaron HotSpot en Java se forraron en plata. Por alguna razón parece que la plata está en Java... > 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). No ha sido mi expereincia. Probablemente te encontraste con proyectos mal hechos. > > > > 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. A menos que tu versión sea superior a la del resto... > 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, JA JA JA Buena comparación!!! Pero el problema no es Java, sino los que construyen sistemas operativos en Java. Es cosa de tiempo para que los sistemas operativos estén escritos en Java. 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... en realidad el mercado va hacia java. Hay una convergencia muy grande. BEA está sacando un producto llamado LiquidVM que corre directamente sobre el hardware, sin sistema operativo. Lo mismo tiene azul, con una máquina con 768 cores y 768 GB de RAM y sin sistema operativo. Existe JPC que es un VMWare implementado en Java. Puedes correr tu sistema operativo favorito en el browser. > 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... Pero es salvable. De hecho en mi empresa ya lo tenemos resuelto. 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... Ok, puede ser, pero tener un Smalltak que ejecuta en un sistema operativo solamente (como era el caso del defunto Dolphin) es claramente una actitud suicida. Si Java ejecuta en todas las plataformas, ¿porqué no usarlo? Es mucho más barato que implementar en una plataforma propietaria de la cual la verdad es que dudo bastante su futuro. ¿Has usado Vista? Yo lo he usado y la verdad es que me ha impresionado muy poco. Creo que prefiero quedarme con Win XP. ¿Has usado Ubuntu? No puede ser más fácil de instalar. Es realmente amigable, mucho más que Windows. Los menús parecen hechos para seres humanos. > 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... Tinalli? Qué es eso? 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" ... Es cierto que Java es sólo rebaño, pero ciertamente es el rebaño más grande. Ahora que es open source, :NET, la única competencia seria que tenía, está tendiendo a desaparecer. Es cosa de tiempo... Y si lo dices por Smalltalk, buen intento y buenas intenciones, pero veo difícil que Smalltalk se recupere de la situación desmedrada en que está si no se vuelve open source y multiplataforma. El problema es que los proveedores de Smalltalk necesitan los ingresos, mientras que Sun tiene otros ingresos para mantener Java gratuito y a flote, aunque técnicamente sea inferior, que parece que es a lo que te refieres. Aunque por suouesto omitiste los bloques, los closures, las variables no tipadas, los traits que parece que a nadie le gustan en este newsgroup, etc. -- 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. -~----------~----~----~----~------~----~------~--~---
