🚀 go-pugleaf

El d�a Mon, 18 Jan 1999 20:00:48 +0100, Jonathan Revusky
<jrevusky@jet.es> escribi�:

>> Bueno, digamos que la definici�n no es tan estricta como para
>> especificar el ancho en bits de esos tipos, pero eso es porque C est�
>> pensado para funcionar en m�quinas muy diversas, en la que por poner
>> un ejemplo, los bytes pueden ser de 7 bits, o de 9, y forzar en esas
>> condiciones un tipo char de 8 bits ser�a muy ineficiente. Sin embargo
>> el est�ndar ofrece mecanismos para que el programador pueda conocer
>> los tama�os y rangos de los tipos que usa. Pero s� que es cierto que
>> si no tienes cuidado y sigues el est�ndar al pie de la letra, te
>> puedes llevar muchas sorpresas.
>
>Me temo que todo eso, aunque parezca mucho, es s�lo la parte visible del
>iceberg. El C NO es portable en el mismo sentido que el Java. No, no y
>no.
>
>En Java, si creo un array con n elementos e intento acceder a arr[n+1]
>algo muy bien definido ocurre. El sistema lanza un
>ArrayOutOfBoundException. Esto ocurre bajo Linux, Windows, Macintosh,
>OS/2 y cualquier SO cuya existencia hasta desconozco.

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.

Si tienes un array de n elementos y accedes al elemento (n+1) es que
est�s haciendo algo mal. Punto. Est� muy bien disponer de excepciones,
y son muy �tiles, especialmente cuanto est�s depurando, pero si vas a
basar tu c�digo en ellas me parece que eso que comentas abajo de las
"chapuzas" bajo C y la "programaci�n s�lida" bajo Java queda un poco
desvirtuado. En cualquier caso, no me parece una forma de medir el
grado de portabilidad de un lenguaje.

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

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

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

>El C ha sido muy importante en la historia de la inform�tica, sobre todo
>porque es muy f�cil implementar un compilador C en cualquier sistema
>nuevo. Entonces siempre ha representado una especie de denominador com�n
>al cual cual uno pod�a recurrir. Tambi�n exist�a el hecho hist�rico que
>el UNIX se escribi� en C y cada port de UNIX, como garant�a, ten�a un
>compilador C encima.
>
>Todo lo expuesto arriba no tiene nada que ver con si C es un buen
>lenguaje. De hecho, lo es... para los autores de compiladores. El C fue
>dise�ado para ser f�cil para los autores de compiladores, no para los
>autores de aplicaciones. Como observaci�n general, apostar�a que somos
>todos autores de aplicaciones, no de compiladores.

Ya hace unos cuantos mensajes que dije que estaba de acuerdo en que
para escribir aplicaciones de usuario el C probablemente no fuera el
mejor lenguaje, pero que es imprescindible para escribir aplicaciones
de sistema (como por ejemplo, s�, los compiladores, pero no s�lo eso)
y que est� muy lejos de la extinci�n. Por tanto, no s� a d�nde me
quieres llevar con eso. Estoy de acuerdo contigo en todo lo que dices
en los dos �ltimos parrafos.

>> >El problema de lenguajes como C es que requieren del programador una feroz
>> >disciplina. He perdido meses enteros buscando un error en una aplicacion que habia
>> >escrito otra persona. Es muy facil descontrolar un puntero o pasar de limites un
>> >array.
>> 
>> Es cierto, pero tambi�n es m�s que nada una cuesti�n de h�bitos. Para
>> quien no est� acostumbrado a escribir en C, es fac�lisimo despistarse
>> y que se le descabalgue a uno un puntero, por ejemplo, pero una vez
>> que te acostumbras es como todo.
>
>Es, m�s que nada, una prueba de que uno se puede acostumbrar a cualquier
>cosa. Saber d�nde est�n todos los baches en una carretera para no dar
>con ellos no significa que la carretera no est� llena de baches.

Cierto.

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

Me parece que estamos diciendo lo mismo todo el tiempo.

>
>Es que yo no veo porque no decirlo directamente. El C require una feroz
>disciplina porque ES UNA HERRAMIENTA MUY, PERO MUY PRIMITIVA. Escribir a
>mano require una feroz disciplina comparado con escribir con procesador
>de textos. Por el mismo motivo. 

Esto me parece ya un poco exagerado por tu parte.

>
>> Yo creo que el enfoque adecuado es el que has comentado arriba. Para
>> aplicaciones complejas, usar un lenguaje de m�s alto nivel, y recurrir
>> puntualmente a C (o para el caso, al lenguaje de bajo nivel con el que
>> se sienta uno m�s c�modo) donde haga falta m�s eficiencia, como por
>> ejemplo en funciones que realicen c�lculos intensivos o similares.
>
>A veces es necesario, pero en general, es una idea bastante peligrosa.
>Me acuerdo que en los buenos viejos tiempos, lo que se hac�a es que se
>escrib�a directamente a la placa de v�deo, EGA, VGA, Hercules, seg�n el
>caso, porque era m�s eficaz que usar el BIOS, por ejemplo. Bueno, era
>necesario, porque se ganaba 10x en eficacia porque el BIOS fue horrible.
>Pero en realidad, era una chapuza, un mal necesario por culpa del estado
>de las cosas de aquel entonces.
>
Un mal necesario para el que escrib�a aplicaciones, o simplemente la
�nica forma posible para el programador de sistemas.

>Yo creo que, en la mayor�a de casos, ser� dif�cil mejorar mucho la
>r�pidez del lenguaje de m�s alto nivel. Si logras ganar 20% o algo as�,
>no compensar� los inconvenientes. Sospecho que en la mayor�a de casos,
>es un error. En todo caso, preocuparse de la eficacia es la �ltima cosa
>que uno deber�a hacer. Lo m�s importante es que el c�digo sea claro y
>mantenible. Cuando tienes algo que funciona, s� que se puede intentar
>identificar la parte del c�digo donde el programa pasa m�s tiempo e
>intentar optimizarlo, pero la mayor�a del c�digo de un aplicaci�n no
>precisa mucha optimizaci�n en primer lugar.

Reitero lo dicho.
>
>Adem�s, muchas veces el problema de r�pidez ocurre porque el algoritmo
>b�sico es muy ineficaz y cambiar de lenguaje no va a mejorar mucho la
>situaci�n. Incluso para la cuesti�n de eficacia, recurrir al C (y peor
>el ASM) deber�a considerarse como un �ltimo recurso.

Y lo vuelvo a reiterar.



Bueno, despu�s de esta extens�sima discusi�n, creo que estaremos todos
de acuerdo en los siguientes puntos:

- El C no es un buen lenguaje para programadores de aplicaciones.
- El C s� es un buen lenguaje para programadores del sistema.
- C es m�s r�pido que Java, lo cual a los programadores de
aplicaciones les importa un comino.
- Java es m�s c�modo y completo que C, lo cual a los programadores del
sistema les importa un comino.

Y del segundo punto se deriva lo �nico que yo he estado defendiendo
todo el tiempo.

- C no est� muerto ni tiene pinta de que vaya a estarlo en el futuro
pr�ximo.

Salu2: GUILLE

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