Programming and Perl

1) Intro slide

2) Hi, welcome to this talk about programming and the Perl language.

   My name is Bron Gondwana.  I'm a from Australia (g'day mate) and I
   work for Opera Software on our FastMail hosted email platform.

   I gave a talk here last year about robust infrastructure.  I showed
   how we provide a reliable email service using redundancy and fault
   tolerance.

   Today, I'm talking about one of the most useful tools in our toolkit.
   Almost all the parts of our system we have made for ourselves are
   written in perl.

   I have been in this role through 4 different company names since 2004.
   My previous job was data management for a clinical trial company, and
   I have also used perl as a consultant working on things as varied as
   e-commerce, online gambling and even a porn site.

3) So - programming.

   Most of you are IT students.  So if I asked you when should you write
   a program, what would you say?

4) ...

   Obviously, I don't really mean that.

5) Don't unless you have to.

   Programming isn't the purpose.  It's a tool.

   It's a way to achieve your real goals.

   If you can get to what you need by using existing tools, or gluing them
   together.  Yay.  We programmers often make fun of people using Excel
   (for example) rather than "real programming".  If it gets the job done,
   more power to it.  I'll re-visit Excel later in this talk.

   You goal may be analysing data.  Predicting something.  Selling widgets.
   Maybe even helping people store and access their email reliably...

6) So - why perl?

   For me - the magic moment came while I was still at Uni.  I had some
   data to process and I was trying this language which I had been told
   was awesome for data processing.

   I had learned enough regex to parse out the numbers I needed, and now
   I just had to add them together.  I read the documentation trying to
   find out how to convert from text to number type so I could add the
   numbers - and there wasn't anything.  In desparation, I just tried
   putting a plus there.

   IT WORKED!

   I was hooked.  Instead of getting in my way, the language was helping me.

   A good way to assess a language is to ask its users what they hate about
   it.  Which bits "suck".  Some languages, many of their users will get all
   defensive about their baby.  Not perl.  The average perl programmer will
   say "yeah, it kinda does, doesn't it" and then get back to work solving
   problems.

   By the way, you'll notice I've set you up with a perfect question to ask
   at the end.  Perl programmers are thoughtful like that.

   I should note here that this talk is about the current "Perl 5" language,
   not the future "Perl 6" - which is due by Christmas.  Nobody's quite sure
   which year.  Last estimate I heard was 2001.

7) Yes, Perl syntax does look odd at first.

   It's also famous for clever one-liners and obfuscated code.

8) It doesn't have to be like that.  As they say "you can write COBOL in
   any language".

   Brian Kernighan said it best - it's twice as hard to debug as to write code
   in the first place.  If you're as clever as you can be when you write it,
   by definition you're not smart enough to debug it.

   Don't be clever.

9) Perl really isn't a "sexy" language.  But it is rock solid.

   There are two things you can talk about for stability, and Perl has both
   of them.

   The first is stability of the language itself and language features.  We
   have 15 year old code in FastMail which still works fine.  It may not use
   the most modern idioms, but it runs.

   As I said before, the goal of programming is to solve problems.  If the
   problem hasn't changed, and the code still solves it, then having to
   "fix" that code for new versions of the language is just makework.  Who
   has time for that?

   All our homegrown, long running tasks are written in Perl.  They can
   easily be running for hundreds of days.  They don't crash.  They don't
   leak memory.

   They could run faster if written in another language, but we don't
   necessarily need fast.  We need reliable and predictable.  Perl
   performance is consistent.

10) CPAN is the "Comprehensive Perl Archive Network".  The largest
   repository of freely available library code in the world.

   Like an "App Store", there's heaps of crap in there.

   But there's a surprisingly large quantity of high quality, well
   engineered modules.  And most of them come with tests.

   Best of all, there's a network of automated test runners which
   test new uploads against a variety of platforms and versions of
   Perl, so you can trust that they will work on your system.

   When you install perl, it runs a whole stack of tests to make sure
   it is working correctly on your system, in your environment.  And
   when you install a module from CPAN (which is usually a matter of
   typing a single command - it will resolve dependencies for you
   automatically and install those too) it will test that the module
   runs correctly on your system as well.

   Testing has been part of the perl culture since before it was cool.

   The end result for you, the user, is that you're working with a
   mature environment.  You don't have to do it all yourself.  This is
   a good thing - outside Uni, reinventing wheels is a waste of time.
   You can concentrate on solving the part of your problem which is
   unique.

11) Perl runs on just about everything, and it talks to just about everything.

   I said I would get back to Excel.  At my previous job, we had a complex
   and very powerful XML schema format to describe the data we were capturing
   for clinical trials.

   It was hard to read, even for those of us who knew it - and a pain to edit.

   Project managers didn't have a hope of understanding it.  They would email
   us Excel files describing what they wanted, and we would spend days
   painfully converting them into the XML format.  Then they would have
   changes, or we would make a mistake... it was a mess.

   In the end, I wrote a tool using Perl's Excel read-write modules - yes,
   they exist - to convert from the spreadsheet to XML.  Most importantly,
   I also had a tool to convert the other way - to build a spreadsheet in
   the style the project managers were using but with annotations in colours
   or stylings of text - even just which cells had content - which mapped to
   the features of our schema.

   I could then just email the spreadsheet to the project managers.  They
   could make changes, and I could convert back instantly.  Instead of days
   it took seconds.  Even if they messed up the formatting past what the tool
   could handle, I could fix that by hand quite quickly.

   In the end, I used the spreadsheet format even for my own changes.

   This is where programming shines.  Solving real problems.  This is why
   it's so awesome that you are programmers.  Don't forget to have other
   skills too - domain knowledge was what helped me understand how to
   apply the programming skill to help everyone.

   Wow - this slide is busy!  Perl can be used for event-based programming
   (just like node.js but with fewer buzzwords).  You can write object
   oriented code, either by convention or with the new Object Model which
   has been added to the code by a hackathon right here in Norway organised
   by our local users' group this year!  It doesn't add new features, but
   improves performance for the already existing modules (on CPAN!).

   And finally, there's plenty of things you may recognise from Functional
   Programming.  Closures.  Map and Grep.

12) Perl was famous in the past for poor quality CGIs

   Most perl users who aren't shameless attention hogs like me are just
   quietly solving problems.  Gluing together other systems and getting
   the job done.

   It's not a good choice if you'd rather be talking about how awesome
   your programming language is than actually programming.

   Just because it's stable, doesn't mean the language is stagnating or
   standing still.  Over the past three years, three major new versions
   of Perl have been introduced - and the existance of CPAN is even more
   important than just having unit tests.  There's piles of code of all
   sorts of quality in there - and core perl changes get tested against
   all of it!  This is good for quality.

13) Finally - when you do need help, there's a great community around Perl.

   Here in Oslo there's a users' group which meets monthly.  Being Norway,
   they mostly drink and share war stories.

   There's also a yearly European conference.  I've been lucky to go to the
   past two years in Riga and Frankfurt.  Next year is in the Ukraine.

   I think the quote that best sums up Perl actually comes from the last YAPC
   conference's final keynote.  Different languages optimise for different
   things.  Perl optimises for useful.

   Perl is useful for me.  I like that it's stable.  I like that it
   performs consistently.  Most of all I like that I can trust it.  I
   sleep easy at night knowing that our robust infrastruture is running
   on Perl.

   I hope you will come to like and trust Perl as well.

14) Questions?