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!

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.

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.

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?

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 );

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

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.

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.

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?

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.