25 Years of Perl

A few days ago, I mentioned that I’m giving a talk at the London Perl Workshop called Twenty Five Years of Perl in Twenty Five (ish) Minutes.

I already have a good idea of how the talk will go. I’ve got a good structure to hang everything off. But I’m still working on the detail. I know I’m very old, but I haven’t been involved with Perl for the whole of its history. And even during the sixteen or do years I’ve been using Perl I’ve almost certainly missed some interesting things.

So I thought I’d crowd-source the talk a bit. What would you include in a history of Perl? What events do you think are important enough to be listed in a twenty minute talk?

Please leave your suggestions in a comment.

London Perl Workshop

Today, the initial list of talks for this year’s London Perl Workshop was announced. Looks like I’ll be giving three talks of various lengths. And of various levels of seriousness.

The rest of the announced talks sounds far more useful. Looks like the workshop will be as good as it always is. If you want to come along (and I highly recommend it), you can register on the web site.

 

DBIC vs DBI

Three times in the last few months I’ve had the “DBIC or raw DBI” discussion. People have told me that they don’t use DBIC because raw DBI is better. And each time, the person promoting DBI in the discussion has used an argument that boils down to “DBIC is probably useful for people who don’t know SQL very well”.

I find that argument really puzzling. Not least because I like to think that I know more than a little about SQL. SQL is a skill that that has run through my career for longer than Perl. I’ve been using SQL since I left college in 1988. I only started using Perl in about 1996. And yet, although I still consider myself a bit of an expert in SQL, I use DBIC for pretty much all of the database work I do these days – and have done for about five years.

I use DBIC not because I don’t understand SQL. I use it because it makes my life easier. I use it because it frees up some of the time I used to spend dealing with the minutia of database communication so that I can spend it working on other, more interesting, parts of my project.

When I’m running training courses that introduce DBIC I have slide that is entitled “SQL is Boring”. It’s a joke of course but, like all the best jokes, it gets a laugh because there’s more than a little truth in it. There are, of course, many interesting SQL problems. I’ve spent many an enjoyable (if slightly frustrating at the time) hour trying to coax the right data out of complex query with correlated subqueries, outer joins and aggregated functions. But that’s the exception rather than the rule.

The vast majority of the SQL I write for the applications I work on is incredibly boring. It’s  boring because it’s all so similar. You get the data to present a list of objects to the user. The user selects the object they’re interested in, so you select all the data about that object. You might select some data about related objects. The user changes some of that data, so you update that row in the database. On a good day, you might delete an object from the database. Or insert a new one. Most of the SQL you need is like that. It’s boring.

We have computers to do the boring work for us. So let the computer generate all that boring SQL. Free up your time to work on the gnarly and interesting problems.

But that’s not the only advantage of using DBIC (or some other ORM). Think about the data that you get back from the database. The data you get back from a DBI call is an array. Or perhaps a hash. Or maybe a multi-dimension data structure if you’re using one of DBI’x more complex fetch() methods. But it’s still a dumb variable. From DBIC, I get an object. An intelligent variable. A variable that knows how to react to various messages. A variable that will save any changes back to the database automatically without me having to worry about where it came from and making sure that I’m writing it back to the right place.

I’m not saying for a second that there’s no place for DBI any more. For a start, DBI underlies DBIC so it’s still a vital part of our toolkit. And of course I still use it for quick one-off scripts. But when those scripts are still hanging round being used and maintained three months later (as they always are) I’ll rewrite them to use DBIC.

If you want to write large applications that are going to be easy to maintain and extend, then you should really be using DBIC (or something similar). I don’t care how well you know SQL. DBIC will make your life easier.

I’ve just mentioned a couple of reasons why I think that DBIC makes my life easier. I’m sure I’ve missed important stuff. What do you think? Why do you use DBIC instead of DBI?

Perl School 2

Yesterday was the second Perl School course. Once again it was at Google Campus and once again it was on Modern Perl for Non-Perl Programmers. The big difference this time though was that people were paying £30 a time to attend.

And that did make a difference. While the previous (free) version sold out in less than a day, there were still tickets on sales for this one right up to the time it started. But I actually ended up teaching more people as far fewer people didn’t turn up (there were still four people who didn’t turn up though – guess some people don’t care about wasting £30).

I thought the course went well – but I’ll wait until the feedback forms come back before taking that for granted. It felt smoother than the first run and we finished on time.

One of the best things about these courses is the way that they draw in people who don’t usually get involved in  the Perl community. Of the twenty-five or so people in the room, I think there were three or four who I had met at Perl Mongers events or YAPCs in the past. As I finish with a section on where to go for more information and as that section includes a big plug for London.pm and the London Perl Workshop, hopefully we’ll see a few more people being drawn into the community.

So now it’s time to start looking ahead. The next Perl School is already planned. It will be on 8th December and will be about Moose. Running once every two months seems to be a pretty good rhythm, so I’m also starting to think about running one at the start of February. That will probably be about DBIx::Class.

As always, I’ll post something here when I have more details. But you can also watch the upcoming events page on the Perl School web site.

And if you have any ideas of other courses that I should be running as part of this series, then please let me know.

Learning from Bad Code

I’ve written before about Linux Format’s habit of sharing badly written Perl code. I thought things were improving, but in the new edition (November 2012, issue 163) they’re back to their old tricks.

This time it’s a tutorial called “Starfield: Learn new languages”. In this tutorial Mike Saunders writes similar starfield simulation code in C, Python and Perl. Mike’s loyalties are made perfectly clear when these three sections are entitled “Low Level”, “High Level” and “Unusual Level” respectively, so I wasn’t expecting much. But here’s what I got.

Let’s be clear here. This code works exactly as Mike intended it to. But if you’re writing sample code for other people to learn from, I think you should be setting the bar a little higher than “works for me”. I think you should should be aiming to show people good quality code that can be easily mainitained. And this code falls well short of that aim.

Let’s look at some of the problems in more detail:

  • No use strict or use warnings. Let’s be generous and assume the editor removed them to save space.
  • Undeclared variables. Of course. if the code contained use strict then the variables would all have had to be declared. Not declaring them means that we’re using package variables rather than lexical variables. In code this simple it doesn’t make a difference. But it’s a bad habit to get into.
  • Indirect object notation. When creating the Curses object the tutorial uses the syntax $screen = new Curses. Again, not a problem in this program, but a really bad habit to be encouraging. In the article’s defence, the documentation for the Curses module only includes this flawed syntax.
  • Split data structures. The author of the article says “instead of having an array of stars containing coordinates and speeds for each one (i.e. an array of arrays), to make things simpler we’ve just set up three arrays.” I read this to mean “I’ve never been able to work out how to make arrays of arrays work in Perl so I’ve taken the easy way out.” This is, of course, a terrible idea. Linked data items should be stored in the same data structure.
  • C-style for loops. The mark of a C programmer who never really got to grips with Perl. The C-style for loop is rarely used in Perl code. The foreach loop almost always leads to more readable code.
  • Magic numbers. The size of the screen and the maximum speed of the stars appear as numbers in the code. Even if you’re not a Perl programmer, surely you would know that it’s good practice to move those into variables or constants.

With all that in mind, here’s my version of the program.

What do you think? Is it more readable? Easier to maintain? Are there any problems or improvements that I’ve missed?

Perl School 3

The second Perl School course is just under four weeks away (and there are still tickets available) but it’s time to start looking ahead.

The third Perl School is going to be on 8th December. Like the others, it will be at Google Campus.  But this time the subject will be slightly different. The first two have been aimed at people who don’t know much Perl, but this one will be the first in a series for Perl programmers who might just not be completely up to date with the latest tools. This one is called “Object Oriented Programming with Perl and Moose”. Tickets are £30 and are available online. More details of the course are on the Perl School web site.

The more observant amongst you will have noticed that I’m giving a two-hour tutorial on Moose at the London Perl Workshop two weeks before this course. That tutorial will cover something like a quarter of the material in the full-day version.

 

A Cautionary Tale

I can never remember exactly how Time::Piece works. But that’s ok because I have documentation.

$ perldoc Time::Piece
No documentation found for "Time::Piece".

Huh?

$perl -v
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi
...

$ corelist Time::Piece
Time::Piece was first released with perl v5.9.5

$ perl -MTime::Piece -E'say $Time::Piece::VERSION'
Can't locate Time/Piece.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .).
BEGIN failed--compilation aborted.

So Time::Piece has been in the Perl core since 5.9.5. I’m running Perl 5.14.2 but I don’t have Time::Piece installed.

After ten minutes or so of head-scratching it came to me.

$ sudo yum install perl-core
Loaded plugins: langpacks, local, presto, refresh-packagekit
[ stuff snipped ]
---> Package perl-Time-Piece.x86_64 0:1.20.1-212.fc17 will be installed
[ more stuff snipped]

I’m running Fedora. The Fedora packagers have decided that they don’t need to install the whole standard Perl distribution as part of their standard installation. I don’t have a problem with that. I do have a problem with their naming conventions.

The minimal Perl installation that they include by default is in an RPM called “perl”. The full RPM that includes everything that a Perl developer would expect to see is called “perl-core”. Surely it’s obvious that those names are the wrong way round?

Isn’t there some way that the Perl 5 Porters can object to  this renaming of Perl?

I know I should be installing my own Perl with perlbrew. But I generally find that the system Perl works for everything that I need. There’s just this one thing that is guaranteed to trip me up every time I work on a new Fedora installation.

This is a public service blog post. Perhaps someone will come across it and be saved a couple of hours of confusion.

CGI.pm vs Templates

I’ve just been involved in a discussion on LinkedIn that I thought deserved a wider audience (I have no idea how well that link works if you’re not a member or or logged in to LinkedIn).

A couple of days ago, someone asked for advice on the best way to include HTML in a Perl program. They got a lot of good advice (basically – don’t do that, use a templating system instead). And then this morning, someone came in and said:

use CGI module, u don’t need to write a single HTML tag..just use CGI Methods…

I did a bit of a double take at that point. I thought we’d all stopped using CGI.pm’s HTML generation methods back in the last millennium. I replied saying that, but this chap was adamant that CGI.pm worked for him. He asked me to explain why I was so against his approach.

This was my reply:

I never said that it didn’t work. I just think that it’s a really limited way to build things and you’d be better off taking a more flexible approach right from the start.

My main objection is the separation of concerns. The logic of your application is separate to the display layer. It’s quite possible that the display of the application will need to change in the future. And that all becomes easier if the HTML is stored separately from code.

This leads to other problems too:

As I hinted at above, CGI.pm only has pretty basic support for HTML. It’s really hard to create a great-looking web application using CGI.pm. In fact, I wouldn’t be surprised if CGI.pm was largely responsible for the terrible web sites that the Perl community has been building for itself for most of the last twenty years.

Your project might well have HTML experts who know how to create good looking web pages. Expecting them to do it by editing Perl code is a bad idea. Front end developers need to know HTML, CSS and Javascript. Why force them to understand Perl as well?

Even if you’re the only developer on a project (as I often am for my personal projects) there are advantages to separating your work into “front-end task” and “back-end tasks”. I find it really helps me switch my mindset to the appropriate skills if I switch from editing a Perl source file to editing an HTML template.

It makes your Perl code more complicated than it needs to be. Seriously, try moving the HTML out of the code and into a template. See how much simpler your code becomes.

It’s unlikely that your CGI-generated pages will make up all of the web site. There will almost certainly be static pages too. If you use a tool like the Template Toolkit then you can generate static pages from the same set of templates that your CGI programs use. That way it’s easier to maintain a consistent look and feel across all of the pages on the site.

I’m not saying “don’t use CGI.pm” (well, I am a bit – but that’s a different story). The CGI bits of CGI.pm (for example the bits that give you access to the incoming parameters or let you set the outgoing headers) are great. It’s just the HTML generation stuff that I strongly recommend that you don’t use.

I’ve just remembered an article that I wrote in 2001 that might also help. The first half is about cookies, but the second half demonstrates using Templates instead of the HTML generation methods. I hope it shows how much simpler it makes things

See http://mag-sol.com/articles/cgi3.html

Does that help at all?

I think that pretty much sums up my objections. Did I miss anything obvious? Or am I completely wrong and many of you are still using the HTML generation methods in CGI.pm to do this?

The Perl community on LinkedIn is a fascinating place. I should really write a blog post about it.

Perl School

On Saturday, I ran the first Perl School session. Twenty-five programmers with little or no previous experience of Perl came along to Google Campus in London and listened to me talking about Perl.

Over six hours I tried to give a good introduction to Modern Perl. In the morning I talked about the core Perl language and explained some of the concepts (for example, context) where Perl differs from most other programming languages. In the afternoon I talked about some of the important big CPAN projects that are defining Modern Perl – things like Moose and PSGI.

The course was free as it was all a bit experimental. I was trying to work out how much material I could get through in a day and what topics would be most useful for the attendees. Many lessons were learned.

  1. There was slightly too much in the course. Things got a little rushed towards the end. I might need to cut a bit of material before running it again. Or perhaps I just need to waffle on a bit less.
  2. When you book a room you should ask how the seating will be configured. I turned up at about 9:15, expecting I’d just need to get to grips with the projector system. I found the room set up with chairs around a central table. It was a bit of a rush to turn that into a lecture theatre before the students arrived.
  3. Some people don’t value free training. There were fifty places available on the course. They were all booked within 24 hours of the date being announced. Over the intervening couple of months, a few people dropped out and were replaced by people from  the waiting list. That’s not a problem. In the 24 hours before the course I received five emails from people saying that they couldn’t come for various reasons. That’s not a problem either. What’s a problem is the twenty or so people who just didn’t bother to turn up and didn’t think it worthwhile to let me know.

I’m doing it all over again in October. Same course (slightly improved, I hope) art the same venue. This time it won’t be free – but I’m hoping that a fee of £30 will be cheap enough that people will still sign up.

And I’m planning more courses for the future. Initially, I plan to run something every couple of months. I’m thinking about one-day courses in Database Programming, Object Oriented Programming and Web Programming. Hopefully some of my readers will be interested to come along to some of that.

I hope to announce the subject and date of another course within a couple of weeks. It’ll probably be in early December. Watch the web site or the mailing list for details as soon as I have them.

Google Currents

Google Currents is an application for viewing content on Android and iOS devices. It reformats content (based on web feeds) to look like a magazine. It looks great on my HTC One X and I’m expecting it to look even better on my Nexus 7 when it arrives.

It’s possible to subscribe to web feeds using it, but for some reason content looks better if the web site owner goes through a simple process to publish the content. This is literally a three minute job which you do from the Google Currents Producer web page. I’ve done that for both this site and the Perl News web site. I can’t seem to find any way to share the address of this content, but if you open the Currents app on your tablet or phone and search for “Perl Hacks” and “Perl News” you should be able to find them.

Currently I’m using all the default formatting options, but I suspect I’ll be drawn into tweaking things soon.

If you published Perl-related content on the web (or, indeed, any other kind of content) then it might well be worth your while taking the three minutes it takes to publish your content for Google Current.