Perl School 3

Yesterday was the third Perl School. Twenty-one students converged on Google Campus in London and spend a day learning about Moose.

The day seemed to go well. People asked intelligent questions and seemed to understand what I was telling them. Hopefully the feedback forms will tell a similar story.

No more training now for a couple of months. But once Christmas is over, I’ll need to start thinking about Perl School 4 – which will be about DBIx::Class. Hope to see some of you there.

Why Corporates Hate Perl

This is a reprint of an old blog post.

A few years ago I was writing blog posts (semi-)regularly for O’Reilly. This is the one that probably got the most feedback. I’m reprinting it now because a) it’s pretty hard to find on the O’Reilly site and b) it’s relevant to a couple of conversations that I’ve had over the last few days.

Last week I was in Copenhagen for YAPC::Europe. One of the announcements at the conference was the location of next year’s conference which will be in Lisbon. The theme of next year’s conference will be “Corporate Perl”. And that (along with a couple of conversations last night) got me thinking about a talk that I’ll submit to next year’s conference which might well be entitled “Why Corporates Hate Perl”.

It’s not true, of course. There are a still large number of large companies who love Perl. I could probably work through to my retirement enhancing and extending systems that are written in Perl at many of the big banks in the City of London. There are, however, also many companies who are moving away from Perl for a number of reasons. Here’s one of the reasons that will be included in my talk.

I was talking to people from one such company last night. The Powers That Be at this company have announced that Perl is no longer their language of choice for web systems and that over time (probably a lot of time) systems will be rewritten in a combination of Java and PHP. Management have started to refer to Perl-based systems as “legacy” and to generally disparage it. This attitude has seeped through to non-technical business users who have started to worry if developers mention a system that is written in Perl. Business users, of course, don’t want nasty old, broken Perl code. They want the shiny new technologies.

And so, in a matter of months, the technical managers at this company have created a business environment where Perl is seen as the cause of most of the problems with the current systems. It’s an impressive piece of social engineering.

It’s also, of course, completely unfair. I don’t deny at all that this company (like many others) has a large amount of badly written and hard to maintain Perl code. But I maintain that this isn’t directly due to the code being written in Perl. It’s because the Perl code has developed piecemeal over the last ten or so years in an environment where there was no design authority which encouraged developers to think beyond getting their immediate task done. Many of these systems date back to this company’s first steps onto the internet and were made by separate departments who had no interaction with each other. It’s not really a surprise that the systems don’t interact well and a lot of the code is hard to maintain.

There are, on the other hand, a number of newer systems which are also written in Perl which follow current best practices in Perl development and are far easier to to maintain and enhance – as easy, I would contend, as anything written in the new approved languages.

It’s certainly true that this company has a large number of systems that need to be rewritten over the next few years. But throwing away all of the company’s accumulated Perl expertise and moving to new languages seems to be a step too far. Management are blaming Perl for the problems when really they should be blaming the management and design procedures that were in place (or, more likely, weren’t in place) when the code was originally written.

Many organisations are in the same situation, with large amounts of unwieldy Perl code. Ten or twelve years ago everyone was writing web systems in Perl and we were all making mistakes. We all have to deal with those mistakes but we’ve  hopefully, learned from them and can rewrite our systems to take account of everything that we’ve learned in the last ten years.

It’s too late for the company I’ve been talking about in this article. The anti-Perl social engineering has probably insinuated itself too deeply into the culture. It’s unlikely that Perl’s reputation can be rescued.

But if you have similar problems in your own company, then please try to ensure that blame is apportioned correctly and that you don’t use Perl as a scapegoat.

A couple of updates to the post. I did propose the talk to the next YAPC, but the proposal wasn’t accepted. And the company I talk about in the article is still employing a lot of Perl programmers – four years after this post was written.

 

Speaking at the LPW

I gave three talks at the London Perl Workshop yesterday[1]. That wasn’t the original plan, but I kept coming up with talks that seemed to be good ideas.

The last one was on 25 Years of Perl was a bit of a failure as I broke the second rule of presenting (always plug in your laptop) and the battery died just as I got to 2012. Which meant that no-one saw my big finish where I pulled out to give an overview of all 25 years and thanked everyone who had ever been involved with Perl.

I’ve put the slides to all three talks on my (new, very much “work in progress”) talks page. It includes a link to all of the 25 years talk.

Thanks (as ever) to all of the organisers, volunteers and speakers at the LPW. The workshop just gets better and better each year.

See you in 2013 – which will be the 10th LPW!

[1] And also spoke on a panel about the state of the jobs market.

LPW Schedule

(You wait weeks for a blog post and then two come along practically together. But this is just another short one.)

It’s the London Perl Workshop on Saturday. The schedule for the day was published some time ago and it’s as diverse and interesting as it always is.

If you look closely at the schedule, each talk has a mysterious-looking number at the end of its description. That’s the number of people who have said they are interested in seeing that talk.

Currently, the highest number I can see on the schedule is 26. There are just under 300 people registered for the workshop. That means that a lot of people haven’t marked the talks that they are interested in.

Marking the talks that you’re interested is useful for a few reasons. Firstly, there’s a page on the site which will show you your personalised schedule which just includes the talks you’ve said you want to see. You could print it out and bring it with you on Saturday (or have that page open on your tablet).

Secondly, it’s useful for the organisers. They have a rough idea of which talks are going to be well-attended, but they can occasionally misjudge it. If they find out that 150 people want to see a talk that they have put in a tiny classroom then they can take appropriate measures (like moving the talk).

And finally, it’s useful for the speakers to have an idea of how many people are interested in their talk.

It’s not hard to register your interest in a talk. Just log in to the workshop web site and go to the schedule page. Every talk will have a star in the top left corner. Clicking that star will register your interest. You’re not actually registering for the talk. No-one is going to do anything if you change your mind on the day and go to a different talk on that day. It’s just so we can all get an idea of the approximate levels of interest in the various talks.

Why not pop over to the schedule page and mark some talks now?

See you on Saturday.

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?