🚀 go-pugleaf

Guillermo Rodriguez Garcia wrote:
> 
> El d�a Sun, 07 Feb 1999 13:57:35 +0100, Jonathan Revusky
> <jrevusky@jet.es> escribi�:
> 
> >> S� que hay una diferencia principal, y es que las librer�as est�ndar
> >> de Java son mucho m�s completas que las de C. Por eso un programa en
> >> Java puede tener GUIs utilizando s�lo librer�as est�ndar, mientras que
> >> en C no es as�... (pero esto no significa que no se pueda hacer de
> >> forma portable.
> >
> >Hay una diferencia b�sica. En C, tienes que saber por adelantado en qu�
> >plataformas quieres que el c�digo corra y escoger las librer�as en
> >funci�n de eso.
> 
> No te creas. Todas las librer�as importantes se portan a todos los
> sistemas importantes, exactamente de la misma forma que Java se porta
> a todos los sistemas importantes.

No realmente, Guillermo. Las librer�as importantes son portadas (o no)
por sus autores. No hay ninguna garantia que cualquier plataforma con un
compilador C tenga esas librer�as disponibles. Es posible que s� y es
posible que no.

En todo caso, el problema en esto es que, incluso si todo lo que dices
es 100% cierto, y es muy f�cil escoger las librer�as y escribir c�digo
que funciona en todas esas plataformas indistintamente, coser y cantar,
eso est� muy lejos de la portabilidad que ofrece Java. Y la diferencia
es fundamental.

Primero: Con Java, las librer�as est�ndar DEBEN estar presentes. De no
ser as�, no se puede llamar Java -- un poco un tema pol�tico, pero las
implicaciones son dram�ticas. Java ya es suficientemente importante para
que cualquier empresa -- Apple, IBM, Hewlett Packard, Silicon Graphics
-- querr� asegurarse de que hay una implementaci�n de Java para sus
plataformas. Y esa implementaci�n debe pasar varias pruebas de
compatibilidad. 

Es decir, en el mundo C, yo, el desarrollador, soy responsable de que mi
programa corra en las diversos plataformas. *Yo* tengo que decidir por
adelantado en qu� plataformas quiero que mi programa pueda correr.
Luego, *yo* tengo que investigar qu� librer�as son disponibles para las
plataformas que me interesan. *Yo* tengo que tener un proceso de build y
de pruebas para mantener versiones distintas de mi programa para todas
esas plataformas. Eso, incluso si tienes raz�n y es relativamente f�cil
(y no lo tengo muy claro) en el mejor de los casos requiere un esfuerzo. 

En el mundo Java, simplemente escribo el programa y, en efecto, es el
fabricante de cada plataforma -- IBM, SUN, Apple, SGI, etc -- quien se
carga con la responsabilidad de que *mi* programa corra en *su*
plataforma. Bueno, no se trata de *mi* programa, sino de *tu* programa o
el de cualquiera. Pero salta a la vista que la diferencia es primordial.
Y de mi punto de vista, eso es un GRAN progreso. Las implicaciones
pr�cticas de todo eso son enormes. No hay color. Si realmente no ves la
diferencia entre las dos situaciones, no s� qu� m�s decirte.

> Haz una aplicaci�n que use tcl/tk, o
> V, y funcionar� en casi cualquier cosa.

La situaci�n simplemente NO es comparable.

<interesantes ejemplos, pero no tengo nada que decir sobre ellos
especialmente>

> 
> Lo cual, me parece a m�, demuestra los dos principales puntos que
> intento defender en esta discusi�n:
> 
> a) Que C puede ser portable.
> b) Que con Java no se puede hacer de todo.
> 
> �Te siguen pareciendo argumentos de abogado?

No, pero no son los argumentos que califiqu� de "argumento de abogado".
Eso fue que C era portable porque la especificaci�n del ANSI dice que lo
es.

> 
> >A diferencia de eso, en el coraz�n mismo de C, hay una sintaxis de
> >punteros y aritm�tica de punteros sin restricciones -- y la sem�ntica de
> >los punteros es necesariamente distinta para cada m�quina ya que depende
> >sutilmente (y a veces no tan sutilmente) del modelo de memoria de cada
> >SO y procesador. Para m�, eso ser�a un motivo inescapable para tener que
> >concluir que C no es intr�nsecamente portable en el mismo sentido que
> >Java.
> 
> Pues no s� por qu� dices eso: de cara al programador da exactamente
> igual como funcionen los punteros por dentro. Yo he escrito programas
> en C que utilizaban punteros y han funcionado en una gran cantidad de
> m�quinas diferentes y en muchas de ellas no ten�a ni pu�etera idea de
> c�mo iban los punteros por dentro, ni falta que me hac�a. La sintaxis
> es la que te da el lenguaje, no depende de la m�quina.

Pues, Guillermo, sabes perfectamente que hay memoria de s�lo lectura en
algunas m�quinas, algunas tienen un sistema sofisticado de protecci�n de
memoria, otras no tienen. En los buenos viejos tiempos del Win16, s�lo
se pod�a crear un bloque de memoria hasta 64K, por culpa de la
arquitectura de memoria de sistema aunque la m�quina tuviese 16M encima.
Hay el tema de la alineaci�n de los bytes en memoria....

Incluso, si en 9 casos sobre 10, las diferencias que puede haber no
tienen implicaciones pr�cticas, eso no me libra de la obligaci�n de ser
*consciente* de esas diferencias. El mero hecho de que yo tengo que
pensar en el maldito problema ya representa una diferencia de base con
lo que ocurre con Java. De todas formas, ese tipo de cosa puede importar
y puede perfectamente hacer que un programa funcione en una m�quina y no
en otra. Pero en el caso m�s general, yo, el desarrollador, tengo que
tener en mente esas diferencias de plataforma y tener cuidado
conscientemente de que todo lo que hago sea v�lido si se traslada a otro
sistema. En Java, no tengo esa preocupaci�n y eso representa una
diferencia primordial.

Adem�s, la verdad es que creo que sabes todo eso y simplemente est�s
discutiendo para discutir. Y eso puede hacer que mi tono llegue a
adquirir un peque�o tono de exasperaci�n. De todas formas, en cuanto a
la portabilidad, creo que he agotado mis argumentos. No s� qu� m�s decir
para respaldar la idea de que C no es portable en el mismo sentido que
Java. Es portabilidad en un sentido mucho m�s limitado.


> Para empezar, te agradecer�a que no utilizaras ese tono paternalista
> conmigo. Si te das cuenta no estoy hablando aqu� de eficiencia, sino
> de que en Java tienes un �nico archivo binario (pero no EJECUTABLE,
> como t� lo has llamado) simplemente porque hay un int�rprete debajo
> que es qui�n lo ejecuta. Y en este sentido da igual que se trate o no
> de un compilador JIT, da igual la eficiencia y da igual lo que genera.
> El caso es que el archivo binario NO es directamente ejecutable, 

Estrictamente hablando, en el mundo Wintel, lo �nico que es directamente
ejecutable es el fichero .COM, que es una im�gen exacta del c�digo que
se ejecuta. Bueno, tiene el inconveniente de que s�lo puede trabajar con
un espacio de memoria de 64K -- bueno, eso es un oceano para un viejo
hacker de C. Pero de todas formas, un .EXE necesita bastante
configuraci�n para ejecutarse. Tiene que cargarse en memoria y resolver
las llamadas a los diversos .DLL que necesita. Es decir que deja una
parte del trabajo al final. Entonces la diferencia entre eso y un
compilador JIT puede ser considerada como una diferencia de grado.

y esa
> es la �nica raz�n para no tener que recompilar en cada m�quina como en
> C.
> 
> Aparte de lo cual, tienes que reconocer que _conceptualmente_, un
> compilador JIT no es m�s que un int�rprete extremadamente sofisticado
> e inteligente. 

No,... no creo que tenga que reconocer eso conceptualmente. Un esquema
de compilaci�n JIT es un esquema donde dejas la �ltima etapa de
compilaci�n hasta justo antes de ejecutar. El c�digo ya es compilado a
un formato binario, el bytecode, y en la etapa final, se resuelve eso en
c�digo de m�quina y luego se ejecuta. No tiene mucho parecido con un
int�rprete. De todas formas, si sus prestaciones de velocidad son m�s o
menos las de c�digo compilado, es un poco vac�o, discutir sobre si es
c�digo compilado "de verdad".

> Dejando aparte temas de rendimiento, de eficiencia, de
> s� genera c�digo m�quina que despu�s ejecuta o lo que le de la gana de
> generar, el caso es que sin �l, el programa no funciona. Y esa es
> esencialmente la caracter�stica de un programa interpretado.

Hm, llevando tu argumento al l�mite, todo menos el fichero .COM es
c�digo interpretado. Es decir, un .EXE casi siempre supone la presencia
de bastantes otras cosas y bastantes cosas se resuelven a la hora de
cargar el ejecutable. Pi�nsalo un poco.

Saludos,

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