PHP 4 en RHEL (y otras distro "enterprise") [Was: Re: Canonical does not contribute to Linux plumbing.]

[Horst H. von Brand]

Rodrigo Fuentealba <the.code.keeper en gmail.com> wrote:
> El día 22 de septiembre de 2008 11:37, Jens Hardings Perl
> <jens en hardings.cl> escribió:
> > On Sun, 2008-09-21 at 23:51 -0400, Horst H. von Brand wrote:

[...]

> Las estrellas de esto se lo llevan la excepcionalmente molesta
> presencia de PHP 4... ¡¡¡tres años después de la presencia de un
> reemplazo 100% superior!!!, pero si RedHat adquirió el compromiso de
                                             ----------------------
                                                 Este es el tema!

> mantenerlo junto con todo el resto por cinco (o eran siete?) años, no
> pueden deshacerse simplemente de ello. Alguna vez discutimos eso en la
> lista con el Doc, y a pesar de que comprendí las razones, no las
> compartía para nada. Es por fortuna que PHP aún mantiene su versión
> 4.4.9, pero ya casi nadie lo mira y llega a dar pena ver código
> escrito en eso.

Has migrado alguna cosilla escrita a la chancha, posiblemente incluso
ex-profeso para ser ilegible ("para proteger nuestra inefable propiedad
intelectual"; si, tambien hay de esos), de PHP 4 a PHP 5? *Duele*! Y si
adquiriste tu distro (al menos en parte) por la /garantia/ de que no
tendras que pasar por esa clase de torturas hasta que _tu_ decidas que es
hora, no cuando tu distro diga que ya esta bueno de arrastrar cierta
tontera an~eja?

> Ahora, tengo una pregunta:
> 
> ¿Existe alguna posibilidad de planificar el diseño de un lenguaje de
> programación teniendo en cuenta la necesidad de mantener la
> compatibilidad hacia atrás?

No creo... los errores de disen~o del lenguaje original nunca podras
corregirlos, y deberas arrastrarlos por los siglos de los siglos en sus
descendientes. Ver p.ej. la precedencia de "=" en C, o su incomprensible
declaracion de tipos; sobreviven en C++. Igualmente, algunas decisiones
idiotas en Perl (manejo de clases) no se pueden corregir sin redisen~o del
lenguaje. Tambien hay discusion detallada de Python 2.6 y 3.0 en
<http://docs.python.org/dev/whatsnew/2.6.html>, detallando la justificacion
de muchos de los cambios al lenguaje.

Como dice el dicho, "Para hacer tortilla, hay que romper huevos".

>                             Se me viene a la mente la figura de hacer
> lo mismo que Solaris, que es binariamente compatible desde tiempos
> inmemoriales.

Vade retro!

[Y me late que tus "inmemoriales" no son tanto tampoco... y es mas un tema
 de seguir manejando formatos de ejecutables y bibliotecas antediluvianos,
 y tener los paquetes del caso. Alan Cox durante an~os mantuvo tarros con
 Linux en formato a.out, que se dejo de usar en serio a fines de los  '90...]

>               ¿Es posible hacer lo mismo con un lenguaje de
> programación? Sí, sé que lo es, pero, ¿existe algún lineamiento a
> seguir para que de como resultado un lenguaje compatible hacia atrás?
> Creo que eso aminoraría en un porcentaje (al menos pequeño) el
> stupidity tax.

Y aumentaria en forma impresionante los impuestos pagados al otro lado de
la cerca. La (dura) experiencia demuestra que no vale la pena. Revisa 
Documentation/stable_api_nonsense.txt en los fuentes del nucleo Linux mas
cercano para detalles. O mira los horrores de seguridad que significa hasta
el dia de hoy en Windows el tener que (en parte) seguir manejando tonteras
de Win95 y anteriores...


Por lo demas, porque complicarse la existencia solo para que otros /no/
paguen el costo de su propia estupidez?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513