Hola Emilio,

On 8/15/07, Emilio Oca <[EMAIL PROTECTED]> wrote:
>
> Guillermo,
> Veo que con la misma ligereza con que opinas de Smalltalk, opinas de Java
> y de otros lenguajes.
> Por suerte vos mismo te contradecis en tus siguientes respuestas.
> Pero dejemos en claro algunos puntos que no tienen que ver con Smalltalk,
> no sea que agarres desprevenido a alguno:
>
>     Java es tan compatible como las implementaciones de sus
> especificaciones, que como son implementaciones distintas de proveedores
> distintos, imaginate. Esto aplica desde las vms hasta las apis de los app
> servers.


Una cosa es la compatbilidad binaria y otra la compatibilidad a nivel de
fuentes.

En el caso de Java, la compatiblidad a nivel de fuentes está asegurada
independientemente del vendor, pero desafortunadamente esto no ocurre a
nivel de versiones (como suele ocurrir con todos los compiladores). Los
casos de incompatibilidades a nivel de versiones son pocos pero existen.
Probablemente el caso más conocido es enum y assert.

En el caso de la compatibilidad binaria, IBM es el único que requiere
recompilar.

    Java tiene problemas en varios casos, es frecuente toparse con ellos. Si
> bien se puede vivir, trabajar y hacer software de muy buena calidad con
> ellos es ignorante afirmar lo contrario o achacarlos a viejas versiones. Y
> hablamos desde implementaciones de lookup en el classpath hasta operaciones
> en numeros decimales.


Creo que lo que mencionas es cierto, aunque nunca he visto problemas de
incompatilibdades en el lookup del classpath, sì he visto incompatibilidades
en el lookup JNDI. En general acà se aplica el design pattern conocido como
service locator y se acabó el problema.

En el caso de los nùmeros decimales, Java en la versión 1.0 era 100%
compatible porque hacìa todo por sfotware, pero luego pasò a hacer todo por
hardware para mejorar el desempeño. Si quieres que sea 100% compatible debes
usar strictfp.

En el caso de Smalltalk ¿què usa?

Smalltalk usa BigInt par alos enteros, pero no sè lo que usa para los
nùmeros de punto flotante. (Y como las clases en Smalltalk son abiertas,
usan lo que uno quiera, pero qué es lo más común???)

    A quien se come MySql? Como supongo que lo decis en serio, trata de
> mirar que servicios brindan o implementan las grandes bases de datos. Que
> MySql te sirva a vos o a tu equipo de trabajo no significa que pueda
> reemplazar en cualquier lado a Oracle por citar un ejemplo.


MySql tiene deficiencias de la misma manera que los tiene Postgres, Oracle,
Sybase y SqlServer. Ninguna de las bases de datos cumplen en un 100% con
todos los features.

Y aunque los cumplieran, el modelo relacional inventado por Codd y Date
piden màs. Simplemente la tecnologìa hasta el momento no es capaz de
implementarlo todo.

   Comparar C con Java en los terminos que usas es no reconocer los ambitos
> de aplicacion propios de cada lenguaje.


Si miras HSQL y H2 veràs que las bases de datos hoy en dìa se pueden
implementar en Java. Ademàs no hay servicios sockets que no se peudan
implementar en Java. ¿Porqué no se podría implementar un sistema de
archivos? ¿O un sistema de archivos que por detràs funcione como una base de
datos? ¿O un sistema de archivos donde cada bloque se almacene en una
màquina distinta?

¿Y si pudièramos implementar un VMWare en Java?

¿Entonces què nos faltarìa para tener un sistema operativo completo?

El resto de tus comentarios los tomo con la ligereza habitual con la que vos
> escribis.


Ok, gracias! No veo ninguna razòn para hundirse en la depresiòn con un
comentario.

Saludos.
>
>     Emilio
>
> --
> 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.

-~----------~----~----~----~------~----~------~--~---

Responder a