🚀 go-pugleaf

El d�a Fri, 29 Jan 1999 22:38:12 +0100, Jonathan Revusky
<jrevusky@jet.es> escribi�:

>> >Incluso si es oficialmente ilegal, carece de significado. Si algo es
>> >ilegal y no hay absolutamente ning�n mecanismo para "imponer la ley", su
>> >ilegalidad es m�s bien te�rica. Por ejemplo, si hay un limite de
>> >velocidad en una carretera de 100 km/h pero no hay ninguna vigilancia y
>> >nunca te multan, ese l�mite no tiene importancia pr�ctica (por lo menos
> 
>> No s� a qu� viene esto, de verdad.
>
>Te explico. Estoy diferenciando una realidad te�rica de una realidad
>pr�ctica. La portabilidad de c�digo C es una realidad te�rica en la
>mayor�a de casos.

Entiendo la met�fora, lo que no s� a qu� viene es el empecinamiento en
demostrar que el C no es portable. C puede ser tan portable como Java.
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. 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.

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) 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. Pero eso no significa que la portabilidad de C sea
"pura teor�a" como t� dices.

Un poco resumiendo:

- 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.
- Si me dices que C no es portable: est�s equivocado.

>> No hago ning�n argumento. Solo digo que el C es perfectamente portable
>> si te atienes al est�ndar, que para eso est�. 
>
>Como dije, veo eso como un argumento de abogado, m�s que un argumento de
>ingeniero.

Pues soy ingeniero, no abogado. Y tampoco creo que fueran abogados los
que redactaron el est�ndar. No s� porqu� no ves el punto del
argumento: se trata simplemente de que es posible hacer programas
portables, PERO tambi�n es posible hacer programas no portables.

>> 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*, 
>
>Mira, esto es pura desinformaci�n. Es cierto que hay muchos "chequeos y
>vigilancias" en Java, pero las cosas de que estamos hablando no tienen
>porque afectar la velocidad de ejecuci�n, ya que se llevan a cabo
>est�ticamente. Por ejemplo, la etapa de verificaci�n del bytecode ocurre

Eso depende de cada m�quina virtual y de cada compilador, pero en
general, s� que va a haber un overhead, que ser� m�s o menos grande, y
eso para aplicaciones que tengan un interfaz interactivo de tipo
"pulso aqu�-ocurre esto" probablemente no tenga ninguna importancia,
pero en otras aplicaciones, como procesos que corren continuamente en
background, o que realizan c�lculo intensivo, o muchos otros, s� puede
que la tenga.

>una vez a la hora de cargar una clase. Si compilas est�ticamente, es una

Si compilas est�ticamente tienes el mismo problema que tanto criticas
en C: tienes que recompilar para cada m�quina. Yo la ventaja de la
portabilidad de Java la veo en Java interpretado (repito: compiladores
JIT incluidos), corriendo sobre una JVM. Java compilado pierde mucho
de la esencia de Java.

>> que teniendo en
>> cuenta para qu� est� dise�ado C parece un factor bastante importante.
>
>El C fue dise�ado en su forma inicial casi exclusivamente para que fuese
>f�cil implementar un compilador.

Y luego fue estandarizado para que fuera portable. El C del que estoy
hablando no es el C de K&R, sino el C ANSI.

>Hombre, mira, para un segundo y da un paso atr�s. Est�s defendiendo algo
>totalmente indefensible, la sintaxis de arrays que tiene el C. �C�mo
>puedes defender eso? �Es indefensible! 

�Pero bueno! Yo NO he defendido en ning�n momento la sintaxis de
arrays del C, simplemente cuando t� dijiste que el C no ten�a arrays,
yo te contest� que s� los tiene, y que no son iguales que los
punteros, aunque en ocasiones se puedan tratar de forma equivalente.
De ah� a "defender la sintaxis de los arrays" hay un trecho. P�rate a
pensarlo.

>> >La portabilidad en C es algo:
>> >
>> >(1) definido de manera muy limitada
>> 
>> La portabilidad de C est� perfectamente definida para permitir
>> trabajar sin tener un overhead del 1000% s�lo en comprobaciones 
>
>���1000%???? �De d�nde est�s sacando esto? Es cierto que las primeras

:-)

Es que soy andaluz, llevo la exageraci�n metida en la sangre.

Lo siento, no estaba citando cifras, es s�lo una forma de hablar. Si
alguien me ha malinterpretado pido disculpas. El overhead de las
comprobaciones y chequeos de Java puede estar, usando datos m�s
realistas, en torno al 20-100%, en funci�n de la aplicaci�n y las
librer�as.

>> sobre
>> si el programador es lo suficientemente inteligente como para no
>> acceder a un elemento inexistente en un array, por ejemplo. Ya he
>> dicho que el �nico motivo de no tener los muchos mecanismos que tiene
>> Java de protecci�n contra errores son motivos de eficiencia, y est�n
>> plenamente justificados.
>
>La sintaxis tan horrible de arrays (y cadenas) en C no tiene nada que
>ver con la eficacia de ejecuci�n. Y punto. Si seguimos esta discusi�n,
>no repitas ese argumento m�s, porque ser�a prueba de mala fe.

Bueno, aqu� te quiero decir varias cosas:

- Primera: yo NO estoy defendiendo la sintaxis de los arrays en C,
estoy defendiendo que el hecho de que no tenga mecanismos como los que
tiene Java para tratar las excepciones es una cuesti�n de eficiencia,
porque el overhead que te comentaba antes ser� m�s grande o m�s
peque�o pero el caso es que _existe_

- Segunda: C no tiene cadenas (eso s� que es cierto)

- Tercera: Simplemente porque t� digas que una cosa "es as� y punto"
no me parece que quede zanjado el tema, as� que si yo repitiera ese
argumento (que nunca he sostenido: ver apartado primero) no ser�a
prueba de mala fe en absoluto, simplemente de que no me habr�as
convencido de estar equivocado.

>> Repito por en�sima vez que me da exactamente
>> igual que Java sea m�s portable que C o que deje de serlo. Lo que
>> defiendo es que C puede ser perfectamente portable.
>> 
>> >y
>> >
>> >(2) no tiene mucho significado pr�ctico.
>> 
>> Claro, por eso herramientas como por ejemplo todas las de gnu est�n
>> �ntegramente escritas en C y son perfectamente portables a docenas de
>> sistemas distintos.
>
>Para los lectores que no sab�is qu� son las herramientas de GNU, que
>sepais que Guillermo est� hablando de un conjunto de herramientas de
>l�nea de mando, que no tienen ninguna interfaz gr�fica, que son cosas
>algor�tmicas como el GREP y el SED y el MAKE que leen un stream por
>stdin y lo escriben al stdout. 
>
>Lo que pasa es que a partir de 1984 y adelante, iniciado por el
>lanzamiento del Apple Macintosh, la inform�tica empez� una revoluci�n
>basada alrededor del esquema de interfaz gr�fica. En este mundo moderno,
>los programas que los usuarios finales utilizan tienen una interfaz
>gr�fica e intuitiva.
>

Pues para empezar, acabas de dar en el clavo. Los programas "que los
usuarios finales utilizan" son aplicaciones de usuario. Los programas
que utilizan mayoritariamente los desarrolladores o son herramientas
de sistema.

Por otra parte, efectivamente las herramientas de GNU son casi todas
en modo consola, pero es que hay mucho UNIX por ah� sin X, con lo cual
en determinadas ocasiones  o trabajas con stdin y stdout o no
trabajas.

Y por �ltimo, tambi�n mucho del software que se escribe para X, por
ejemplo con tcl/tk, se escribe en C,  y todo ese software es
perfectamente portable a cualquier m�quina donde haya tcl/tk (casi
todas las que merecen la pena, y no solo Unix: tambi�n hay para
Windows, OS/2, etc.). Como ves, el tema de que las aplicaciones tengan
GUI o lo dejen de tener es mayoritariemente un problema de librer�as,
no de lenguaje. La librer�a est�ndar de Java incorpora awt y jfc
(swing), y la de C no tiene nada parecido, pero hay alternativas como
tcl/tk o V, por poner un ejemplo. No tiene nada que ver con el
lenguaje en s�.

>Es cierto que el C puede considerarse portable para los que quieren
>quedarse en el mundo perdido de Jurassic Park hasta el fin del tiempo.
>Pero si quieres hacer algo moderno, con una interfaz gr�fica, un
>programa que un usuario normal y corriente utilizar�a, no puedes
>f�cilmente hacerlo en C y que sea portable.

"Programa que usuario normal y corriente utilizar�a" != "herramienta
de sistema".

Aparte de lo cual s� que puedes. Usa V o tcl/tk, o alguna otra.

>Bueno, lo dejo aqu� de momento. S�lo un comentario m�s sobre el resto
>que he cortado. Por una parte, no deber�as decirme que no entiendo c�mo
>funcionan los arrays en C. Es que lo entiendo perfectamente y desde hace
>muchos a�os.

Bueno, entonces me limitar� a decir que no daba esa impresi�n.

>Y mira, hombre, da un paso atr�s y date cuenta de que est�s defendiendo
>algo totalmente indefensible.

�Es que NO, NO, NO, NO, NO lo estoy defendiendo! Si as� fuera no
tendr�a problema en reconocerlo, te lo aseguro.


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