The tech blog of Peter Shangov

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:

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:

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:

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.

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.

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!