22 nov. 2009

a picture is worth a thousand words

This week in the Perl world we have seen two events that I believe are very important:

  1. new look and content in http://www.perl.org
  2. new blogging system at http://blogs.perl.org

Such actions are those that cause direct impact on the community attraction, so my sincere congratulations to all involved in them.


In my opinion, Perl has an enormous inner strength, that with relatively little effort may be evident in a simple way to everyone else.
I'm sure when we try to justify the revival of Perl, these two events will be listed.

Good work!

17 nov. 2009

choosing a bad module name... Modern::Perl?

I have been using Modern::Perl, and it's great. In a unique and single line you can enable all the nice and "modern" features.

But, in my opinion, the name of this module was bad selected.

Why?

Currently the meaning of modern perl is matched 100% by this module, and this it's Ok; but in 2020 (for instance), modern Perl won't be achieved with Modern::Perl, and we will need other module, similar but different...

The name is nice, but sometimes we have to think in this kind of tips.

11 nov. 2009

perl story

In my work, I have a reputation of data-problematic-related fast resolver. Yesterday, I received a ZIP file with 200 Excel files. The problem: each XLS file had a close but different format, with columns changed or dropped. They wanted a complex report with the result of joining all files (in the correct way).

So I wrote a script with Spreadsheet::ParseExcel (I've used it before), and in a few minutes I had a script that extracted the information and merged it in a simple CSV file. Then I did an import process in Excel and generate the report with dynamic tables. Success!

Perl saved me hours of work (tedious) and made me happy. I often use Perl in this way, doing load, extraction and transformation tasks. I often write little scripts that simplify my work and increase my productivity. That's the reason because I have to resolve many problems of this kind every day ... and I like it.

31 oct. 2009

Why should I choose Perl over PHP?

A friend of mine, who loves PHP, often tries to convince me to write Web apps in PHP. He knows I am a Perl lover, and I just say: "PHP doesn't like me". But next time he tries it hard, I'd like to put him in troubles with a detailed and specific list of features or issues about Perl-vs-PHP topic.
I think experienced programmers appreciate the huge list of features and options available with Perl.
I want to write a list of PHP problems to argue convincingly with my friend.

Could you help me with your opinions?


25 oct. 2009

Choosing a worker with Perl background

Sometimes, I have to participate in interviews with people who wants to work in my company. We have a heterogeneus environment, with many different technologies involved.

In any case, I prefer to choose a worker with Perl background, why?
  1. We use Perl in many places
  2. If we don't use Perl, I have experimented that people with Perl skills can make a good work in a short period of time
  3. Their mind handles different concepts in a simple and consistent way, and designs they provided are good.
  4. They can work without problems in more than one project at the same time.
  5. In general, their projects are cheaper to maintain (beacuse of 3).
In short,
$my_opinion_about_worker++ if( $perl_background );

22 oct. 2009

Perl6 - Rakudo #22

Hello, I've just read the Rakudo#22 announcement (http://rakudo.org/node/57), and there is a lot of new improvements. In my opinion, the most important is the first one:

"Rakudo is now passing 32,582 spectests, an increase of 17,085 passing tests since the September 2009 release. With this release Rakudo is now passing 85.0% of the available spectest suite".

Wow! 85%! This is very impressive! But, what does this mean?
1. We are running fast to the 1.0 release
2. The spectest is not complete
3. The remaining 15% is complex
4. All options (1-3) are true

19 oct. 2009

Perl QT

Ten years ago, I wrote my first GUI application, using C++ and QT. This framework made easy my work, and I got a good interface with a little ammount of effort. I love it.

Now, I have to write a GUI, and I can use any language (it's my choice). I'd like to use Perl with QT, but the PerlQt project (http://perlqt.sourceforge.net/) seems to be paused (last revision: Sept, 2003).

I know there are other options like Tk, WxWidget, but if I'd like to use QT, Perl won't be my choice. I have to use C++ or Java.

12 oct. 2009

CPAN download counter

Hi, I recently released my first CPAN module, called SQL::Template. It was a nice experience, because I had to get a new CPAN pause account, and follow the publish procedure.

Then, I posted a message in this blog and have been waiting for feedback. No results, no comments, no news, no bugs in RT...

In IRC channel, I asked if there is any method of getting the number of downloads of my module. A guy said me "no, beacuse CPAN is a highly distributed system, and there isn't a stats collect process".

I accept this answer, but I'd like to have a metric about the number of downloads or visits that a resource have in CPAN. The exact total number it's hard to get, but any accurately procedure should be investigated. For example, stats from http://search.cpan.org.


9 oct. 2009

Should Perl5 "stole" other languages features?

In a recent group conversation, a friend of mine was talking about features that his favourite programing language (Java) have to include, "stole" from other languages. Another guy tell us other things for his option (Ruby), and so on.

When they ask me about nice features that I would like to have in Perl, I said: well, we don't need to borrow any one from others... In Perl5 we have stolen the nice features from Perl6 !

What do you think? Should Perl5 stole any feature from other languages?

5 oct. 2009

SQL::Template 0.1.0 released

Imagine this situation: you know DBI and you like it, because you can make use of your SQL knowledge. But you are not happy having the SQL code into the Perl code. You can use other CPAN modules, which let us to abstract SQL code. But we want to write SQL code, we feel confortable with it.

The SQL::Template module manages this ideas:

  • decoupling SQL sentences from Perl code, writting sentences in a XML file, that you can use in different parts of your code.
  • Dynamic test of expressions.
  • Reuse of SQL fragments.
  • Simple API (very close to DBI).

I invite you to see and use this module (it's production ready). Comments are welcome.


2 oct. 2009

Why Perl6 won't replace Perl5?

Because most of Perl5 programmers aren't going to change a working language with a lot of tools and new enhacements by a new venturesome platform.

Perl6 must look for new people from Ruby, Python (and others) areas; IMO, if it hopes that Perl5 people will use Perl6, it will fail (at least, in next 3-4 years).

And there is a serious risk: Java 7 will have dynamic language support, so it will be hard to compete for Perl6.

I'd like to be wrong. What do you think?

29 sept. 2009

Why PHP is not my favourite language?

Because I'm not a web application developer; I'm an enterprise application developer, who sometimes writes Web apps. So I use Perl.

What are your reasons?

24 sept. 2009

Why Perl is my favourite language?

"Because it's different, like me"

Please, post your answer to this question, I'll make a resume with them. Thank you!

18 sept. 2009

21 - Perl 6

Hola, acaba de salir reciente la última compilación 21 de Rakudo, la implementación de referencia de Perl6. Siempre me ha gustado el 21, quizás por ser el siglo en el que estamos, quizás porque es el día en que cambian las estaciones del año, quizás porque fue el dorsal con el que Perico Delgado ganó aquel mítico Tour de Francia del 88, quien sabe.

Bromas aparte, creo que ya podemos usar una versión bastante evolucionada de la implementación (no para producción, a mi juicio), para ir probando y saboreando sus nuevas características y empezar a escribir al respecto. Sí, ha llegado ese momento largamente esperado de arremangarse y adentrarse en las aguas aún poco profundas del lenguaje.

El aprendizaje de un nuevo lenguaje nunca me ha preocupado, he llegado a utilizar demasiados como C, C++, Fortran, Basic, Pascal, Perl 5, Java, C#, Groovy, y unos cuantos ensambladores (x86, 68000, MIPS) todos ellos con cierto nivel de profundidad, y en algunos casos con mucho conocimiento. La verdad es que es algo que me llama la atención y me gusta. Ojala pudiese aprender idiomas con la misma facilidad. Ahora llega el momento de coger las riendas de un nuevo caballo llamado Rakudo y me dispongo a disfrutar de la montura, los comienzos serán un momento perfecto para adaptarnos mutuamente. Sí digo bien, adaptarnos.... quiero probar eso de poder hacer mutaciones a mi gusto y tener mi dialecto. Creo que el tema de los DSL es algo muy importante para los próximos años.

Por otro lado, y es lo que más me preocupa, es que un lenguaje pese a que es fácil de aprender, donde muestra su potencial es en el conjunto de librerías y utilidades que lo complementan.... mucho trabajo por hacer aquí hasta que haya un CPAN6 decente y usable... ahí es donde hay que centrar el esfuerzo en los próximos 2 años, en mi opinión.

Bueno, me auto-deseo suerte, valor y ... al Rakudo!
¿Te animas?



11 sept. 2009

I have an idea (2)

How can we improve the use of Perl ?

This is a simple question, many peope has answered it, and in this article I'm going to present my idea in this area.

Often, we say that CPAN is our main tool in order to develop some kind of solution, and we are right. But CPAN provides many different ways to do the same thing, someones are good and others aren't (TIMTOWTDI). CPAN should show the number of downloads of each distribution, and the activity (number of changes per unit of time). We are lazy, I know; but comments in modules and feedback are wellcome.

With this tools (Perl+CPAN), we need to build applications. Reference applications. There's a few in my opinion. In different areas (not only Web, we are tired). If we can create a set of modelic applications, people will ask for the tools used to build them. This is a very important thing: define a collection of important projects, and assign a development group.

We need to be present at the cloud! it's time for it!

5 sept. 2009

I have an idea (1)

Until now, I have written my posts in Spanish. My first idea is turn to English in order to allow more people will be able to read this blog. So, I hope my poor English level won't be an obstable.
With this "I have an idea" series, I try to explain some ideas that cross my mind. Sometimes they will be crazy, or boring, or interesting.

The first idea title: "PSR - Perl Specification Request". Last years, we are experimenting a slow and progressive descrease of Perl-enterpise use. Other platforms like JEE and .NET are growing. We need to improve our presence in this scenario, but how? Perhaps we can pay attention to success projects in this area, and create or improve similar things in our environment. For example, I like the EJB3 model in JEE to build enterprise applications, covering topics like scalability, security, transactions, etc. There is a set of specifications for EJB3, and many providers have built their products according with them.

Perl6 introduced a new concept in our world: specification. Rakudo is one implementation of that one. This is a very important thing, we should use. Why not create a PSR group? His job will be create the specification of hot topic areas, like web objects, persistence, rules, busines process model, validation, etc. The each group of people will implement their own solution. The PSR could propose a test-suite in order to ensure the implementation is correct.

This is a simple idea, but with a big amount of work to do:
  • Organizative, in order to identify the specification areas, the specification propossal procedure, the interfaces between specifications, the work plan and scheduled tasks
  • Technical, with two levels: first the specification group, which makes the interface definition, defines the funcionality and build the test suite. Second, the workgroup that implements the specification
I think we need to improve in a organizated way, and perhaps this idea may be a good starting point in order to define a scenario in which we will feel confortable. Rakudo will be probably released next spring, and this will be a good starting point. The specification model I have proposed may be the main concept to build CPAN 2.0.

What do you think?

3 sept. 2009

Proxy object

Los objetos proxy constituyen un concepto avanzado que se asemeja por completo a los más conocidos servidores proxy, los cuales actúan como intermediarios entre el cliente y el servidor. En nuestro caso, un objeto proxy constituye una especie de envoltorio "invisible" (wrapper) sobre un objeto que es el que al final queremos invocar.

Probablemente te preguntes para qué te sirve esto, la verdad es que cuando se conoce bien, uno se pregunta como es posible no haber conocido de su existencia previamente. En resumidas cuentas, siempre que tengamos que hacer algo adicional a una simple llamada a un método de un objeto, el Proxy es un buen candidato a cubrir esta necesidad.

Una razón para controlar el acceso a un objeto, es precisamente aplazar la creación e inicialización del mismo hasta que realmente lo necesitamos (obviamente en aquellos casos en los cuales esto tenga un coste significativo). Un ejemplo puede ser la carga de un documento que contiene además de texto, multitud de imágenes incrustadas. Obviamente no es necesario cargar todas las imágenes al principio, ya que con un alto grado de probabilidad no serán utilizadas inmediatamente. En este caso, conviene realizar la carga bajo demanda, y es donde entra el Proxy ya que a todos los efectos se puede considerar como un objeto del tipo que enmascara (Imagen) pero con capacidad de programar e interceptar la llamada al método que deseemos. Imaginemos que el método es "draw", en este caso aprovechamos en el proxy para crear el objeto Imagen y a continuación invocar a "draw".

Según el tipo de uso, hay gente que clasifica los objetos Proxy en alguna de las siguientes categorías:
  • Remote proxy, que se encarga de codificar la petición y sus argumentos para enviar la solicitud y recibir la respuesta del objeto real. Un ejemplo de esto suelen ser las llamadas a Web Services, que nos aislan de toda la complejidad de tratar con las peticiones sobre la capa de transporte elegida (http, smtp, ...)
  • Virtual proxy, para dotar de un nivel de cache al objeto que se está llamado. Imagina aquellas situaciones en las cuales la respuesta del objeto real es la misma ante la misma entrada, el proxy puede cachear las respuestas e invalidar las mismas en base a determinados criterios
  • Protection proxy, para verificar si la llamada tiene suficientes privilegios como para poder realizarse

Bueno, vista la parte "teórica", quizás esté bien ver un poco de código ¿no crees?

package Proxy;
use strict;
use Carp;
use UNIVERSAL qw/can/;


our $AUTOLOAD;


sub new {
my ($class, $target) = @_;
return bless {TARGET=>$target}, $class;
}


sub isa {
my $self = shift;
return $self->{TARGET}->isa(@_);
}


sub AUTOLOAD {
my $self = shift;
my @params = @_;
my $method = substr($AUTOLOAD,7);
return if( $method eq 'DESTROY' );
my $target = $self->{TARGET};
if( defined $target ) {
if( UNIVERSAL::can($target, $method) ) {
return $target->$method(@params);
}
else {
croak "Proxy target doesn't support $method method";
}
}
else {
croak "Proxy target hasn't been set $target";
}
}

1;

Como puedes observar, se trata de la definición de un módulo Proxy que hace uso del método especial AUTOLOAD de Perl. Recuerda, esta función (si existe) se llama cada vez que no se encuentra un método que se está intentando llamar. En AUTOLOAD, simplemente se verifica que el método existe en el objeto destino, y si es así, se llama.
Para probar esto, imaginemos que tenemos otra clase Persona, muy sencilla (con ayuda de Class::Accessor):

package Persona;
use base qw(Class::Accessor);


Persona->mk_accessors(qw(name role salary));

1;


Bueno, hasta ahora nada del otro mundo. Imaginemos ahora que nos piden que la propiedad "salary", cada vez que sea consultada, debe quedar constancia en un fichero de quien lo hizo. Nuestra primera intención podría ser ir a tocar la clase Persona y meter el código donde corresponda. Sin embargo, a mi juicio, eso "ensuciaría" la clase con cuestiones que no le son propias. Y además para algo tengo que utilizar el tema del Proxy, que para eso lo he explicado...

En primer lugar, creamos una clase que hereda de la anterior y que hace el trabajo de log en el fichero:
package Proxy::Persona;

use base 'Proxy';
use strict;
use autodie;

sub salary {
my $self = shift;
my @params = @_;
if( @params ) {
$self->{TARGET}->salary($params[0]);
}
else {
open my $fh, ">>person.txt";
my @now = localtime(time);
printf $fh "[%02d-%02d-%d] %10s %s\n", $now[3], 1+$now[4], 1900+$now[5], getlogin, $self->{TARGET}->salary;
close $fh;

return $self->{TARGET}->salary;
}
}
1;


Y a continucación creamos un fichero para probar que esto ha funcionado:
use Persona;
use Proxy::Persona;

$p = new Persona;

$p->name('JOSE');
$p->role('MANAGER');
$p->salary(2000);

$x = Proxy::Persona->new($p);
print "Salario: ", $x->salary(), "\n";


Precisamente el último print, es el que sirve para llamar al método proxetizado y hacer el log. Cualquier otra llamada a cualquier otro método de la clase Persona, se llama sin mayor actuación. Es de destacar:

  • La clase target (Persona) no se ha modificado para nada
  • El script que utiliza la clase proxy debe ser modificado ligeramente para crear un objeto de la clase Proxy::Persona
  • Toda la funcionalidad que deseemos añadir, figura en la clase Proxy::Persona, con lo cual queda mucho más limpio el resto del código que empleamos.

Bien, espero que con esta pequeña aportación, haya quedado mucho más claro para que sirve y cómo podemos beneficiarnos del uso del patrón Proxy.

Me gustaría conocer tus opiniones, no únicamente de este tema, sino de la línea de los artículos, o si hay algún tema que sea de tu interés y que pudiese ser motivo de una entrada. ¡Animo!

30 ago. 2009

Empaquetado con PAR

Durante mucho tiempo, el uso de los diferentes módulos que tenemos a nuestra disposición a través del CPAN nos creaba un pequeños handicap: cuando tenemos que distribuir nuestro programa, es necesario asegurar que todas las dependencias están disponibles para poder ser empleadas. Esto, que a priori debería ser algo sencillo, no ha quedado bien resuelto hasta la aparición del Perl Archiver (PAR). En resumidas cuentas, PAR nos permite agrupar todos los módulos, ficheros de configuración, recursos y otras dependencias en un único fichero comprimido, para facilitar su distribución.
Imagino que a los que trabajen con Java les resultará familiar este concepto, incluso el nombre que se utiliza es similar (JAR, Java Archiver), que se inspira obviamente en el archiconocido TAR.

En este artículo trataré de resumir las opciones más importantes de cara al uso de esta estupenda herramienta, que pasa por ser un tanto desconocida pese a que tiene sus orígenes por el año 2003.

Crear un fichero PAR


(a) El caso sencillo
Un fichero PAR está comprimido en un formato ZIP, por tanto podremos utilizar nuestra herramienta preferida que maneja este tipo de formatos (por ejemplo, el comando "zip" en Linux, o 7-zip en Windows). Imaginemos que deseamos crear el fichero "prueba.par", con un par de módulos de contenido
%> zip prueba.par Modulo1.pm Prueba/Modulo2.pm
Como vemos, podemos (y debemos) incluir las estructuras de directorios que estemos utilizando.

(b) Algo más habitual...
Aunque crear un fichero de esta forma es muy sencillo, en aquellos casos en los cuales tengamos un programa complejo que requiera localizar las dependencias de módulos que tiene, puede llegar a ser tedioso, sobre todo cuando además realizamos cambios en el programa que afectan a esas dependencias. Para estos casos disponemos de una utilidad, el PAR Packager (pp) que se encarga de realizar este tipo de tareas, y que obviamente sólo hay que tener instalado en el equipo de desarrollo, no en los usuarios del fichero PAR que construyamos.
Imagina que partimos del "programa.pl" y que deseamos encontrar todas sus dependencias y empaquetarlas en un fichero PAR; simplemente hacemos:

%> pp -p -o programa.par programa.pl

Con "-o" especificamos el fichero PAR de salida que se genera, y "-p" indicamos que deseamos generar un fichero PAR. En este ejemplo, el fichero "programa.par" contiene por tanto, todas las dependencias que se han encontrado. Este fichero se puede utilizar así:
  1. Para visualizarlo, con nuestra herramienta ZIP favorita
  2. Para utilizar los recursos que contiene desde otro programa, como se mostrará más adelante
  3. Para ejecutarlo directamente, ya que el fichero PAR creado de la forma anterior ha incluido el fichero "programa.pl" dentro del mismo, si tenemos instalado el PAR Packager, podemos probarlo sin más que escribir:

  4. parl programa.par

  5. Si queremos distribuirlo a un equipo en el cual no tenemos PAR PAckager, pero sí PAR, podemos usar la opción "-P" cuando lo creamos
  6. %> pp -P -o programa_empaquetado.pl programa.pl
    %> perl programa_empaquetado.pl
(c) Crear un fichero ejecutable "stand-alone"
Una posibilidad muy interesante que nos proporciona el uso de PAR es la capacidad de crear ejecutables que puedan ser utilizados en plataformas donde ni siquiera se ha instalado Perl. Esto es un concepto bastante interesante cuando queremos asegurarnos de que nuestro programa funciona en cualquier sitio, aunque un pequeño detalle es que sólo funcionará en la misma arquitectura en la que fue construido. La herramienta que utilizamos para esto sigue siendo obviamente, "pp".
Siguiendo con los ejemplos anteriores, podemos hacer esto:

pp -o programa programa.pl       # en Linux
pp -o programa.exe programa.pl # en Windows

Usar un fichero PAR

Una ver que disponemos del fichero PAR con un conjunto de módulos, si lo queremos emplear desde nuestro programa, debemos tener instalado en nuestro sistema el módulo PAR, que lo podemos realizar a través del CPAN, como otro módulo normal.

En nuestro programa debemos hacer entonces (siguiendo con el ejemplo "prueba.par"):
use PAR "ejemplo.par";
use Prueba::Modulo2;
#...
Como vemos, todo lo necesario está en el fichero ".par", y si queremos ubicarlo en una ubicación específica lo podemos hacer sin más que especificarlo a la hora de utilizarlo:

use PAR "/la/ruta/del/fichero/par/ejemplo.par";
use Prueba::Modulo2;
#...

Referencias

Si deseas profundizar, te recomiendo una serie de lecturas:

¿Cuáles son tus experiencias en la distribución de tu código Perl?

28 ago. 2009

El sentido común

Una de mis aficiones consiste en jugar al ajedrez, y hace unos cuantos años, cayó en mis manos un manual titulado "El sentido común en ajedrez", de Emanuel Lasker, probablemente uno de los mejores (quizás el número uno) de entre todos los campones de este deporte. Este libro era sencillo, directo y servía para hacer fácil aquellas cosas que podían parecer complicadas en un principio.

Te preguntarás ¿que tiene que ver esto con Perl? Bueno, la verdad que me apetecía contarlo, porque esta tarde encontré en mi estantería este libro, y me ha hecho recordar lo bien que me lo pasé cuando lo leí, hará unos 20 años (!). E inmediatamente, he recordado un módulo curioso y más que recomendable: common::sense. Por tanto el nexo de unión entre el ajedrez y Perl en este artículo reside precisamente en el uso del menos común de todos los sentidos.

Pero, ¿en qué consiste el sentido común en Perl? Llevamos ya un tiempecito con la versión 5.10 del lenguaje, y muchos no hacemos uso de una serie de características nuevas (no presentes anteriormentem y que por tanto harían que los scripts no funcionasen en plataformas antiguas).

use common::sense;

# Es lo mismo que:
#
# use strict qw(vars subs);
# use feature qw(say state switch);
# no warnings;

como podemos observar, hay un par de curiosidades en el módulo:
  1. no warnings, parece contrario a lo que uno inicialmente puede pensar, pero tiene su lógica. La activación de warnings debería afectar únicamente a aquellas partes del código que el programador tiene bajo su control, no a aquellas pertenecientes a los módulos que está utilizando. Por tanto, si se activa el flag "-w", hay que asegurar que no va a tener implicaciones en nuestro módulo para que no aporte mensajes que no deberían preocupar al programador que lo use.
  2. use feature, para poder emplear las nuevas características de la versión 5.10 (las cuales no están disponibles si no se las activa de esta manera). Son las siguientes:
  • say: es lo mismo que hacer un print añadiendo un "\n" al final de forma implícita.
  • state: viene a ser un equivalente de las variables de tipo static en C o en Java, es decir se crea e inicializa una única vez
  • switch: el tan debatido largamente control de flujo de tipo switch, que tiene eso sí una implementación avanzada, donde podemos incluso utilizar expresiones regulares
Cabe recordar que la versión 5.10 trae unas cuantas cosas más, y si las queremos activar todas, basta con hacer esto:

use feature qw(:5.10);

¿y tú, haces uso del sentido común que te propongo?


26 ago. 2009

Renacimiento

Al igual que la humanidad vivió su época de revitalización cultural en la etapa del Renacimiento, podemos decir que estamos experimentando algo similar en el mundo Perl.
Durante unos cuantos años, hemos podido observar una lenta pero progresiva pérdida de importancia o notoriedad de nuestro viejo y querido lenguaje. Quizás vivimos un mundo en el cual nos hemos acostumbrado a versiones frecuentes en las herramientas que usamos, y en el momento que no se producen nos surgen dudas sobre su viabilidad, y en seguida se oyen los cantos de sirena "... is dead".

Si bien es cierto que no hemos experimentado un crecimiento significativo en estos años, podemos afirmar que el lenguaje se ha ido dotando de una serie de elementos que lo mantienen muy vivo y en buena forma para afrontar los problemas presentes y futuros. Algunos de estos elementos que comento son los siguientes:
  • CPAN, el pozo de la sabiduría donde uno puede encontrar un módulo para prácticamente cualquier cosa que se le ocurra. Algunos argumentan con razón, que se trata de la killer-app de Perl, en el sentido de que la mayor parte del esfuerzo de la gente se ha centrado en enriquecer CPAN. De hecho, todas aquellas características que se añaden en el core del intérprete, han sido previamente probadas a través de algún módulo publicado en el CPAN.
  • Moose, por fin una forma de programar orientado a objetos que ha sido muy bien diseñada e implementada
  • Padre, un IDE para Perl. Esto sí que es algo que sabrán apreciar todos los programadores acostumbrados a las facilidades que nos da un entorno de este tipo. Aunque está en sus etapas iniciales, ya se puede utilizar y comprobar su potencial
  • Devel::Declare, una forma de modificar el comportamiento de Perl en tiempo de compilación sin necesidad de utilizar filtros de código fuente (que por cierto es otra técnica muy potente, si quieres profundizar, mira el módulo Filter::Simple). Permite tomar el control del parser, con lo cual es posible crear nuevas sintaxis... imagina el potencial de esto
  • Perl 6. Bueno, esto será motivo de una serie de artículos... En cualquier caso, hay que estar preparados para la nueva versión de Perl anunciada para Abril del 2010. En realidad no es un sustituto de Perl 5, ya que éste seguirá su progresión (acaba de salir la versión 5.10.1). Se trata de un nuevo concepto, un nuevo diseño y una nueva implementación que se basa en una máquina virtual Parrot especializada en la ejecución de lenguajes dinámicos. Cuando salga la versión 1.0 de Rakudo (así es como se ha denominado la implementación de referencia de Perl6) habrán transcurrido 10 años desde su concepción original.

A mí particularmente hay una razón de tipo sentimental que me refuerza en el pensamiento que da título al artículo. Creo que toda la gente que trabaja con Perl siente algo especial por este lenguaje, algo que no he percibido en los entornos de otros lenguajes (y conozco unos cuantos). Por eso estoy seguro que Perl está vivo, incluso más vivo que nunca. Dentro de 20 años no sé como se programará o cuales serán las técnicas al uso, pero se que se podrá hacer fácilmente en Perl.

Hay muchas otras razones que sirven para reforzar el mensaje del renacimiento de Perl. Si quieres profundizar en ellas, te recomiendo la lectura de este artículo (escrito por chromatic, un referente de Perl).

¿Cuáles son las tuyas?