Burdjia

Etiqueta JavaScript, 2 entrada(s)

Feed Rss, Atom

Pascal, HTML5 y cubos giratorios

Estaba repasando el foro de Club Delphi cuando llegué, de nuevo, a un artículo de Jon L. Aasenden, un programador con ideas bastante afines a las mías.

El artículo en cuestión habla sobre las posibilidades que tendría poder traducir programas de Pascal a JavaScript.  Alguna vez había pensado yo en ello, y de hecho ya existen cosas similares como Morfik y ExtPascal.

Una de las cosas que menos me gustan de JavaScript (y de PHP) es su poco control sobre los datos.  No me refiero a que no pueda obtenerse información acerca de su tipo y naturaleza, que se puede, sino a que las variables no tienen por qué ser declaradas antes de usarlas y que estas no tengan un tipo concreto, lo cual me ha generado no pocos dolores de cabeza.  Esta característica me hace perder un tiempo precioso intentando descubrir por qué el cálculo no se realiza correctamente o por qué cierto campo se obceca en permanecer vacío; y todo porque obvié incorrectamente el tipo de dato o porque escribí mal el nombre de una variable.  Con Pascal esto no pasa, ya que al tener que declarar las variables y disponer estas de un tipo determinado, si comentes un error al escribir el nombre o asignas un dato de tipo no compatible el sistema te avisa rápidamente y rápidamente corriges el error.  Combinar, por tanto, ambos mundos es una idea que me atrae mucho:  por un lado tienes la universalidad de JavaScript, y por otro la estabilidad y potencia de un lenguaje estructurado como Pascal.

Además de esto, otra cosa que me ha llamado la atención son los varios enlaces que el señor Aasenden coloca al final de su artículo, entre los que hay varios ejemplos de gráficos 3D, con modelos complejos, texturas y materiales, completamente escritos para HTML5; es decir, que se ejecutan en el navegador web sin necesidad de instalar ninguna extensión como Flash o similares. Y me ha llamado la atención porque el pasado noviembre escribí un diminuto programa para HTML5 en 3D, y tenía la intención de publicarlo, pero entre pitos, flautas y que no me centro, lo olvidé. Seguro que si lo hubiera hecho en noviembre, nada más terminarlo, hubiera ganado muchos puntos, pero ese tren ya partió.

En fin: aquí tenéis el nada espectacular ejemplo de gráficos 3D en HTML5 que escribí entonces.  Que conste que no funciona con Internet Explorer, al menos hasta la versión 8 (gracias a Theck, de GAS, por comprobarlo).  El código fuente tiene asociada la licencia zlib/libpng, utiliza conceptos básicos y está profusamente comentado, así que podéis echarle un vistazo sin problemas.

Por qué no confío en los colectores de basuras

No, no me refiero a los abnegados funcionarios que se esfuerzan por mantener limpias nuestras calles.  Me refiero a ciertos mecanismos que disponen algunas implementaciones de ciertos lenguajes tales como JavaScript, Objective C, Java, etc.

Básicamente, el recolector de memoria hace un seguimiento de la memoria utilizada, y se encarga de ir liberando aquella que ya no se usa.  No me voy a meter en una explicación técnica, porque no es el lugar; baste con decir que con un recolector de basuras se libera al programador de la tarea de indicar cuándo liberarla (valga la redundante redundancia de liberar la liberación).  Y esto es bueno, o eso me han dicho.

Ahora bien, llevo unos cuantos años trabajando en una aplicación web para unos clientes de la empresa en la que trabajo.  Es un programa bastante complejo, concretamente un administrador de pedidos con facturación, el cual está escrito en PHP y JavaScript1.  Cuando el proyecto ya alcanzó cierto nivel adquirió como característica que, tras un par de horas de trabajo con el mismo, sufría un decaimiento general en el rendimiento, tardando cada vez más en realizar las operaciones hasta ser prácticamente inutilizable (el programa es usado por el operador durante toda la jornada).

Cuando tuve la oportunidad de estudiar este problema, algo que mis colegas españoles saben que es harto difícil de tener, me di cuenta de que todo el problema estaba en el lado cliente, ya que las consultas al servidor eran suficientemente rápidas.  Aparte de la sobrecarga del microprocesador, la memoria iba creciendo sin descanso a cada operación realizada.  Consulté por aquí y por allá sobre la gestión de memoria en JavaScript, pero en el mejor de los casos se limitaban a venderme lo maravilloso que es tener un recolector de basuras.

Hasta que se me ocurrió que si en este lenguaje hay un new, quizá también hay un delete.  Y resulta que así era.  En ese momento se me terminó el tiempo que podía perder (sic) en el problema, pero cada vez que tenía que hacer alguna modificación al programa procuraba buscar por  los alrededores por si encontraba un buen lugar donde colocar un delete.  En cuanto hube colocado estratégicamente un puñado de ellos, la tendencia del programa a reducir su rendimiento dejó de ser tan patente, llegando a ser utilizable aun tras toda la jornada, y últimamente apenas se observa una reducción de velocidad, salvo si realizas ciertas funciones que no tengo muy claras.  Ahora los problemas que más me preocupan son otros.

Tras esta experiencia, la escasa confianza que ya tenía en estos cachibaches se ha esfumado por completo.  No sólo no voy a volver a confiar de nuevo en ellos, sino que voy a recomendar a diestro y siniestro que no los use nadie.  Y a ello voy:

Destruid los objetos en cuanto no los necesitéis.  Evitad confiar en el colector de basura.  Si el lenguaje no lo implementa, ni se os ocurra instalar o crear una biblioteca para añadírselo (sí, Objective C, estoy hablando de tí).  Y si estáis diseñando un nuevo lenguaje de programación, por favor: no lo hagáis.

Y ya está.


1Para que conste en acta, ya dije cuando me lo propusieron que, en mi opinión, no eran los lenguajes ni la plataforma más acertada para este programa, pero maldito el caso que me hicieron.