The tech blog of Peter Shangov

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

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.

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.

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

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.

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.

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.

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!