🚀 go-pugleaf

El d�a Tue, 19 Jan 1999 23:44:36 +0100, Jonathan Revusky
<jrevusky@jet.es> escribi�:

>> Qu� gracioso, eso de medir la portabilidad de un lenguaje en funci�n
>> de lo que ocurre cuando escribes c�digo que realiza acciones ilegales.
>
>No veo porque es gracioso. El mismo programa produce el mismo
>comportamiento en distintas plataformas. Punto. Es una definici�n muy
>l�gica de portabilidad.

Un programa *legal* en C ANSI tambi�n produce el mismo comportamiento
en distintas plataformas.

Por el contrario, un programa *ilegal* en C puede tener un
comportamiento indefinido, o simplemente dependiente de la
implementaci�n. Evidentemente ser�a m�s c�modo disponer de una
infraestructura subyacente que se encargase de lanzar excepciones
diversas en funci�n del error que se haya producido, y de hecho unas
cierta infraestructura si que hay, (en forma de se�ales SIGXXX que
permiten capturar tipos diversos de excepciones), aunque no es ni
mucho menos tan completa como la que ofrece Java. La cuesti�n es que
ese tipo de infraestructura (el que Java incorpora) implica
comprobaciones exhaustivas, por ejemplo en cada acceso a un array en
el ejemplo que t� citas, y eso para programaci�n del sistema
simplemente no es aceptable.

C se dise�� con la programaci�n del sistema en mente, no pensando en
aplicaciones de usuario. Se dise�� para que fuera eficiente y r�pido,
permitiese hacer de todo y no fuese tan complejo como el ensamblador.
Java se dise��, principalmente, para que fuese portable y
relativamente c�modo de utilizar, no pensando en su eficiencia. Como
ves, todo se reduce de nuevo a la separaci�n aplicaciones de
sistema/aplicaciones de usuario.

> Francamente, es tu definici�n de portabilidad
>que es m�s bien dudosa, creo.

No es m�a, es de las organizaciones ANSI e ISO, que me da a m� en la
nariz que de esto deben saber un poco.

[...]
>En la pr�ctica, tras una cierta escala, no hay sistemas sin ning�n bug
>de ning�n tipo. Decir que no importa que el sistema falle en alg�n SO y
>funciona en otro, porque el buen programa no tiene bugs en un principio
>es pamplinas.

No es eso lo que he dicho. He dicho que no puedes basar tu c�digo en
trabajar a base de excepciones. Me parece bastante diferente.
>
>Adem�s, tus afirmaciones se basan en el argumento falso de que la
>"programaci�n s�lida" consiste en no cometer errores.

Tampoco he dicho eso. Eso es simplemente _tu opini�n_ acerca de en qu�
baso yo mis argumentos, que por cierto es err�nea.

>Es como decir que
>la vida moral o �tica consiste en no cometer pecado. No es no pecar, es
>m�s bien un enfoque que lo minimiza. Java encapsula ese enfoque mucho
>mejor que C o C++.

�Y qui�n lo niega? Realmente no s� a que viene todo esto.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. 

>> >En C -- que de hecho ni siquiera tiene arrays o cadenas, los simulamos
>> >con punteros --
>> 
>> El C tiene arrays. No est�n "simulados mediante punteros", sino que
>> son tipos de datos diferentes de los punteros, para los que rigen
>> reglas distintas, aunque en muchos casos son intercambiables. 
>
>Seg�n mi manera de entender las cosas, el C no tiene verdaderos arrays.
>Un array en C no es m�s que un puntero constante.

Mira, mira...

=== Empieza ===
6.9:    Someone explained to me that arrays were really just constant
     pointers.

A:  This is a bit of an oversimplification.  An array name is
    "constant" in that it cannot be assigned to, but an array is
    *not* a pointer, as the discussion and pictures in question 6.2
    should make clear.  See also questions 6.3 and 6.8.
=== Acaba ===

> Con otra sintaxis para confundirnos. La prueba de eso es sencilla.
>
>El prototipo:
>
>int main(int argc, char *argv[]);
>
>es totalmente equivalente a:
>
>int main(int argc, char **argv);
>
>Si el C tuviese arrays, ser�an dos prototipos incompatibles.

No te confundas. El hecho de que punteros y arrays sean equivalentes
en muchas ocasiones no quiere decir que sean totalmente
intercambiables. De hecho, el est�ndar define cu�ndo son equivalentes
y cuando no lo son; internamente cada compilador los puede implementar
como le parezca, aunque lo l�gico es hacerlo mediante punteros.

Por ejemplo, en C, esto es totalmente portable:

char cadena1[] = "cadena de texto";
[...]
cadena1[0] = "x";    /* cambia una letra */

Pero esto NO lo es:

char *cadena2 = "cadena de texto";
[...]
cadena2[0] = "x";    /* cambia una letra */

Igual que tampoco lo es, por ejemplo, (y muchos compiladores se
negar�n a compilarlo) declarar una variable en un modulo como

char variable[] = "variable";

y referenciarla en otro como

extern char *variable;

Y much�simos otros ejemplos. La llamada "equivalencia" de punteros y
arrays en C no significa que sean totalmente id�nticos. Son
equivalentes, por ejemplo, como par�metros formales en una funci�n,
pero en muchos otros contextos no lo son.

Para que te quede claro:

=== Empieza ===
6.3:  So what is meant by the "equivalence of pointers and arrays"
     in C?

A:  Much of the confusion surrounding arrays and pointers in C can
    be traced to a misunderstanding of this statement.  Saying that
    arrays and pointers are "equivalent" means neither that they are
    identical nor even interchangeable.

    "Equivalence" refers to the following key definition:

        An lvalue of type array-of-T which appears in an
        expression decays (with three exceptions) into a
        pointer to its first element; the type of the
        resultant pointer is pointer-to-T.

    (The exceptions are when the array is the operand of a sizeof or
    & operator, or is a string literal initializer for a character
    array.)
=== Acaba ===

>
>>Pero eso
>> es una facilidad que se da al programador, no una restricci�n. Otra
>> cosa es que el programador no sepa usar esa facilidad y cometa
>> errores. Pero esa es la discusi�n de siempre: mientras m�s libertad
>> tienes, m�s cosas puedes hacer, y mientras m�s cosas puedes hacer m�s
>> trabajo cuesta aprender cuando no sabes.
>
>Esto se dice mucho, pero... no tiene mucha base real. La libertad de
>escribir a una direcci�n de memoria inv�lida no es realmente una
>libertad. Realmente es como afirmar que el suelo est� lleno de porquer�a
>y el hecho de limpiarlo me quita la libertad de tropezar y romperme el
>culo. Bueno, es cierto quiz�s, pero no es libertad como la mayor�a de
>gente entiende el concepto.

No hablo de la libertad de escribir a una direcci�n de memoria
inv�lida, ni a la libertad de que tropieces en un suelo lleno de
porquer�a. Hablo de la libertad de tratar los arrays y los punteros
como tipos equivalentes, en las situaciones en la que est�
perfectamente especificado que puedes hacerlo.

La diferencia est� en que si no te interesa tratar punteros y arrays
como tipos intercambiables en las situaciones en las que puedes
hacerlo, pues simplemente NO lo haces. Mientras que en tu ilustrativo
ejemplo, puedes perfectamente tropezar y romperte el culo aunque no
quieras.

>> > escribir a arr[n+1] puede funcionar bajo Windows 95,
>> >causar un assert bajo NT, funcionar con corrupci�n de los datos del
>> >programa bajo Linux, hacer que todo el sistema venga abajo en
>> >Macintosh... Todo depende de la disposici�n de memoria del sistema.
>> 
>> A lo mejor es por eso que el est�ndar dice claramente que el resultado
>> de esa operaci�n es "undefined". No veo ninguna incoherencia.
>
>No, es una descripci�n de la situaci�n, pero no quiere decir que la
>situaci�n sea deseable. 

De acuerdo.

>> >Es decir que, a diferencia de eso, en Java, estamos trabajando con un
>> >cierto determinismo que no depende de la maquina subyacente. Trabajamos
>> >con ciertas garant�as que (en mi opini�n) son imprescindibles para hacer
>> >algo que se asemeja a... ingener�a de verdad. Creo que es por eso que,
>> >cada vez que me encuentro escribiendo c�digo en C, tengo la inc�moda
>> >sensaci�n de que estoy haciendo chapuzas, mientras en Java, creo que
>> >estoy haciendo programaci�n de verdad. Eso es una sensaci�n subjetiva,
>> >pero creo que se basa en factores reales.
>> 
>> Sigo pensando que me parece un craso error basar este juicio y esta
>> discusi�n en lo que ocurre cuando realizas acciones que son ilegales.
>
>100% en desacuerdo. Adem�s, como dices, escribir a arr[n+1] no es ilegal
>ni en C ni en Java! Pero en java, el sistema lanza una excepci�n que
>puedes gestionar o no. Y lo hace de modo independiente de la plataforma
>subyacente. 
>
>Escribir a arr[n+1] cuando arr fue creado con n elementos es incorrecto,
>pero no es ilegal.

�C�mo que no es ilegal? �Qu� entiendes t� entonces por ilegal? Si un
lenguaje de programaci�n est� estandarizado, como C o Java, y se
escribe c�digo que contradice la norma, ese c�digo es ilegal. As� es
como se define.

[...]
>> Pero adem�s, evitar una carretera que tiene algunos baches pero hace
>> un camino diez veces m�s corto que otra perfectamente lisa y llana no
>> significa que la segunda sea mejor que la primera.
>> 
>> Programador de aplicaciones de usuario: "a m� no me importa llegar
>> antes o despu�s, lo que quiero es llegar sin complicarme la vida hasta
>> el infinito"
>> 
>> Programador de sistema: "Por supuesto, elegir� la carreter� m�s corta,
>> porque una vez que sortee los baches, podr� llegar antes ->
>> traducci�n: y escribir� herramientas mucho m�s eficientes, que es lo
>> que me interesa".
>
>El problema es que no vas a escribir herramientas mucho m�s eficientes
>t�picamente. La b�squeda de eficiencia usando herramientas de bajo nivel
>como C/ASM es pirita, el oro de tontos. De hecho, creo cada vez m�s que
>el resultado suele ser lo contrario. Hay una tendencia de escribir
>c�digo globalmente muy ineficaz buscando "eficacia localizada".

El problema es que vas a escribir herramientas infinitamente m�s
eficientes. Sigues pensando en aplicaciones de usuario, casi en
"herramientas de usuario" si es que eso existe. Yo estoy hablando de
programaci�n del sistema. 

>> - C es m�s r�pido que Java, lo cual a los programadores de
>> aplicaciones les importa un comino.
>
>No estoy tan seguro realmente. Ahora mismo, s�. Pero �intr�nsicamente?
>No estoy seguro. El C++ no es mucho m�s lento que el C y el Java es
>intr�nsicamente m�s optimisable que el C++. No hay que confundir el
>estado actual de las implementaciones con lo que es intrinsicamente
>posible.

C es intr�nsecamente m�s r�pido que Java por la misma raz�n que C es
intr�nsecamente m�s r�pido que Pascal, por poner un ejemplo, o que
C++, al que t� citas arriba. Simplemente porque es un lenguaje que
funciona a mucho m�s bajo nivel.

>> - Java es m�s c�modo y completo que C, lo cual a los programadores del
>> sistema les importa un comino.
>
>No estoy tan seguro tampoco. La motivaci�n detr�s de Java, un poco como
>ADA antes, era tener un lenguaje robusto para hacer programaci�n de
>aparatos. Luego naci� como el gran lenguaje para el Web y ahora para
>programaci�n general de aplicaciones. Pero Gosling y Joy no son
>precisamente programadores de aplicaciones y Java naci� como
>consecuencia de sus frustraciones con el C y C++ en esos �mbitos.

Hay dos grandes motivos por los cuales lo que he dicho es cierto:

- Con Java no puedes hacer CUALQUIER cosa, mientras que con otros
lenguajes s�. Eso, como comprender�s, para un programador que se
dedica a desarrollar herramientas de sistema o aplicaciones de
sistema, por no hablar del que desarrolla sistemas operativos
directamente, tiene "una cierta importancia".

- Java es mucho m�s lento que C y permite un menor control sobre
aspectos concretos de la implementaci�n, lo cual para programadores de
sistema es fundamental.

>> - C no est� muerto ni tiene pinta de que vaya a estarlo en el futuro
>> pr�ximo.
>
>En eso, estoy de acuerdo. A�n y as�, lo veo de una perspectiva un tanto
>distinta me parece. Es decir que si fuera cierto y el C estuviera
>muerto, yo no lo llorar�a. Es una l�stima que no sea cierto. 

Me parece fant�stico todo eso.

Ahora, por favor, ya he dicho varias veces que *NO* estoy interesado
en comparar Java con C, incluso he reconocido que para desarrollar
aplicaciones de usuario es mejor hacerlo en Java que en C. Suplico
encarecidamente que nadie m�s intente convencerme de nuevo de porqu�
Java es incre�blemente mejor que C y que C++.

Todo esto empez� porque dije que C no estaba "muerto" ni "a punto de
morir", en lo cual al menos parece que estamos de acuerdo. Toda la
discusi�n posterior acerca de lo mucho mejor que es Java comparado con
C, simplemente no s� a qu� viene. Nunca he sostenido lo contrario.
Solo digo que C es �til porque es necesario, simplemente porque hay
cosas para las que Java no sirve. Me da igual si es por inercia, o si
ha sido UNIX o no el que ha encumbrado el lenguaje. Me da igual si
Java es "m�s portable", "m�s f�cil", "m�s racional", "m�s
intr�nsecamente optimizable" o mil cosas m�s. La cuesti�n es que hoy
por hoy, el lenguaje C es totalmente necesario, y en cuanto a la
"aparente complejidad" que muchos arguyen, recomiendo a todo el que
desarrolle en C que se lea el est�ndar, que para eso est�.

Salu2: GUILLE

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