🚀 go-pugleaf

Buenas...

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

Evidentemente, como tampoco tienes garant�a de que Sun no vaya ma�ana
a la quiebra y Java se hunda. Pero parece poco probable, �no?. Pues
salvando las diferencias, si coges librer�as que est�n bien extendidas
y asentadas (y hay unas cuantas) puedes estar pr�cticamente seguro de
que las vas a tener en cualquier plataforma medianamente importante.
Si para hacer un GUI yo trabajo con tcl/tk, V, wxWindows, Coral, etc.
s� que mi aplicaci�n va a funcionar sin ning�n cambio en cualquier
plataforma de la que merezca la pena preocuparse, y NO tengo que
mantener versiones distintas de mi programa, ni escoger cuidadosamente
la librer�a en funci�n de la plataforma, etc.

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

�C�mo? �Qu� YO no veo la diferencia? Pero bueno, qu� es esto �una
broma de mal gusto?. Ya estoy literalmente _harto_ de decir que es
cierto que la portabilidad de Java es en un sentido diferente que la
portabilidad en C, y t� sigues y sigues intentando "convencerme" de
algo en lo que siempre he estado de acuerdo!


- El 23/1 dije:

"Yo no estoy defendiendo que C sea mejor o peor que Java. A m� Java me
parece un lenguaje fant�stico, y me parece muy bien que sea m�s
portable que C y que C++. Lo �nico que yo estoy haciendo es defender
la utilidad de C, no ponerlo por encima o por debajo de otros
lenguajes."

- El 28/1 dije:

"�Por qu� te empe�as en convencerme de que Java es m�s portable que C,
cuando yo nunca he defendido lo contrario?"
"Java es m�s portable que C, porque Java est� dise�ado con el objetivo
prioritario de ser portable. "

- El 5/2:

"A pesar de todo, nunca he tenido problema en reconocer que Java es
m�s portable que C.
Si me dices que Java es m�s portable que C: de acuerdo.
Si me dices que Java es portable "en un sentido distinto que C": de
acuerdo, b�sicamente porque es interpretado."

Nota: Esto se refer�a a la necesidad de un programa que lo
interpretase, no de s� el c�digo que se ejecutaba se compilaba antes o
no (ver comentario m�s abajo)

- El mismo d�a, en otro mensaje:

"Mira, ya s� que Java es m�s portable que C. Ya s� que el sentido de
la portabilidad en Java es distinto al sentido de la portabilidad en
C."

- El 8/2

"No es solo que lo diga, es que estoy harto de repetirlo. Te invito a
que repases todos mis mensajes, si no te acuerdas. He dicho mil veces
que no discuto que Java sea m�s portable que C, o portable en un
sentido diferente, o m�s c�modo, etc."


�Qu� m�s quieres? �Qu� tengo que decir? Ya S� que Java es M�S portable
que C, que es portabilidad en un sentido diferente, etc, etc. Es que
yo NO estoy comparando C con Java, nunca lo he hecho. S�lo estoy
discutiendo la afirmaci�n de que en t�rminos absolutos, C no puede ser
portable. 

>> Haz una aplicaci�n que use tcl/tk, o
>> V, y funcionar� en casi cualquier cosa.
>
>La situaci�n simplemente NO es comparable.

Pero es que NO la estoy comparando.

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

Pues no los he puesto para adornar, sino para ilustrar lo que
defend�a:  que es lo mismo que pone justo aqu�:

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

Muy bien, entonces �est�s de acuerdo con las dos conclusiones
anteriores, haciendo notar que la palabra "portable" en la afirmaci�n
a) no tiene el mismo significado que en el mundo Java?

[punteros] 
>> 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.
[...]

Pues Jonathan, t� deber�as saber perfectamente que si reservas un
bloque de memoria con malloc, ning�n compilador te va a dar un bloque
de s�lo lectura, ni memoria sofisticadamente protegida que no puedas
utilizar, etc. Eso de cara al programador da exactamente igual.

El �nico caso en que es necesario "prestar atenci�n al maldito
problema" es si est�s trabajando con el sistema a bajo nivel, pero en
ese caso evidentemente tu programa no ser� portable. Pero eso es una
*elecci�n*, si te atienes al est�ndar te aseguras la portabilidad.

>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

Ya te digo que yo he realizado aplicaciones para m�quinas en las que
no ten�a literalmente ni IDEA de c�mo funcionaba el sistema de gesti�n
o protecci�n de memoria, y no he tenido que pensar en el maldito
problema. 

>Adem�s, la verdad es que creo que sabes todo eso y simplemente est�s
>discutiendo para discutir.

Pues te puedo asegurar que no discuto por discutir.

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

�AAAAAAHHH! (infarto)

�Pero si ya he dicho MIL veces que estoy de acuerdo con eso! No tienes
que decir NADA M�S para respaldar la idea de que C no es portable en
el mismo sentido que Java porque es algo con lo que SIEMPRE he estado
de acuerdo!

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

Mira, cuando hablo de ejecutable quiero decir que se trata de un
archivo binario que el sistema operativo puede leer y ejecutar sin
ayuda externa. En una programa en Java que no sea compilado
est�ticamente, o tienes un int�rprete de bytecode, o tienes un
compilador JIT, que en cualquier caso son programas externos
necesarios para poder ejecutar el archivo binario en el que tu
programa est� contenido. Un EXE es tan ejecutable en ese sentido como
una COM, pero un .class ... pues no mucho.

Para que entiendas el sentido en el que lo estoy tratando, si escribo
un programa en un formato ejecutable para un cliente, le doy al
cliente mi programa y lo podr� ejecutar en su sistema sin m�s ayuda.
Por el contrario, si le doy un programa en Java que no sea compilado
est�ticamente, tendr� que darle tambi�n el jre o lo que sea para que
lo pueda ejecutar: eso NO es un ejecutable, entonces. Y desde ese
punto de vista un int�rprete y un compilador JIT son exactamente
iguales, independientemente del proceso que haga cada uno
internamente. Son programas necesarios para poder
ejecutar/lanzar/interpretar la aplicaci�n en Java. Y es por ESO por lo
que Java es totalmente portable, porque ESE programa realiza una
funci�n de capa intermedia entre los servicios del sistema y la
aplicaci�n (ning�n problema con eso).

>parte del trabajo al final. Entonces la diferencia entre eso y un
>compilador JIT puede ser considerada como una diferencia de grado.

Con la sutil diferencia de que el ejecutable es un formato nativo del
S.O. y por tanto puede ser ejecutado sin ayuda, mientras que un
archivo binario en Java no. Desde ese punto de vista, un compilador
JIT es conceptualmente un int�rprete extremadamente inteligente.

>> 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".

Me da igual si es c�digo compilado de verdad o no, a lo que me refer�a
era a la necesidad de ese int�rprete/compilador JIT/ll�malo como
quieras para que tu programa se pueda ejecutar en la m�quina destino.

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

Piensa t� en lo que te acabo de decir.
 
Y por favor, intenta no seguir "convenci�ndome" de que Java es m�s
portable que C o portable en un sentido diferente.

Salu2: GUILLE

----
Guillermo Rodriguez Garcia
<XXguille@XXiies.XXes>  (ya sabes :-)