🚀 go-pugleaf

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. Haz una aplicaci�n que use tcl/tk, o
V, y funcionar� en casi cualquier cosa.

>> Simplemente utiliza una librer�a adecuada, como por
>> ejemplo V), pero no es un problema de que el *lenguaje* sea m�s o
>> menos portable, sino de las librer�as.
>
>Las librer�as son un elemento de la rompecabezas. No obstante, no es el
>�nico elemento. Hasta el lenguaje Java es intr�nsecamente m�s portable
>que el lenguaje C. Como Juan Antonio indic�, la sem�ntica de Java se
>expresa en t�rminos de una m�quina virtual. Un programa v�lido en Java
>se reduce a una serie de instrucciones para esa m�quina *virtual*, que
>es una abstracci�n de una m�quina real. Bueno, eso quer�a matizar en un
>cierto momento, ya que por supuesto el C tambi�n incorpora una
>abstracci�n de la m�quina real. Cualquier lenguaje menos ensamblador,
>pens�ndolo. No obstante, hay una gran diferencia. En Java toda la
>sem�ntica de esas instrucciones (de hecho, uf, algunos matices me vienen
>en mente...pero bueno) est� definida de una manera independiente de la
>m�quina real.

Y eso tiene la ventaja de que todo lo que escribas es perfectamente
portable, y la DESVENTAJA de que es IMPOSIBLE escribir algo que
aproveche las caracter�sticas de una determinada m�quina o de un
determinado S.O., en aras de la portabilidad.

Por eso digo que C puede ser portable pero no te obliga a serlo.


Mira, para que dejemos de hablar de vaguedades y teor�as ambiguas, te
voy a citar ejemplos concretos. Me pongo a pensar en las aplicaciones
que yo he desarrollado en los �ltimos meses. T� puedes hacer lo mismo.

Un par de aplicaciones de las que yo llamo "de usuario":

1. Una aplicaci�n de gesti�n hotelera (no suelo hacer este tipo de
cosas, pero se trataba de una ocasi�n especial). ESTO es lo que llamo
aplicaciones de usuario (ahora ver�s el contraste con las que vienen
despu�s). Ni se me ocurre hacerla en C, porque tendr�a que trabajar el
triple. Ning�n problema en reconocerlo. La pod�a haber hecho en Java,
pero la hice en Delphi 4 porque *no* necesitaba que fuese portable, y
con Delphi puedo utilizar caracter�sticas espec�ficas de W95 mientras
que con Java NO PUEDO.

2. Una aplicaci�n estilo "chat", con algunas particularidades, para
correr en una red local en la que hab�a diferentes tipos de equipos.
Esta sigue estando en lo que yo considero aplicaciones de usuario.
Aqu� si que necesitaba portabilidad, y no ten�a que acceder a recursos
concretos de cada m�quina o S.O. Bueno, pues ESTA la hice en Java.

Y un par de aplicaciones que NO son aplicaciones de usuario:

3. Un analizador de espectros en tiempo real para frecuencias de
audio, que necesitaba para realizar un procesado digital de la se�al.
B�sicamente lo que hace es muestrear audio hasta 44 kHz, a 8/16 bits,
en mono/est�reo, calcular el espectro de la se�al o el espectrograma,
seg�n el modo de trabajo, enventanarla con diferentes funciones,
realizar filtrados de tipos diversos, etc., y todo esto en tiempo real
(70 fps). Esto no es una aplicaci�n de usuario, esto es una
herramienta. Evidentemente la hice en C. Y no es nada portable, por
cierto, ni falta que hace. Ahora bien, te reto no ya a hacer esto de
forma eficiente en Java, sino simplemente a _hacerlo_ en Java, y ver�s
qu� quiero decir.

4. Una aplicaci�n de visi�n artificial que reconoce matr�culas de
veh�culos a partir de fotograf�as tomadas por una c�mara digital. El
programa encuentra la placa en la imagen, la segmenta e identifica los
caracteres. Esta tambi�n est� hecha integramente en C, y hay dos
versiones: una de consola que funciona en *cualquier* sistema que
tenga un compilador de C, aunque sin mostrar im�genes, solo texto,  y
otra con GUI (basado en V), que corre bajo Windows (95, 98 y NT),
OS/2, Mac y cualquier sistema Unix con X.-Windows. La pod�a haber
hecho en Java, aunque probablemente hubiera salido algo m�s lenta
(realiza c�lculos intensivos). En cualquier caso la hice en C y es
perfectamente portable.


Bueno, pues aqu� tienes casi un ejemplo de cada tipo:

- Una aplicaci�n de usuario que se pod�a haber hecho en Java pero
result� m�s f�cil y apropiado hacerla usando una herramienta RAD. Es
decir, que la portabilidad es buena... pero no siempre necesaria.

- Una aplicaci�n de usuario en la que le mejor elecci�n era Java.

- Una herramienta que es IMPOSIBLE hacer con Java

- Una herramienta que se podr�a hacer con Java pero que est� hecha en
C y es perfectamente portable.


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?


>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.
 
>Otro motivo importante por el cual C es intr�nsecamente no portable --
>por lo menos compar�ndolo con Java -- es que Java lleva incorporado en
>el lenguaje mismo una sem�ntica de programaci�n multitarea. Ya que los
>programas no triviales hoy d�a tienden a ser multitarea, eso representa
>una gran limitaci�n de la portabilidad de C, una limitaci�n superada
>claramente por Java.
>
> 
>> Por otra parte, he visto que le contestabas a Enrique que en C hay que
>> recompilar para cada m�quina, mientras que en Java tienes lo que has
>> llamado "un �nico binario ejecutable". Eso es simplemente porque Java
>> normalmente es int�rpretado (dentro de esta categor�a incluyo los
>> compiladores JIT) 
>
>�C�mo dices? Guillermo, para que lo sepas. Los compiladores JIT compilan
>de verdad. Generan instrucciones de m�quina. La compilaci�n JIT ocurre
>la primera vez que una clase se carga en memoria. Y se ejecuta c�digo
>compilado comparable en eficacia con el c�digo generado por compiladores
>de otros lenguajes.

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

>> y C compilado, pero sigue sin ser una caracter�stica
>> esencial del lenguaje, m�s bien del entorno.
> 
>> A pesar de todo, nunca he tenido problema en reconocer que Java es m�s
>> portable que C. 
>
>Si t� lo dices. :-)

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. Lo �nico que defiendo es que hay
cosas que con Java no se pueden hacer, por una parte, y que C puede
ser perfectamente portable, por otra.

>
>> Pero eso no significa que la portabilidad de C sea
>> "pura teor�a" como t� dices.
>
>Mira, yo apostar�a que todas las empresas principales de Software --
>IBM, Microsoft, Adobe, Corel, etcetera -- tienen grupos enteros de
>trabajo donde la gente no hace m�s que portar c�digo.

Pff.. Empresas como IBM, Microsoft, Adobe o Corel deben tener grupos
enteros de trabajo hasta para limpiar las bolitas del rat�n.

>Para m�, la portabilidad de C es algo te�rico. Puedes afirmar que ANSI C
>es portable pero tienes que condicionar y matizar la afirmaci�n hasta
>tal punto que, al fin y al cabo, no tiene mucho significado.

No, f�jate que poco matizo:

"Un programa escrito siguiendo las directrices que dicta el est�ndar
ANSI C es perfectamente portable. Un programa escrito en C que no siga
el est�ndar puede funcionar perfectamente pero no ser� necesariamente
portable"

>Cierro este mensaje aqu�, porque todo esto se vuelve largo y quiz�
>conteste al resto por separado cuando tenga un momento.

Vaya, pero si te has dejado la parte m�s interesante.

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