This week's post was supposed to be about something entirely different, but I had a huge “WOW!” moment today that I just need to share. So I had to write a quick web scraping script but I happened to be working on a new Win32 machine that did not have Perl installed yet. I installed the latest Strawberry Perl and since I did not have a text editor configured on that machine either decided I will get Padre as well. I typed “cpan Padre” and I watched all of Padre's dependencies install flawlessly without a hitch. For the first time ever. In my lifetime. (Padre itself did fail a bunch of tests, so in the end I had to force install it anyway, but Padre has never been advertised as stable software anyway). So just for the sake of it, I went on and typed “cpan Catalyst::Devel”, to see what's going to happen with a distribution that has traditionally been a huge pain to install on Windows. Catalyst::Runtime failed with two tests (out of a bazillion). Everything else installed like magic.

For many of you Unix people it may not be entirely obvious why this is such a huge deal to me. Until a year ago I was an ActiveState user that had for ages been used to enjoying only the portion of CPAN that made its way to the public PPM repositories. Then, about an year ago, I had to make a fresh installation of Perl on a new PC and I decided to give Strawberry a go. And lo and behold, I was initiated into a world where I could install anything I fancied, where I could always update to the latest bugfix release of the module I was using, and where I could play with all the cool brand new stuff people blogged about.

Except too much stuff would just fail to install. I had to track down bugs all the time. I had to force install virtually everything – and sometimes even that would not help.

Until today. This is the first time I have had to do a fresh install of Perl in a year, and the comparison in the experience made me realize what staggering progress has been made since. I literally could not believe the install results I saw. They are not perfect yet, and honestly I do not think they will ever be, but they are certainly damn near perfect!

So although Thanksgiving Day was more than a week ago, I would like to thank Adam and Curtis, and everybody else in the Strawberry Perl team, and the hundreds of people who wire tests and fix bugs and report bugs and make Perl happen, for the tremendous efforts you are investing and the tremendous results you are producing. Your efforts are not unnoticed.

A string of health problems kept me from coding and blogging for more than a month but I am finally back on track now and starting to work on my projects again.

I just released a new version of Miril, the static content management system, to CPAN, and while it does not contain any new features, it has seen a great deal of refactoring to make the code easier to read, as well as the addition of some developer documentation in Miril::Hacking. Hopefully this would make it a bit easier for others to join in.

The two big issues that are next on the table are a rewrite of the current storage engine to make it easier to edit content directly in the plain-text files, and addition of form validation (a more detailed roadmap is available at the github wiki: http://wiki.github.com/pshangov/miril). After that, there will be a new period of testing and refactoring, to prepare the code for version 1.0.

A couple of weeks ago Microsoft launched its WebsiteSpark initiative in an effort to gain some inroads into the market share of the open-source web development stack. The Redmont giant, however, has got it wrong again. The thing is, people choose open source not only because the initial licensing costs are lower, but because it provides certain types of benefits that closed-source simply cannot provide, no matter at what cost.

Recently I had to do some hacking on a .NET web project I'd worked on several months ago. I lost one full day of my precious time struggling with an inane problem related to the way .NET works with configuration files in multiple projects within the same assembly. Which reminded me why closed source software can be such a painful experience:

1. You cannot ask about it. While most aspects of the platform are pretty well documented, every now and then (and always more often then you expect) you end up working with some niche or very new technology that is not very well documented. And when you get stuck with closed source software you get stuck big time. The docs are scarce and not very comprehensible, and make not mention of that specific issue that is bugging you. Since this is closed source software, the only people who really grok it are those who wrote it, and if they are silent, suddenly there is no info in the forums and the mailing lists are dead. Closed source drastically limits the potential number of experts in a given technology – this number is based on the resources and priorities of the developing company and not on the relative importance of the technology itself.
2. You cannot see it, and you cannot debug it. You know something is going wrong, you are probably not passing the correct parameter or have failed to allocate some resource, but you can never know. Everything is as documented, everything should work fine, but it does not. And there is no error message or it is useless. That library you are using is like a big black hole – it sucks in your input, returning nothing, and you have absolutely no idea why.
3. You cannot fix it. Sometimes inheritance is not good enough. You need that one extra feature but there is no sane way to add it to the existing library. You end up writing your own library from scratch just because of that one issue.

Admittedly, such issues do not arise that often. But based on my experience, a) they arise more often then when working with open source tools, and b) they take vastly more time to resolve then when working with open source tools. Perl was my first programming language. At one point in my development as a perl programmer, I started to realize that perl's libraries on CPAN are not perfect at all – even in the most widely used ones I would discover bugs and essential missing features. I was frustrated at first that I have to struggle to read through source code when the documentation is lacking. I was frustrated that I had to write patches for problems that I felt others should have fixed already. It was not until I stated doing serious programming in C# that I realized that commercial closed source development tools, despite the financial backing that they have, suffer from these same issue, and you are even more frustrated that you cannot even read through the source code or submit patches.

Microsoft's profits come from selling licenses for the OS and Visual Studio, it gets no direct earnings from .NET itself. If they really want to appeal to open source developers, they should act bold and open up the source of as much of the .NET stack as possible.

Everybody likes screenshots, so here are some of Miril, the static content management system written in perl:

The main list of all posts:

Create a new post:

Search:

Lists of all files:

Account settings (apparently a little bit broken right now...):

The UI is based on the Flashyweb theme by NodeThirtyThree.

I am proud to announce the availability on CPAN of my latest project, Miril. Miril is a static content management system – it takes data from some source, e.g. a database or plain-text files, and generates static html. What makes Miril different from other tools that do a similar job (such as ruby's Jekyll or homegrown solutions using the Template Toolkit), is that it provides a nice user interface for editing and managing content and you can safely install it for non-geeks to use.

Yet another CMS???

Like all good software, Miril was born out of frustration. Most modern content management systems share two fundamental characteristics that I do not particularly like:

• They are either written in PHP or they are exceptionally difficult to deploy (or impossible to deploy if you are on a shared host)
• The want to do it all for you – they not only let you manage content, they also give you comments, discussion forums, surveys, social networking, and anything else under the sun. If you only need a small website with information about yourself, your company, or your software project, this can be a huge overkill.

I had been using Drupal for some time (found it to be one of the saner pieces of software written in PHP), but the time required to set up even a simple website in Drupal with custom design was frustratingly long. Gradually I started writing my own scripts in PHP, until I realized that I did not really need dynamic page generation for anything else besides the content management itself, and could just as well do that content management from a perl program that runs as a cgi-script.

Miril makes a hacker's life easy

Miril has one primary goal: get your site online and working as fast as possible.

• The whole of Miril currently installs from CPAN. You only need to create a standard CGI::Application script that runs it.
• Miril is configured entirely using plain-text files. This means that after you have created your first site, you can just copy and tweak you configuration files to get started with new sites – no need to go through on myriads of checkboxes and drop-down lists and submit buttons.
• Miril can also store its data in plain-text files (actually that is the only place where it can store data right now, database support will come soon). You can quickly set up your website without messing with databases, and since all generated content is static databases do not give you a performance boost anyway.
• Miril's templates (currently only HTML::Template syntax is supported) make it easy to apply your custom website design. The look and feel of Miril's user interface is completely independent from the look and feel of your website – unlike CMS's such as Drupal or Wordpress which mix the two and thus sentence website authors to long hours of painful and error-prone theme adjustments.
• Miril's user interface is used strictly for managing content, and is kept as simple as possible. In fact, Miril is probably the CMS with the simplest user interface on the market right now – so you can spend as little time as possible training your users once the website is ready.

How to get it

Miril is currently alfa-quality software and is under active development. The code is pretty messy and it spurts out the occasional warnings – glitches should be expected! Miril is completely usable though, and it runs the site you are currently reading. You can get it from CPAN, and take a look at the Manual to get started. The repo is at http://github.com/pshangov/miril.

Within the next week or so I am planning to announce the launch of an open-source perl project I have been working on recently and I want to create some publicity within the community. My blog currently appears only in the Planet Perl Iron Man feed, so I thought I should look into some other aggregators and get my blog included there too. There are two major problems I encountered that I want to share.

Statistics

Of the four major perl blog feeds I know of (use.perl.org, Iron Man, Perlsphere and Planet Perl), only Planet Perl provides statistics in the form a feedburner button displaying the number of readers. I am unable to find any similar information for any of the other feeds. There are a number of reasons why such information would be useful:

• blog authors will know which feeds are more popular and which ones they should seek to join
• blog authors will be able to tell what percentage of total subscribers tend to visit their blog and if necessary take measures to increase it
• this will be a good indication of how the community in general is expanding/shrinking

Joining

The other problem I encountered was joining. Perlshpere has an email address which one should write to to get their blog added, but I wrote to this address twice and did not get any response. Planet Perl gives no information on how to join at all, and the “Site Information and Contacts” link leads only to the main perl.org contacts page.

Any help/suggestions will be appreciated.

A friend of mine, a pretty good java and C# programmer, recently asked me this question while I was advocating the merits of perl and of dynamic languages in general. Why don't universities pay proper attention to dynamic languages? Why do software companies, which are run by smart people and employ smart people, use java and C# rather than dynamic languages for the enterprise systems they develop? Why are dynamic languages used as niche tools only (e.g. perl for system administration, or RoR for quick websites), and usually because an individual pushed for their use rather then because of company policy?

I promptly replied that platforms such as java and .NET are backed by billion-dollar companies that spend enormous amounts of money convincing people that their software is superior. But even as I said it, this explanation felt somewhat insufficient to me. The question has been haunting me ever since, and gradually a somewhat unexpected realization dawned on me.

The dynamic languages ecosystem makes it difficult for the participants to make money.

Language superiority discussions among tech people have traditionally revolved around arguments such as: “My language has cleaner syntax!” or “My language has better extensions!” or “My languages makes whatever task easier!” or “My language runs faster in such and such environments!”. Look carefully, however, and you'll see that on top of the tech arguments, the organizations behind java and C# have made sure that there is another, more subtle one that is clearly understood: “My language helps you make money!”.

Technologies such as java and .NET have large companies (the Big Guys) backing them. This is a factor that has been discussed so many times (“We cannot compete with the Sun marketing machine”) but it is still so easy to underestimate. The majority of the IT sector is occupied by ISV's that either develop applications for the businesses or the government, or (especially in Eastern Europe and Asia) do outsourcing for other companies. The Big Guys have developed complex partnership programs that provide these ISV with a formal attestation (in the form of certificates, references, logos for their websites, etc) of their ability to work with the respective technologies. Most ISV's work hard to attain such partnerships, as this in turn helps them compete more successfully for new customers and win government tenders. So it is in their best interest to promote the platforms developed by the Big Guys, and there is very little incentive to explore alternative technologies. In fact, several large government tenders (here in Bulgaria) that I have been involved with have all mandated the use of a specific technology – .NET and/or java, in the tender specifications. The reason? The actual tender documentation has been prepared by external consultants who are in turn certified Microsoft/Sun/IBM partners.

What the software giants are doing is, is they are saying: “The more effort you invest in using and specializing in our products, the greater formal acknowledgment in the form a of a certificate or partnership status will you receive by us, and the easier will it be for you to win tenders, win the trust of new customers and demand higher margins.”

A similar scheme exists for developers. Most of the Big Guys offer various certification courses for IT professionals whereby the certificate obtained acts as some sort of reference before your current or future potential employees. In most positions, if you hold better certificates, you have better chances to obtain a better paid job. So certificates are a great deal for everybody: the training and examination companies earn fees from those taking the certificates, the HR companies can employ less qualified and hence cheaper staff to evaluate candidates, the IT professionals can earn better salaries if they hold the necessary certificates, and the ISV's can invest less money and effort in finding recruits.

The Big Guys thus create an environment where it is not only them that make money, but they also help a lot of other people to make money – the ISV's, the IT professionals, the training, consulting and recruiting agencies, etc. The more and easier this money is, the greater the enthusiasm for their technologies will there be. They create large cliques where everybody has a vested interest in promoting their platform. Why would Apple's Objective C gain such popularity – because Apple has made efforts to ensure that the developers that use it can make (a lot of) money. I remember a time when many java programmers started to flock to C# and .NET. Why? Because .NET programmers get paid better. Why? Because ISV's generally charge more for projects written in .NET. Why? Because the expenses associated with .NET projects are higher (licenses to start with). Why would end customers choose to pay for projects written in .NET then? Because ISVs, consultants, training companies, IT professionals - everybody tells them that this is the best platform to use (except open-source geeks of course, but they are dodgy-looking individuals that cannot be trusted anyway).

This seems to be a win-win for everybody. And it is very hard to beat.

So I finally decided to give Git a go. I work on Windows XP. Git's homepage lists msysgit as the installer for non-Cygwin Win32 users, so I went on and grabbed it. The installation, however, proved far less straightforward than I expected.

First, msysgit presented me with the following screen:

I have three choices:

1. Use Git Bash only. I am a newbie Git user. I am just starting to use Git. I have read some basic tutorials that assume the user is running a unix machine, but do not really know yet what the preferred Git interface on Win32 is. I do not know what “Git Bash” is. Maybe it is a modified version of Bash that is designed to provide a better interface to Git? May be it is the nickname of an important Git tool that is known to everybody else but me? Do I want to use that? Will this Git Bash thing still be installed if I select any of the other options? I have no idea.

2. Run Git from the Windows Command Prompt. This “heading” sounds OK – from the tutorials I have read I assumed that I will be using Git from the command line, so that sounds as what I would need to use. But then the text says: “Use this option if you want to use Git from a Cygwin Prompt”. Well, I don't use Cygwin so is this still a good option for me? Is this a general purpose option or is it an option specifically targeted for Cygwin users? It initially looked to me that this is the most appropriate option for the average Joe user (not too conservative and not too dangerous), but it is not selected by default so maybe it is not? And should Cygwin be mentioned here at all when there was a separate download link for Cygwin on the Git home page.

3. Run Git and included Unix tools from the Windows Command Prompt. This option scares me right away. What are these “accompanying Unix tools”? Where can I get a list of them and why is this thing trying to install them when I only want to use Git?

So, faced with a choice between this conservative Git Bash option, the option for the Cygwin Prompt and the “accompanying Unix tools” option, I realise I have no absolutely no clue which one to choose. So I head to the msysgit website to find some info. Nothing on the start page. Nothing on the InstallMSysGit page. I check the list of wiki pages but no page description seems to point at the information I need.

So I look at the screen again, and finally decide that the second option probably means “Use from the Windows Command Prompt OR the Cygwin Prompt”, so I am going to take a chance and give it a try.

Then comes the second screen:

I have no idea what the difference is between ssh.exe and plink.exe and why I would choose one over the other. A brief search on the msysgit homepage fails to enlighten me either. I choose, for no particular reason whatsoever, to stick with the option that is selected by default (OpenSSH).

And just when I thought I was done, there came screen number three:

I work on Win32 and most of the files I create have Windows-style line endings. But I occasionally hack on some open source projects where line endings tend to be Unix-style. But why would Git care about that? SVN never asked me such as question! It seems the most reasonable option for me would be the third one (“Commit line endings as they are”) but why is this question asked at all? What is are the consequences of this choice? Does Git do something special with line endings that do not match my choice (e.g. if I choose Windows-style and then try to upload a file with Unix-style line endings, will Git attempt to convert the line-endings to Windows-style automatically?) Or maybe some git commands do not work properly unless they know the type of line endings in advance? Again, the msysgit website fails to give me any information.

Post-installation, I looked at what Git had installed, did some research and found the following:

Screen #1: msysgit is apparently based on the “MSYS” tools provided by the MinGW project, so it ships these tools with its installation file. It is hard to figure what these tools are before install, since they seem not to be listed even on the MYSYS website itself. Msysgit creates a directory (called “bin”), where it places these tools (i.e. the .dll and .exe files), along with the actual git commands. It also creates a second directory(called “cmd”), where only links to the git tools (“git” and “gitk”) are created. Armed with this knowledge, we can figure out what the individual choices from the first screen entail:

1. Use Git Bash only. The MSYS tools contain a port of Bash. If you select this option, msysgit will add to your “Start” menu a link to the Bash executable. It will launch a command prompt window with Bash, and since it will open in the directory where all the other the MSYS tools are located (“bin”), you will be able to invoke the git commands from there. Neither the “bin” nor the “cmd” directories will be added to your PATH, so you will not be able to use the “git” command from an ordinary command prompt window.

2. Run Git from the Windows Command Prompt. This is probably the preferred option for most users. The link to Bash will be added as above, but in addition the “cmd” folder will be added to your PATH environment variable, so that you can use the “git” command from anywhere – the standard Windows Command Prompt, a Cygwin prompt, or any other shell that you may be using.

3. Run Git and included Unix tools from the Windows Command Prompt. The “bin” directory will be added to your PATH, so in addition to “git”, the other MSYS commands will also be made available anywhere in your system. This may not be the best idea – some of the MSYS tools may conflict with the built-in Windows tools, and in particular MSYS ships its own “perl.exe” which may mess up with your default perl installation.

Screen #2: While browsing the support forum on Github, I read about a number of issues resulting from the use of Git with plink.exe, so you are probably better off sticking with OpenSSH here.

Screen #3: This option apparently modifies a setting in Git (“core.autocrlf”) that controls whether Git would automatically convert line endings to a single format when pulling and committing code. This can be helpful if you want to make sure that all files in a repository use the same line-ending style, but may be a problem if you are working with multiple repositories and in heterogeneous environments (I have yet to find how to set this option on a per-repository basis).

Conclusion

Despite this rant, I have to express my gratitude to the msysgit people for porting git to Win32 in the first place. I am now a (mostly) happy git user, and there are already some things about git that I seem to like very much (I will probably write an article about that soon). I hope that this explanation will help some people who, like me, were used to the ease of use of Subversion and TortoiseSVN on Win32, and felt a little intimidated while installing Git. Or maybe it was just me ...

Vim being one of the most commonly used programming editors by the nerds that perl programmers are, it has quite a few scripts allowing you to read module documentation straight from within Vim itself. All of them, however, just grab the output of the 'perldoc' command and place it in a plain text buffer. PERLDOC2 does a similar job, but with a twist – it adds syntax coloring to make reading documentation easier and more convenient. Check out these screenshots:

Currently supported is highlighting of headers, lists and verbatim text. Inline formatting is not implemented yet.

To install, you need to get the Pod::Simple::Vim module from CPAN first, and then install PERLDOC2 as you would any other vim script. In your vimrc file, you will need to setup the “g:Perldoc_path” variable, pointing to a directory where the generated documentation files will be stored , trailing slash included (keeping a cache allows you to easily navigate back and forth between the doc files you have recently viewed). Then just type “:Perldoc Module::Name” in vim’s command prompt.

How it works

Pod::Simple::Vim is a Pod::Simple-based parser that outputs the requested documentation in plain text but with some special formatting codes. These formatting codes are in fact quite similar to the ones used to display vim’s own help format. PERLDOC2 provides a syntax file, perldoc.vim, which interprets those formatting codes. Vim talks to Pod::Simple::Vim via the pod2vim script installed by Pod::Simple::Vim.

And last but not least, I have just set up my first repository on github, and this is my first upload there – contributions are welcome!

I have been thinking recently that it would be so cool if there were a Mastering CPAN book, both for CPAN users and for CPAN authors. The best way to get the job done with CPAN is sometimes just so non-obvious. Such a book would be useful both for newcomers who still feel intimidated by CPAN as well as for more experienced users looking to learn some neat advanced techniques. A sample Table of Contents may look like this:

Part I: Using CPAN

• Basics - what is CPAN, who hosts it, who contributes to it, etc.
• Finding stuff on CPAN
• Installing stuff from CPAN, CPAN.pm and CPANPLUS.pm, other shells, manual installation, PPM packages and repositories, .deb and .rpm packages, ActiveState Perl vs Strawberry Perl, compiling modules on Win32 with AS Perl and Visual Studio Express, understanding the overwhelming output of the cpan shell and figuring out which messages are important, failed tests and forced installs
• Structure of a CPAN distribution, info you can find in META.yml, finding usage examples in the tests directory
• Reporting bugs and finding support for a module
• Creating your local minicpan, running a webserver for pod documentation
• Advanced commands in the cpan shell, creating bundles for all of your installed modules, other local maintenance tasks
• Other useful tools and websites: cpan testers, cpan dependencies, annocpan, cpanhq, diff and grep on search.cpan.org

Part II: Authoring CPAN Modules

• The stuff from “Writing Perl Modules for CPAN” that is still relevant
• EE::MM, Module::Build and Module::Install, including advanced options
• Basic info on writing tests, testing modules on Win32 via the Microsoft Open Source Network CPAN Author Lab, cpantesters
• Distribution management and upload tools
• Basic techniques to write code that works with older versions of perl

Perl is notorious for its punctuation-ridden syntax, and if there is one place where this is manifested most obviously, it is when working with data structures. While I myself can see the beauty behind the line noise and have nothing against the syntax per se, it sometimes feels there are just too many characters to type. In particular, I have recently had to do a lot of work with XML data represented by perl hashes, via XML::TreePP and XML::Compile. Working with the data structures generated by these modules can quickly become pretty painful.

Enter Data::AsObject. It allows you to work with hash and array references as if they were objects. For example, I often have to process XLIFF files, which are used in the translation industry. Using XML::Compile, I can get my XLIFF files serialized into a hash and use it as follows (you don't need to know the details of the XLIFF format to see the point of the example):

# $xliff holds the serialized xml
# get the source language of the first file
my $source_lang = $xliff->{'seq_any'}->[0]->{'file'}->{'source-language'};

# get all the translation units in the first file
my @trans_units = @{ $xliff->{'seq_any'}->[0]->{'file'}->{'body'}->{'cho_group'}->[0]->{'trans-unit'} };

# for each translation unit, add an alternative translation with a source and a target
foreach my $tu (@trans_units) { 
    my @matches = get_matches($source->textContent);

    my $id = 0;
    foreach my $match (@matches) {
        $tu->{'cho_context-group'}->[$id]->{'alt-trans'}->{'source'}->{'_'} = $match->source;
        $tu->{'cho_context-group'}->[$id]->{'alt-trans'}->{'target'}->{'_'} = $match->target;
        $id++;
    }
}

The same example with Data::AsObject (for this to work, hooks need to be added to XML::Compile to automatically convert “source-language”, “trans-unit” and other elements with dashes to “source_language”, “trans_unit” etc.):

# Data::AsObject::dao converts a hashref or an arrayref to a 
# Data::AsObject::Hash or a Data::AsObject::Array object
dao $xliff;

my $source_lang = $xliff->seq_any(0)->file->source_language;
my @trans_units = $xliff->seq_any(0)->file->body->cho_group(0)->trans_unit;

foreach my $tu (@trans_units) { 
    my @matches = get_matches($source->textContent);

    my $id = 0;     
    foreach my $match (@matches) {
        $tu->cho_context_group($id)->alt_trans->source->{'_'} = $match->source;
        $tu->cho_context_group($id)->alt_trans->target->{'_'} = $match->target;
        $id++;
    }
}

This an almost real life example and you can easily see what benefits in terms of readability Data::AsObject provides. Of course there are many caveats, the primary one being that you need to be able to control your input and guarantee that hash keys will only contain alphanumeric characters and underscores. Go check out the docs for more usage details.

This is the obligatory general-purpose evangelism piece that every perl hacker ends up writing sooner or later in his or her journalling career. Mine comes as only the second article in this blog, and is dedicated to what has recently become an increasingly controversial aspect of the perl culture – the dreaded There Is More Than One Way To Do It design philosophy. This article suffers from an abundance of generalizations, but too many details would have made it unbearably long to read. A more useful discussion may ensue in the comments.

Many argue that TIMTOWTDI is the curse of perl. It confuses beginners, increases the learning curve, makes it difficult for companies to enforce programming standards, makes it difficult to establish criteria for evaluating job candidates, etc. These arguments are by all means true. But for me, having programmed in a number of languages, TIMTOWTDI has emerged as probably the number one reason why I persist in preferring perl to anything else on the market.

A great example of TIMTOWTDI in action is Catalyst. I recently spent several months learning it and developing a relatively complex application. It was indeed very frustrating at the beginning. Catalyst supports a bazillion configuration formats and different parts of the documentation provide examples with different formats, and it is not always straightforward to translate from one format to the other. I had a tough time figuring out which form generation and validation library to start learning, since I had never used one before (Which one has the functions I need? Which one is best integrated with Catalyst? Which one has the best documentation?). Trying to understand the multiple ways in which access control can be implemented made my had spin. And so on, you get the idea.

But at the end of my learning experience I was happy. Having grasped the fundamentals of Catalyst I knew I could use any templating system I needed, plug in any storage model I needed, and generally deal with any circumstances whether planned by the Catalyst authors or not. I felt exhilarated and brimming with power. I felt like Popeye the sailor after eating his spinach. I felt I could rule the world.

I have done serious web programming in two other languages besides perl – C# and PHP. Late last year I joined a team working on a large web portal written in C# and .NET, and I had the chance to learn learn the .NET web programming patterns. In .NET there is generally one way and one way only to do things – which is sometimes good, and sometimes it sucks big time. I won't go into detail, but you don't feel powerful doing web applications in C#. You feel trapped.

With PHP, on the other hand, you have a proliferation of frameworks and tools, but the overwhelming majority of them have their own view of the universe and usually come with their own stack of tools developed by the framework creators and designed to be used with this particular framework exclusively. Diversity seems to come at the price of constant reinvention of the wheel. You end up feeling you could rule the world, but you'll have to use a different type of army for each individual country, and some countries will probably not surrender at all, and also things tend to get pretty messy with the larger countries, and in the end it is just too much work to bother so why don't you just give up your global domination plans altogether.

The bottom line is, perl powerful because it tends to provide a level of abstraction that you just do not get in other languages. Perl itself, as well as perl's frameworks and tools, have been designed from the very start to accommodate diversity and deal with the unexpected. The perl module author is trained to make very few assumptions about how you are going to use her code and leaves a lot of room for choices. And the knowledge that I can make choices gives me a warm fuzzy feeling and lets me sleep well at night. Choice creates competition and competition creates evolution. I may be a strange bird, but I love the fact that I can choose what object-oriented programming framework to use. I find it comforting to know that I can choose what regular expression engine I want to use – even though I would probably never do that. I am grateful to be able to work in an environment that inherently acknowledges that each solution is imperfect and the least imperfect solution tends to be different for each individual problem.

This is the first post in yet another new blog to join the perl blogosphere. My name is Peter, I am from Bulgaria, and my technological inclinations seem to have been determined by a memorable childhood camel-riding experience (my family was relatively poor and precious stones are not something I am used to; also, I never really managed to get comfortable with snakes). Although I first started programming in perl nearly 10 years ago, it was only in the past year that I evolved from an anonymous and passive consumer of perl code and culture to a point where I released my first cpan modules, started sending bug reports and patches for other people's modules, and joined an exciting community project. Now the hacker in me is feeling a new urge – to speak and be heard!

While readers of this blog will be entertained with musings on tech stuff of any nature, the predominant theme is going to be Perl. Some of the topics that I want to talk about are perl documentation and where it can be improved, my favourite but under-appreciated cpan modules, my personal perl projects (stay tuned for some some cool stuff!), and, of course, my own takes on perl evangelism. I will be joining The Iron Man Challenge, and the first five items on this blog will also be cross-posted on use.perl.org.

The name of this blog reflects my passionate belief that technology empowers the individual to influence the world and change it for the better. I think this is true more then ever at this specific point in time when technology has become so accessible and powerful that it has made it possible, like never before in history, for individuals and small groups to spread their ideas and influence to thousands and even millions of people, all over the world.

Enjoy!

Credits:

This blog is hosted on my brand new Hostgator account (I will post a review of Hostgator as a perl hosting solution once I've had some experience with it). The theme – Byty the Free Child (which I fell in love with after seeing it on David Golden's blog), was designed by Cristian Antohe, initially for Wordpress. The content management system powering the blog is something I have been working on for a while and will soon be released to the public. The comment system is managed by Disqus.