🚀 go-pugleaf

Ramon Vidal Morell wrote:
> 
> Hola Jonathan.
> 
> > .
> > S�, con VisualAge, el compilador nativo viene el la edicion empresarial.
> > Cuesta 3000 dolares, casi medio mill�n de pesetas. Antes estaba en
> > Alphaworks gratis, y luego, decidieron ganar dinero con eso. El JBuilder
> > no tiene un compilador nativo en ninguna versi�n.
> >
> 
> Se les va un poco la olla a IBM con los precios. La diferencia de coste
> entre la version profesional y la empresarial es brutal.

IBM trata con muchos clientes que no gastan su propio dinero. Es el
presupuesto del departamento o lo que sea. Yo, como consultante
independente, nunca pagar�a 3000 dolares por un entorno de programaci�n.
Aun y as�, es caro. Lo que pasa es que la l�nea de productos esa, el
Visual Age, era un entorno de Smalltalk, y en ese mundo, las
herramientas tienden a ser muy caros. Van dirigidas a empresas
telef�nicas y cosas as�. El Visual Age Smalltalk, me parece, era $5000
la licencia, as� que quiz�s creen que lo venden barato.


> Por lo que habia oido, la edicion empresarial no lleva tantas mejoras como
> para justificar tal precio. Quiza unos enlaces con CICS y con AS400 y por lo
> que ahora se, el compilador nativo.
> 
> > El mayor motivo para querer un .exe, aparte de mejorar el tiempo de
> > carga de la apli,  es simplemente para que el usuario pueda lanzar el
> > programa con un doble clic bajo Windows -- sin jugar con el CLASSPATH ni
> > nada de eso. Por eso, escrib� el SmartJ, que permite eso -- aunque
> > tienes que tener una JVM instalada. (Disponible a trav�s del URL en mi
> > sig.)
> 
> El ultimo JIT que tengo es el de la 1.1.7 y es cierto que es rapido, pero el
> HPJ produce un resultado bastante mas rapido, aunque quiza solo es
> apariencia, debido a la rapida carga.

No he dicho que no es m�s r�pido. Lo es. Hasta qu� punto depende de la
naturaleza del c�digo. Pero no es la diferencia noche y d�a que mucha
gente supone. Creo que la rapida carga enga�a. Lo que pasa con Java es
que es prohibitivamente caro inicializar una aplicaci�n Java. Eso es
cierto, porque cargar una nueva instancia de la JVM y cargar todas las
clases puede tardar tiempo. Pero, para una aplicaci�n de servidor que
siempre corre, no es relevante. 

> La idea era usarlo en un servidor de sockets bajo NT.
> Te parecera una tonteria, pero a algunos capos de mi empresa no les interesa
> hacer pruebas de velocidad. Han "decidido" que java es lento y que un .EXE
> es rapido.

S�, parece una locura, pero no me sorprende. Estoy llegando cada vez m�s
a la conclusi�n de que los que m�s hablan de eficacia y velocidad son
los que menos noci�n tienen sobre el tema. 

Por ejemplo, suele escaparles totalmente el hecho de que la gran mayor�a
de c�digo que uno escribe no es "cpu-bound". Lo cual quiere decir que
una vez es "bastante r�pido", no se consigue m�s rapidez optimiz�ndolo
m�s all� de ese punto. �Por qu�? Porque el tiempo de ejecuci�n es
totalmente dominada por factores ajenos -- el tiempo pasado dentro de
m�todos del kernel, E/S de disco, esperando respuestas de la red....

En cualquier hardware relativamente moderno, el JIT de Symantec produce
c�digo tan r�pido que en pocos caso la rapidez ser� un problema.
Entonces, creo que en la mayor�a de casos, la mejora obtenida por
compilaci�n est�tica no vale la vela. Depende del c�digo, pero, en
general, se puede decir que Java con el JIT de Symantec corre a m�s de
50% de la r�pidez del C compilado. Mira, no s� cu�nto c�digo de servidor
en la red est� escrito en lenguajes interpretados como Perl y Python.
Pero mucho c�digo, y es mucho m�s lento que java -- 5x, 10x, yo que
se... Pero, es igual, esos programas no correr�an m�s r�pido si
estuvieran reescritos integralmente en C. Porque ya son lo
suficientemente r�pido para que el tiempo sea dominado por otros
factores.

En general, esa historia de la velocidad y rapidez es, m�s que nada, una
cosa reaccionario para bloquear cualquier idea nueva. Escenario t�pico:

Propones reestructurar el c�digo de manera m�s orientado objetos. Y te
dicen que eso costar�a demasiado en eficacia. 

Les tomas en serio y quieres tratar el problema debidamente. Les
preguntas en qu� m�dulos el programa est� pasando m�s tiempo, y �ni
siquiera saben! No tienen ni idea porque nunca han usado una herramienta
de profiling sobre el c�digo. �C�mo cuadrar eso con su gran obsesi�n por
la velocidad? Parece una contradicci�n, �no?

"Padre, �por qu� vivimos en una cueva? Quisiera vivir en una casa."

"Las casas cuestan demasiado, hijo."

"Padre, estoy harto de dormir sobre estas rocas. �No podemos conseguir
una cama?"

"Las camas tambi�n cuestan dinero, hijo. Aparte de eso, los verdaderos
trogloditas dormimos sobre rocas. As� es y siempre ha sido as�."

"Vale, padre."

"Por cierto, hijo. �Qu� es una cama?"

Jonathan Revusky
-- 
Java and Delphi Consulting
Make your .class files double-clickable
with SmartJ
http://www.bigfoot.com/~crystalline.solutions