Paul Johnson <paul@pjcj.net>, Wesley Johnson <wes@wes-johnson.com>
I have been using Perl for longer than I care to remember and I'm currently working on a grant to improve Devel::Cover, the Perl code coverage module.
I am half way through my 'A' level studies, which include a Computing course.
Perl is now almost 25 years old. Some of us have been using Perl for almost all that time. Many of us have been using Perl for a sizeable fraction of that time. And the reason we have been doing so is because we believe that in those cases it is the best tool for the job, however we define 'best'.
In order for Perl to remain viable it requires a critical mass of users, and that requires involving people who are younger than the language itself.
One way that we have tried to do that is by taking part in the Google Code-In for the last few years. This is a programme aimed at introducing students between the ages of 13 and 17 to open source software.
Learning a programming language well enough to be proficient in using it is a commitment. It requires time and effort. Sometimes it is useful to learn a programming language because it will introduce us to new ideas and ways of programming. Every programmer should know at least one language from each of the major paradigms: imperative, object oriented, functional and logical. Each one will allow you to look at problems in a different manner and when you know them all you can choose the appropriate way to solve the problem at hand.
A programmer who hasn't been exposed to all four of the imperative,
functional, objective, and logical programming styles has one or more
conceptual blindspots. It's like knowing how to boil but not fry.
Tom ChristiansenIt's hard to know lots of languages well, and generally we are more productive in the languages we know best and enjoy the most. For many of us, Perl is one of our favourite languages, but in order for Perl to be a viable choice for a project there are certain requirements.
The language itself needs to be robust. It should have features that help the programmer and it should not be buggy. In addition, the language should have sufficient libraries available for the tasks at hand. And there should be a community around the language to provide the resources and support necessary to learn and use the language, and to ensure that the language and libraries remain in good condition.
Although many people like to argue otherwise, Perl meets all these requirements. The core is solid. It is well maintained and has relatively few serious bugs. The volunteer and grant recipients who maintain it do amazing work.
CPAN is widely touted and Perl's crowning jewel. The quality may be variable, but you are almost guaranteed to find a high quality module to assist you in your project.
And the community around Perl is second to none. Naturally, it is not perfect, but it is vibrant, and full of knowledgeable volunteers.
But Perl doesn't have quite the aura that some other comparable languages might have amongst some people. I don't want to investigate here why that might be, but it is clear that unless Perl remains viable as a language, many of us will need to start considering whether we would be better off choosing another language for our projects. And companies will stop using Perl for development which will mean fewer and less interesting Perl jobs.
Additionally, it is generally advantageous to have a number of languages competing in an area. It encourages innovation and copying which benefits all the languages and their users.
In order to keep Perl viable it requires new people to start using and eventually contributing to it. Some of the people at Google have had similar thoughts about programming and Open Source Software in general, and for many years they have been running the Google Summer of Code programme.
This is a programme for university students in which they can work over the summer in the northern hemisphere on a specific Open Source project and be paid for that effort by Google. The Perl Foundation has taken part in this programme almost every year.
A few years ago Google started the Google Code-In programme (GCI). This is a similar programme to GSoC, but it is aimed at pre-university students between the ages of 13 and 17. It is held over the northern hemisphere winter and allows the students to complete a number shorter tasks of various difficulties for which they receive points. The students also receive payments for the tasks they complete, and those who receive the most points and invited to visit the Google HQ in Mountain View. The Perl Foundation has taken part in GCI each year the programme has been held.
Each organisation taking part in GCI provides a number of tasks in different areas, and categorises the tasks as easy, medium or hard. Tasks should take from a few hours to a few days to complete and students may complete as many as they would like.
Students claim a task and then get a certain amount of time to work on it. Within that time they need to complete and deliver the results of the task. Each task has one or more mentors who will determine whether the student has completed the task and will either confirm that it has been completed or provide assistance if the student needs it. The mentor can also extend the time available if they feel the student is making progress but requires more time. If the student cannot complete the task it is returned to the pool of open tasks and may be claimed by another student.
In October 2011 my son, Wesley, tweeted "Can't wait much longer for #gci2011". Mark Keating picked up on that and replied to him, to Florian Ragwitz and to me that we should probably get ourselves organised. So we duly decided on a course of action, put up a wiki to collect suggestions for tasks and publicised it as much as we could on mailing lists, blogs, IRC and twitter.
Our schedule was quite tight. We needed to provide a credible plan to Google to gain admittance into the programme, and that involved including a certain number of tasks in each category. The categories were Code, Quality Assurance, Research, Training, Translation, Documentation and Research.
We received a wonderful response from the community - the first of many - and put together a proposal which was good enough to persuade Google to accept us into the programme. Not only did we receive numerous task suggestions, but almost all of those who made suggestions also volunteered to act as mentors for those tasks. Many were also willing to volunteer to mentor other tasks.
On 21st November 2011, at 08:00 UTC, the contest started. Students were able to see the tasks and start claiming them. We set up an IRC channel for mentors and students with the idea that there would always be someone around to help a student who needed a little advice.
With students aged between 13 and 17 it was clear that many aspects of software development would be new to them and it soon became apparent that many would need assistance in working with git and github, or in understanding that they needed to edit a template rather than the resulting HTML. Fortunately, we were blessed with many patient mentors who were willing to spend their time assisting the students.
One of the GCI rules was that students could not work on more than on task at a time. That meant that as soon as a student submitted a task they were keen to get it accepted or to find out what was wrong so that they could either fix it or move on to their next task. Our mentors were, of course, all volunteers, with jobs that took priority, who might be in different time zones to the student and, perhaps, in a few cases, might even have a life.
We had a group of 50 mentors who went beyond the call of duty in trying to aid all the students in a timely fashion, but there were still occasional instances in which students had to wait a bit longer than they would have liked to get feedback.
We noticed a trend quite early on that the translation tasks were very popular. It's understandable why that is. If you are fluent in two languages the translations can be relatively easy tasks. Wesley is bilingual and was also drawn to those tasks. This caused difficulties in some organisations where students sometimes provided translations that weren't particularly good, but the organisation didn't have mentors fluent in those languages to be able to notice that. We ensured that we always had mentors fluent in the languages for which we had translation tasks, and if we couldn't provide such mentors we didn't offer those tasks.
One of the more difficult aspects of the translation tasks was that whereas we had a pool of 50 mentors, the majority of whom were qualified to mentor on the majority of the tasks, only those fluent in both English and the language of the translation were qualified to mentor the translation tasks. In general we had two or three mentors per language, and it turned out that in many cases the translation tasks required much more mentor input than we had expected.
In total we had 89 students complete at least one task. 162 tasks were completed in total out of 392 which were available.
With a large interest in programming amongst young people, learning how to teach them about Perl and the community around it is essential to help to pass on Perl to the next generation.
We are already trying to do this by participating in projects such as GCI and GSoC, but what else can we do to try and encourage more people to participate in Open Source projects in general and Perl in particular?
GCI and GSoC do a very good job at encouraging students to get involved in the open source community. Using IRC is one of the greatest helps in my experience, because not only are the project mentors often online, but so are other members of the community who are frequently willing and able to help.
One of the things that helped me getting started with Perl was watching Gabor Szabo's videos on YouTube. They are explained very well and provide good information for people who are new to Perl.
For many young people an easy introduction is very important. When things start becoming more complex and harder to follow many lose interest and decide to do something else. It is important to make sure that any introduction is easy to follow.
Many people also learn to program in languages such as VB. That is the language that is taught at my college and despite my dislike for it and programming in Access, there's nothing I can do about it. A great way to make Perl more relevant for younger people is to provide 'stepping stones' from more common languages such as VB.
The reason many people use Perl is because they think it is best suited for the work they want to do. If we know these reasons and are able to share them, we should do so. Teaching younger people about the advantages of Perl could encourage them to use Perl sometime in the future if not straight away.
In order to pass on our knowledge of Perl to the 'next generation', we need to teach them what makes Perl the most suitable language for our work and how to start using it. Once these things are done it should be very easy to help and encourage more people to use Perl.
In order for Perl to remain a viable language for new development it requires a critical mass of users. Encouraging young people to consider Perl and providing ways to allow them to do that is essential to ensure the ongoing success of the language.
GCI wasn't perfect. The programme is still young and it's evolving and improving. It required a great deal of work on our part, but I think that overall our participation in GCI this year can be counted a success. We may not have completed as many of the technical tasks as we would have liked to, but every task exposed a student to some aspect of Perl. Even the translation tasks required students to understand the subject matter and become familiar with version control at a minimum.
Our 50 mentors deserve the utmost praise for their selflessness, willingness, skill, patience and tact. These qualities in such abundance amongst so many makes it a joy and privilege to count myself a member of the Perl community. Without their efforts we would never have been able to enter the programme, let alone complete it. It's hard to over-emphasise the commitment and effort put in by so many of the mentors.
I trust that our students found the programme beneficial; many of them said as much. We may find some of them contributing to Perl directly in the future. Most will likely contribute more indirectly by sharing a positive experience with Perl, by learning how be a part of a successful project or by generally enhancing the Open Source world in general. In short, and without wishing to appear melodramatic, I believe that such an investment in the future is in some small way helping to make the world a better place.