On Mon, 2006-10-23 at 14:00 -0300, Horst H. von Brand wrote: > Juan MartÃnez <[EMAIL PROTECTED]> wrote: > [...] > > Un lenguaje compilado, en general, siempre (o casi siempre) sera la > > mejor alternativa a usar. > [...] > > Sobre todo si es para un sistema complejo > > (un SIA por ejemplo), dado que será mas rapido que un lenguaje > > interpretado. > > Lo cual es totalmente irrelevante. Que el SIA se demore 0,5s o 0,01s en > responder, si el perejil en la pagina web al otro lado de Chile luego pasa > 5s pensando que hacer a continuacion no hace particular diferencia. Si, si > tienes decenas de miles de usuarios simultaneos es vital, pero eso se da > solo cuando muestran los resultados de las elecciones ;-) > > [Si, /hay/ casos en los cuales el rendimiento realmente es crucial, pero > son muchisisimos menos de lo que uno cree. Ve y mira la carga en tu > "servidor" vecino, rara vez pasa del 40% en mi experiencia, tipicamente > mucho menos...]
Esa postura, que si bien comparto en parte, es peligrosa. Sobre todo en manos inexpertas que pueden creerte a ojos cerrado todo lo que dices. Bajo esa lógica, hay muchos /ingenieros de software/ que los problemas de rendimiento se lo achacan a la máquina, al sistema operativo, al motor de base de datos o a lo "complejo del sistema". Jamás al mal diseño de sus algoritmos o de la lógica retorcida de sus propios programas. Indices? "Para qué, si el motor se supone que es potente, corre en una máquina de 4 procesadores y 16 GB de RAM". 200 usuarios? "Es que eso es mucha carga para todo sistema". Y si tarda 1 ó 2 horas es "porque es muy complejo". Eso escapa al lenguaje, escapa incluso si es compilado o interpretado. Y aunque las HH sean más caras, cuando esas HH te exigen aumentar el HW una vez al año a una potencia 4 veces mayor... -- Germán Poó-Caamaño http://www.ubiobio.cl/~gpoo/ Concepción - Chile
