🚀 go-pugleaf

Guillermo Rodriguez Garcia wrote:
> 
> El d�a Fri, 08 Jan 1999 11:15:01 +0100, Ramon Vidal Morell
> <vidal@ibm.net> escribi�:
> >>
> >> No necesariamente, si usas las librer�as adecuadas. Ocurre exactamente
> >> lo mismo que con Java. Yo no estoy hablando de las librer�as, aunque
> >> sean librer�as est�ndar como las del jdk, sino del lenguaje en s�. Por
> >> ejemplo, en C tienes V o Tcl/Tk para la interfaz gr�fica, y las
> >> librer�as est�ndar de Unix para multithread (que vienen con todas las
> >> versiones de gcc, no solo las basadas en Unix) con lo que ya puedes
> >> hacer todo eso de forma portable. Pero vaya, que no iba por ah� la
> >> discusi�n.
> >
> >Realmente C no es un lenguaje portable, o lo es tanto como un piano con asas.
> 
> :-)
> 
> >Los datos basicos int, char, etc no estan definidos de igual forma para todas las
> >plataformas, por lo que te puedes llevar mas de una sorpresa al traspasar una
> >aplicacion de un sistema a otro.
> 
> 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.

En C -- que de hecho ni siquiera tiene arrays o cadenas, los simulamos
con punteros -- 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.

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.
 
> >Eso no quiere decir que este obsoleto ni mucho menos.

No, porque la inercia es una fuerza terrible. Pero es una l�stima.

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.


> >En general no suelo usar C para dise�ar aplicaciones grandes ya que los arboles no
> >me dejan ver el bosque. Prefiero usar un lenguaje de mas alto nivel y cuando es
> >necesario recurrir puntualmente a rutinas C o ensamblador.
> 
> Es una buena filosof�a.
> 
> >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.

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. 

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

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.

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.

Jonathan Revusky
-- 
Java and Delphi Consulting
Make your .class files double-clickable
with SmartJ
http://www.bigfoot.com/~crystalline.solutions