🚀 go-pugleaf

Guillermo Rodriguez Garcia wrote:

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

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. Francamente, es tu definici�n de portabilidad
que es m�s bien dudosa, creo.
 
> 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.

Pero por supuesto. Un programa portable puede correr en una multitud de
sistemas. Si el programa se comporta de modo distinto en cada uno, �c�mo
demonios vas a ofrecer alg�n soporte t�cnico al usuario? En el caso m�s
general, no puedes reproducir un bug sin tener la misma configuraci�n de
sistema que el usuario que dio el informe.

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

Adem�s, tus afirmaciones se basan en el argumento falso de que la
"programaci�n s�lida" consiste en no cometer errores. 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++.

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

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

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

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

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

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

Quiz� un poquit�n, pero no mucho.

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

Claro que no.

> - El C s� es un buen lenguaje para programadores del sistema.

El C es un mal necesario a nivel de programaci�n de bajo nivel, cerca
del hardware. Yo no creo tampoco que sea muy buen lenguaje a ese nivel,
pero es el denominador com�n, el est�ndar.

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

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

Pens�ndolo, incluso el C++ naci� como intento de remediar los defectos
de C, pero es realmente horrible. Es la consecuencia de intentar crear
una gran infraestructura encima de una fundaci�n demasiado d�bil para
soportarla. Realmente lamentable.

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


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