My recent procurement of new employment has thrown me back into the hellish world of perl. For those unaware, perl is the dyslexic ginger stepchild of 2400 bps modem line noise, albeit executable and fast. Now don’t get me wrong, I’ve been coding professionally in perl since 1995, and have produced several large enterprise applications that are still in use to this very day.
Perl is a very capable language without a doubt however having used the language for so many years both professionally and for hobby I have become well aware of its faults and shortcomings. This article isn’t specifically about pointing out the many issues perl has, some of which will be addressed in Perl 6 (when it eventually gets released in 2027). Today I am only going to speak of one specific issue which is actually quasi addressed in a set of modules, all relating to the Template Toolkit.
When coding in perl, even adhering to best practices such as those outlined in the excellent book by the one and only Damien Conway, author of the more notable “Object Oriented Perl”, one still finds perl problematic due to too much adherence to the ‘there’s more than one way to do it’ mantra. The constructs are very low-level language based, which makes sense given perl’s humble beginnings but ugly none the less. Some languages which have come into existence after perl have corrected this shortcoming and as previously stated, perl is moving towards correcting some of its ugliness, though a bit late.
The current leading language which not only matches perl’s power in many areas, while exceeding perl’s abilities in others is Python. Its focus on clean form through visually enforced coding constructs along with a more natural syntax which closely follows not only spoken speech but though processes is a testament to language advancements. Which brings us to my main focus of this article, clean syntax in the style of Python, within a perl application.
The perl Template Toolkit by Andy Wardley is the definitive all around powerhouse of template creation systems available within perl. There are many others available but they all pale in comparison especially when you take into consideration the multitude of uses, formats and arenas in which Template Toolkit is competent. This is no mere mail merge replacement library, even though it will do just that exceedingly well. The toolkit is much more than that, mainly due to its wonderful flexibility in its meta language utilised for in-template logic.
This language within a language is also where I happen to draw its direct link to Python whether intentional or not. Good design shines through and it just happens that the aforementioned comparison is dead on. Let us begin with a sample of what I’m talking about but reviewing a simple .tt template from the Template Toolkit website.
[% FOREACH team = teams -%]
[% team.name %] [% team.played -%]
[% team.won %] [% team.drawn %] [% team.lost %]
[% END %]
All of the above would be located in a .tt template file. A dictionary (a.k.a. associative array/hash) is passed called “teams”, containing the named elements of name, played, won, drawn and lost respectively with their associated values. Unlike perl’s “c” style referencing methodologies which is fine and dandy for shell scripting or c programming it is by no means as clean as the more appropriate referencing styles utilised by most modern languages, specifically object oriented languages using the dot format. As a side note, perl’s object system was ripped almost verbatim from Python, though poorly implemented (e.g. implemented with perl’s tmtowtdi mind-set as opposed to a proper object focus with structure and stringency.)
The above code is clean and simple, much like Python. The only exception is the punctuation, which is only necessary as delimiters for the meta language. Thanks to this cleaner approach taken by the Template Toolkit system, we can allow the logic to be cleaner by limiting the perl to only the minimal amounts thus ending up with cleaner overall code, especially handy in the world of cgi and/or form processing.
Let us face facts, of the following, how would you range readability from easiest to hardest.
Python:
for team in teams:
print team.name, team.played + ‘-’
print team.won, team.drawn, team.lost
Template Toolkit:
[% FOREACH team = teams - %]
[% team.name %] [% team.played -%]
[% team.won % ] [% team.drawn %] [% team.lost %]
[% END %]
Perl:
foreach my $team (@teams)
{
print “$team{‘name’} $team{‘played’} -\n”;
print “$team{‘won’} $team{‘drawn’} $team{‘lost’}\n”;
}
The above Python code is simple to understand, even by non-programmers. The Template Toolkit version while a little messier due to the punctuation is still rather clear cut and simple to read, while the perl version adds a significant amount of unnecessary punctuation. What this all comes down to is that if you have to code in a perl environment, there is now a way in which you can produce a cleaner codebase, mainly by keeping the data display layout and logic within .tt template files.
So I commend Andy Wardley and all of those who assisted with this wonderful module (and its associated add-ons) in doing what Larry Wall and crew have been unwilling to do thus far within perl. Dictate flexible standards which avoid the ugliness which has now grown synonymous with perl. If you find yourself stuck in a perl environment, you now have some solace in a place to take refuge courtesy of the Template Toolkit.
Oh, and for those of you who have moved on to one of the the languages of choice at google, Python, there is the ever flexible Cheetah template framework.
No comments:
Post a Comment