🚀 go-pugleaf

Josep wrote:
> 
> Guillermo Rodriguez Garcia wrote:
> 
> > El d�a Wed, 10 Mar 1999 20:25:56 +0100, Josep <pep@megaiweb.com>
> > escribi�:
> >
> > >�Has o�do hablar de JavaOS?
> >
> > Pero JavaOS _NO_ es un SO desarrollado en Java, aunque su nombre pueda
> > l
> 
> Muy h�bil, Guillermo, pero te has olvidado de mi otra pregunta:
> 
> �Sab�as que hay cosas que es necesario que un sistema operativo haga y son
> imposibles de hacer en C? Y aqu� me refiero a cosas que no se deben hacer en
> p�blico, como mangonear directamente registros del procesador. Si hay un
> ESTANDARD de C - que no sea espec�fico de una plataforma - que permita hacer eso,
> yo no lo conozco.

Lo que a m� me gustar�a subrayar es el problema con este tipo de
argumento: "El n�cleo de linux est� escrito en C. La propia JVM est�
escrita en C." Y entonces, quieren que saques ciertas conclusiones.
Bueno, de hecho, no s�. �Qu� son las conclusiones que quieren que
saquemos?

El n�cleo de Linux o la JVM son trozos de c�digo que son usados por
cientos de miles, probablemente millones de personas cada d�a. Para todo
tipo de aplicaciones. Adem�s, no son bloques enormes de c�digo tampoco.
El runtime de Java, es decir el n�cleo del JDK 1.2 es alrededor de
50.000 l�neas de c�digo C. 

Esas 50.000 l�neas de c�digo son casi una singularidad en el mundo del
software. Un caso muy muy especial entre todas las miles de millones de
l�neas de c�digo que se escriben cada a�o. Se trata de un bloque de
c�digo relativamente peque�o puesto a prueba tanto, con verdaderos
ej�rcitos de ingenieros detr�s.  Es de suponer que cada posible camino
de ejecuci�n es puesto a prueba continuamente. Si hay un bug -- y claro
que aparecen -- es de suponer que acabar� sabi�ndose y se reparar�.

Compara la condici�n de esas 50.000 l�neas de c�digo con el c�digo
que... yo escribo. Yo puedo afirmar que si escribo algo para una
empresa, si 5 personas miran y/o ponen mi trabajo a prueba antes de que
se utilice, �es realmente mucho! Y cuando esas 5 personas o menos miran
o prueban el c�digo, es m�s bien superficial. El contraste entre mi
condiciones de trabajo (y como el resultado de mi trabajo se utiliza) y
lo que ocurre con la JVM o el n�cleo de un sistema operativo es casi
imposible de exagerar.

Entonces, el hecho de que los que escriben la JVM tengan sus motivos
leg�timos para trabajar en C, y hasta en ensamblador a veces (pero muy
poco), no dice absolutamente NADA en favor de la idea de que t� y yo
deber�amos trabajar as�, ya que las condiciones b�sicas son tan
distintas.

Por ejemplo, sali� el tema de la verificaci�n de los l�mites de los
arrays. Es muy dif�cil para m� imaginar una situaci�n en que ser�a
responsable trabajar en un lenguaje SIN verificaci�n de l�mites -- por
lo menos, si hubiera la m�s m�nima posibilidad de evitarlo. En realidad,
un m�dico que tomase una decisi�n de un nivel de irresponsabilidad
semejante estar�a sujeto a bastantes consecuencias jur�dicas, creo yo. 

El hecho de que Java elimina la posibilidad de categor�as enteras de
errores es un hecho muy importante. Los estudiantes que hab�is escrito
programas de mil o dos mil l�neas de c�digo sin cometer errores con
punteros deber�ais asumir el hecho que si casi siempre puedes escribir
1000 l�neas sin ese error, la probabilidad de cometer el error nunca es
nula.

Dejo un ejercicio num�rico a los estudiantes entre nosotros.

Supngamos que, 9 veces en 10, puedes escribir 1000 l�neas de c�digo C
sin cometer un error de puntero. 

�Qu� son tus probabilidades de escribir 10.000 l�neas de c�digo C sin
cometer un error de puntero?

�Qu� son las probabilidades de escribir 100.000 l�neas de c�digo C sin
cometer un error de puntero?

(Despu�s, calcula las probabilidad arriba suponiendo -- muy
generosamente -- que puedes escribir 1000 l�neas de c�digo C sin cometer
un error de puntero 99 veces en 100.)

Pensad entonces en el hecho de que tal error es INEVITABLE en C e
IMPOSIBLE en Java. Un ingeniero de verdad (no un chapucero) sabiendo
eso, �qu� herramienta va a escoger?

Espero que esto ayude a la gente con ciertas lagunas conceptuales.

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