🚀 go-pugleaf

"Juan A. Paz" wrote:
> 
> Guillermo Rodriguez Garcia wrote:
> 
> S�lo una cosilla...
> 
> > No hago ning�n argumento. Solo digo que el C es perfectamente portable
> > si te atienes al est�ndar, que para eso est�. El hecho de que no haya
> > miles y miles de controles y chequeos y vigilancias etc etc como los
> > hay en Java es simplemente por motivos de *velocidad*, que teniendo en
> > cuenta para qu� est� dise�ado C parece un factor bastante importante.
> 
> Hay una diferencia ESENCIAL  entre JAVA y C que claramenteproporciona portabilidad frente a velocidad. Simplemente JAVA
> corre sobre una JVM, no sobre un sistema operativo de los muchos
> que existen. Si existe una JVM para un sistema operativo y tu programa
> JAVA corre en otra cualquiera correr� sobre esta nueva plataforma
> porque la simple definici�n de la JVM impide que haya problemas
> de portabilidad.

Supongo que estamos bastante de acuerdo, aunque me gustar�a matizar un
par de puntos. S� que JAVA es mucho m�s portable que C y s� que es
porque hay una m�quina virtual. Pero bueno, una m�quina virtual no es
una m�quina real, m�s que nada es una construcci�n cognitiva. Estamos
diciendo que tenemos una abstracci�n de una verdadera m�quina -- su
sistema de ficheros, sus hilos de ejecuci�n, su gesti�n de memoria su
interfaz gr�fica -- y escribimos nuestro c�digo para que corra en esa
m�quina abstracta, a diferencia de escribir c�digo para que funcione
bajo Win32 o Mac o Unix o lo que sea. Es una interfaz de programaci�n y
nuestro c�digo funcionar� en cualquier m�quina que implemente esa
m�quina abstracta. Lo que me deja con un cierto malestar en tu
afirmaci�n es la sospecha de que decir que Java es portable porque tiene
una m�quina virtual es quiz� equivalente a decir que Java es portable
porque Java es portable.

Y lo que pasa tambi�n es que cualquier lenguaje de programaci�n (incluso
el C) tiene una m�quina virtual en cierto modo -- hay una abstracci�n
subyacente de la verdadera m�quina. As� que quiz� la diferencia se halla
en la amplitud de ambici�n de la JVM. Realmente existe la ambici�n de
definir una interfaz de programaci�n que sea independiente de plataforma
y han ido mucho m�s lejos para conseguirlo.

De hecho, Java es tres cosas:

(1) El lenguaje mismo.

(2) El runtime -- la especificaci�n del bytecode Java y cosas como el
ClassLoader, el SecurityManager etc.

(3) Las librer�as est�ndar.

Bueno, es d�ficil mantener una l�nea fina entre las tres cosas, pero
todos contribuyen a la portabilidad frente a algo como C.

(1) El lenguaje mismo ya tiene incorporado una sem�ntica de programaci�n
multitarea -- multitarea -- la palabra clave "synchronized", pero bueno,
funciona en conjunci�n con las librer�as est�ndar, las clases
java.lang.Thread y el m�todo Object.wait() etcetera.

(2) Las librer�as est�ndar incorporan el AWT, una encapsulaci�n de una
interfaz gr�fica. (Es el aspecto de Java que m�s problemas ha dado, 90%
de los problemas de portabilidad -- y de velocidad.)

(3) El runtime puede rechazar c�digo "inv�lido" -- es decir c�digo con
resultados indeterministas. Entonces, a diferencia del C, hay un
mecanismo implantado que impone la compatibilidad al est�ndar.

> 
> C no es portable ni pretende serlo. C + UNIX es,  puede ser, portable a
> otros C + UNIX, lamentablemente hay muchos UNIXs diferentes, as�
> puedes hablar de C+ POSIX, etc...

En los 80, o� bastante que C era portable. Creo que eso se basaba en 2
ideas.

(1) C es portable porque lo estamos comparando con ensamblador (lo cual
no es decir gran cosa, digo yo :-))

(2) Cualquier plataforma tiene un compilador C. (Eso es un argumento
pragm�tico m�s que nada, no te�rico. C no es intr�nsecamente m�s
portable que cualquier otro lenguaje comparable. Simplemente se
convirti�, por razones historicos en un "�standar de facto".)

Pero, de todas formas, cuando se dec�a que C era portable, nunca
significaba portabilidad en el sentido amplio de lo que significa en el
mundo Java. Era algo mucho m�s limitado.

> 
> En cuanto a la compilaci�n del kernel de Linux supongo que ser�
> 'compilable' para muchas plataformas porque estar� repleto de
> compilaci�n condicional para ocultar la diversidad de uso de la
> memoria f�sica, de pantalla, etc... en los distintos sistemas. 

Sin duda. Aunque no he mirado ese c�digo.

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