Dice la Wikipedia que “Perl es un lenguaje de programación diseñado por Larry Wall en 1987. Perl toma características del lenguaje C, del lenguaje interpretado bourne shell (sh), AWK, sed, Lisp y, en un grado inferior, de muchos otros lenguajes de programación. Estructuralmente, Perl está basado en un estilo de bloques como los del C o AWK, y fue ampliamente adoptado por su destreza en el procesado de texto y no tener ninguna de las limitaciones de los otros lenguajes de script”.
En los sistemas Unix tenemos a Perl como una de las herramientas básicas y ahora, la versión 1.7 del compilador optimizado Perl 5 a C/C++, llamado Tycho, ha sido liberada este mes. El tema que trata de solucionar RPerl es el bajo desempeño, el cual no es un problema en la mayoría de los casos pero prohibitivo si se trata de los sistemas en tiempo real.
Perl da algunas cosas por otras, por ejemplo, no es veloz pero a cambio es flexible y toma en cuenta muchos detalles que los programadores muchas veces están obligados a considerar, por ejemplo la conversión de tipos, entre otros. Otro problema es que Perl no genera ByteCode, para que éste corra en una máquina virtual, sino que hace algo que se llama Op-tree, el cual tiene un conjunto muy complicado de instrucciones. Si generase ByteCode probablemente sería mucho más fácil de interpretarlo en una VM (máquina virtual), como RPython o LLVM, algo que sin duda haría que mejorara su desempeño en términos de velocidad al menos.
Esto, sin embargo, no es tan fácil de hacer porque re-escribir las funciones internas de Perl parece ser una tarea ingrata y muy compleja, además de que llevaría mucho tiempo. Esto, de hecho, fue el camino que tomó Perl 6, intentando empezar con una base de código limpia y no importándole demasiado la compatibilidad hacia atrás, emitiendo ByteCode para MoarVM o JVM. Para Larry Wall, este es “Perl 5 bien hecho”, sugiriendo así que Perl 6 es un intento de corregir todos los errores de diseño de Perl 5.
Una alternativa, sin embargo, es trabajar con una versión recortada o un subconjunto de Perl, que puede ser compilado a C o incluso generar ByteCode. Esto es lo que ya pasaba cuando el compilador Perlito, que traduce Perl a Javascript paa el backend V8 o Python, para el backend RPython. Hubo además otros intentos de convertir el código op-tree a ByteCode, a partir de los módulos B::Bytecode, pero este ByteCode no se intentaba usar en una VM, sino para mandar el op-tree al disco de manera que pudiese cargarse más tarde e interpretarse de nuevo, de forma que se convirtiese en una plataforma más independiente.
También se tiene la traducción a código nativo, que se hizo usando perlcc -el compilador-de-perl-a-c, pero este programa estaba plagado de dificultades y tuvo poco éxito.
Ahora la idea es usar RPerl, la cual es similar a perlcc, pero para el conjunto que puede ser compilador estáticamente. La R de RPerl es precisamente por Restricted Perl. De esta manera, por una parte, la de no tener que reescribir el código interno de Perl y además, el poder darle más flexibilidad lidiando solamente con la parte que se compila estáticamente. Claramente el código escrito para RPerl no puede usar algunas características de Perl, pero puede ser una buena solución en muchos casos.
En algunas pruebas características de velocidad, podemos ver que el algoritmo de la burbuja (para ordenar datos), lleva 15 segundos en completarse, mientras que con RPerl solamente requiere de 0.04 segundos. Bastante impresionante.
Referencias:
RPerl sitio oficial
Aprendiendo RPerl
RPerl en Kickstarter
RPerl en GitHub
i-programmer