🚀 go-pugleaf

Guillermo Rodriguez Garcia wrote:
> 
> El d�a Mon, 25 Jan 1999 18:18:24 +0100, Jonathan Revusky
> <jrevusky@jet.es> escribi�:
 
> >Es incorrecto obviamente. Pero no s� si es ilegal. Quiz� se describa
> >como ilegal en la especificaci�n, pero no me parece un argumento muy
> >potente en todo caso.
 
> En fin...
 
> >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.
 
> >nadie que proporcione empleo y vivienda a cada espa�ol.) El argumento
> >que haces sobre lo que es legal, a nivel pr�ctico, me temo, no tiene
> >mucha base real.
 
> 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.

> 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
una vez a la hora de cargar una clase. Si compilas est�ticamente, es una
verificaci�n a la hora de compilar. Adem�s, en el caso de clases
cargadas dinamicamente, es una etapa opcional que s�lo es necesaria para
"untrusted code" que se carga de la red.

En cuanto a la verificaci�n de que un �ndice no sobrepasa los l�mites de
un array, como he indicado en mi respuesta a Enrique, casi cualquier
caso cr�tico se hallar�a dentro de un bucle y cualquier compilador --
hasta un compilador JIT -- puede prescindir de las verificaciones de
l�mites cuando es demostrable que el �ndice nunca supera el l�mite. En
cualquier caso en que t� y yo nos damos cuenta de que el �ndice nunca
supera el l�mite, el compilador se da cuenta tambi�n. Con dos
diferencias. El compilador se da cuenta mucho m�s r�pido, cuesti�n de
microsegundos y... el compilador NUNCA se equivoca.

> 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. Acu�rdate que los dise�adores de C
ten�an el objetivo de hacer un sistema operativo. Hacer un lenguaje s�lo
era una etapa intermedia. Quer�an un lenguaje para el cual fuese f�cil
escribir un compilador. Es s�lo por eso la sintaxis tan impresentable de
los arrays (y cadenas) en C. Fue una chapuza r�pida por la cual llevamos
a�os pagando.

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 todo eso nos lleva, como siempre, a la siguiente observaci�n.
> >
> >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
implementaciones de java funcionaban con interprete de bytecode y que
hab�a un 1000% o m�s comparado con C. Ahora, en cualquier plataforma
importante, java es un lenguaje compilado (en JIT o incluso
est�ticamente) y las comprobaciones ocurren est�ticamente a la hora de
compilar a c�digo nativo. 

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

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

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.

> 
> >Eso a nivel de empresas grandes que pueden dedicar muchos a�os-hombre al
> >tema de portar software. A nivel de gente como yo, un desarrollador
> >independiente, o incluso empresas peque�as, a nivel pr�ctico, esa
> >portabilidad casi no existe.
> 
> Nunca he dicho que el C sea un buen lenguaje para t�, ni para la gente
> como t�, ni para peque�as empresas que desarrollan mayoritariamente
> aplicaciones de gesti�n o similares. He dicho que el C es el lenguaje
> de los que desarrollan sistemas operativos, aplicaciones de sistema,
> herramientas, etc. Se me va a caer la boca de decirlo.

Mira, mucha gente que trabaja muy cerca del hardware est� hasta el mo�o
del C tambi�n. Es por eso el inter�s suscitado por el embedded Java
specification y alguna especificaci�n que HP est� desarrollando en
competencia con eso. Java suscita tanto inter�s en esos dominios tambi�n
porque los fallos y limitaciones del C son ya patentes. 

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. Y no soy el �nico en considerar que la sem�ntica de arrays
en C es totalmente inaceptable.

Y mira, hombre, da un paso atr�s y date cuenta de que est�s defendiendo
algo totalmente indefensible. El consenso general en el mundo, entre
gente que piensa seriamente en temas de lenguajes de programaci�n, es
que esa sintaxis de arrays en C es algo horriblemente roto. Si quieres
defender el uso del C, s� m�s selectivo. No defiendas todos sus
aspectos, hasta sus fallos m�s evidentes, como si se tratara de tu
propio hijo. S� que sabes bastantes cosas, pero es que da�as tu
credibilidad as�, hombre. Pi�nsalo.

Saludos,

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