The Russian Perl journal Pragmatic Perl published an interview with me in its October 2013 issue. The questions were exceptional. Because you probably read Russian about as well as I do, here's the English text I provided.
How and when did you learn to program?
Which time?
Like many of my peers in the US (middle class white kids who grew up in the suburbs), the first time I saw a computer in person was elementary school. I was 5 or 6 years old. It was a Commodore 64. In those days, computers came with manuals and BASIC, and the manual showed you how to write simple BASIC programs on almost the first page. (Page 32—I just checked. The first several pages tell you how to hook it up to a TV or monitor and how the keyboard works.)
I eventually talked my parents into buying a computer for the family.
When I was in high school, my interests changed and I spent more time playing music than programming, but in college I tried to pick up C++ (it didn't take) and Java (it took a little) and in my first real job in a career, I wrote a few programs for the printer group at HP and found that a lot more entertaining than anything else I was doing.
What editor do you use?
Vim.
When and how were you introduced to Perl?
Java was new and interesting when I started at HP, but I was doing what work I could on HP-UX and Linux (Red Hat 4 or 5, I think). Java was way behind on Linux in those days, but at least it had basic Swing support.
The second serious programming project I worked on had to send email to a list of customers about updates to the printer networking support service. I wrote a proof of concept in whichever variant of the Bourne shell HP-UX 9 supported. It was about ten lines of code. Then I had to port it to Java because the group who wanted the code needed it to run on Windows NT. Back in those days, Java was immature. It didn't have many libraries. To send email, you had to write a lot of code to connect to an SMTP server and send the correct headers and everything. It took more code to set up the Java libraries than it did to do the whole task in shell.
I started looking around for other languages. My brother was studying and working in telecommunications at his university at the time, and he'd been automating a lot of things in Perl. I bought the second edition of the Camel book, read it cover to cover, and that was it.
What are other programming languages you enjoy working with?
Haskell, for the way it makes a good type system usable (and encourages you to write small pieces of code that join together sensibly).
Scheme, for the way it lets you build up a good system from a small set of usable pieces.
I keep wanting to like Go, but it's never quite been useful enough for me yet. (I expect it to be better at Unicode than it is.)
I keep thinking there's a good language in C++ struggling to get out, but then I feel like I'm not smart enough to find it out.
What do you think is the strongest Perl advantage?
The lack of ceremony. You can give Perl to someone who has little experience programming and he or she can get something done more quickly than you would expect. He or she might make a mess—the discipline to program well takes time and experience to develop—but the pragmatism of Perl is a huge advantage.
What do you think is the most important feature of a language of the future?
That depends on the language. Most people think speed of execution is the most important thing. In a few contexts it is. If you want to get a lot of users, though, you have to let them do something that they want to do without frustrating them so much that they'll leave for something else. Again, pragmatism is a benefit here.
PHP didn't get a lot of users because it's a good language. PHP has a lot of users because it's just about the easiest way to make a dynamic web page.
You've invested a lot in Perl ecosystem and infrastructure. What is the reason behind that?
I want to make my life easier. Having good tests for CPAN modules means that I can trust CPAN modules more than I could before. Having simpler and better abstractions for things like email or OO development means that I can get my work done more correctly and with less effort than previously.
Having a good introduction (like I hope the Modern Perl book is) available freely means that more people can start writing better Perl than they would if they followed the awful, outdated tutorials that were already online.
During your work on Perl 6, you worked on roles. Do you think they are essential for modern OOP? Are they a silver bullet or another "shoot yourself in the foot" pattern in a real large and complex project?
If you read modern OOP tutorials, the bad ones will try to tell you that inheritance is essential to OOP. That's silly. Polymorphism is essential to OOP.
(Polymorphism is essential to programming. If you can't learn to
treat things that are different in small details but similar in other details
in the same way, you'll go crazy. People often struggle learning arrays because
they want to name variables $recipe1, $recipe2, and
$recipe3. Only when they realize that they can treat them all as
elements of @recipes do they start to understand the power of
programming.)
In the development of roles, I kept arguing that we needed to solve two things:
- how to identify behaviors and state that were conceptually similar enough that they could be polymorphic
- how to share code without enforcing a code sharing mechanism (delegation, inheritance, composition, cut and paste, role application)
The researchers behind the original Smalltalk Traits paper were trying to solve similar problems at the same time, so I think we were all on the right track.
Can roles be misused? Yes. Can you shoot yourself in the foot? Sure. Are they essential to a good OOP project? That depends on the project.
In my experience, using roles and parametric roles effectively has improved the design of several projects. It takes time and experience to understand their effective use, but if you're a disciplined programmer who is willing to revise the design of your system as you discover what it needs to do, roles are another tool in OO design and analysis that you should consider.
Why do you think testing is important?
I want to improve my confidence that the code I'm using and deploying works. Testing by hand doesn't give me confidence. I'm okay if I don't have 100% confidence, but if I can look at the tests and they make sense, I have fewer worries about the code.
I don't care much about the distinction between unit tests, integration tests, behavior tests, spec tests and the like. I try to stay pragmatic. I want to know if the essential behavior I want to rely on actually works. I want to know that you've thought about edge cases. I want to know that if I make a change and break something, running the tests will catch that.
It's about quality and confidence and reliability. It's also a marker of discipline and quality of the programmer. You don't have to have automated tests to write great software, but if you're not writing automated tests, I want to know why I should trust the software you write.
After more than a decade is Test::Builder keeping up with the modern testing practices?
What it does, yes. What it looks like inside? No. Hopefully
Test::Builder 1.5 or 2.0 will make it out and clean things up.
What inspired you to write the Modern Perl book?
Perl needed a short introduction that didn't pretend to cover the entire language. I thought that explaining the philosophy of the language, how to use perldoc, the necessity of the CPAN, and what to use and not to use would be useful.
Why did you decide to make it freely available?
Three reasons. First, people are going to get it for free through various copyright infringing means if they really want it. That's not worth my time fighting. Second, I hoped it would spread further (and promote the printed and paid electronic editions) if it were freely available. Third, I know there are people in countries in places like Eastern Europe and Southeast Asia and Africa and other regions who will never be able to buy a printed copy because it's too expensive to ship (or just too expensive). I can't write in all of their native languages, but I can give them a free edition in English that someone can localize.
Are you planning on updating it as Perl hopefully evolves?
I'd like to get a new edition out before the end of the year.
It seems that you're involved in several businesses. What is your primary occupation right now?
Right now I'm consulting for a startup in the medical industry.
How do you see the future of Perl?
I'm hopeful for projects like Stevan Little's new MOP and Peter Martini's subroutine signatures in the core.
I'm doubtful about projects putting Perl on a new backend, at least without someone fixing the XS problem (that is, XS exists, is pretty much just the guts of Perl 5 exposed, and has rarely had a formal API that the core can support without tying the hands of the core hackers).
CPAN continues to grow.
I don't know what will happen with the Perl outreach problem. (Some people call this "marketing".)
Perl will continue helping my clients and projects get the right answers.
Should we encourage young people to learn Perl right now?
That depends what they want to build. I talked to a high school student yesterday who wants to study computer science and has experience with HTML and wants to learn JavaScript. Does Perl make sense for her? (Is there a simple Windows distribution that uses some Plack magic to make deploying Perl programs as easy as PHP programs, but doesn't require her to use CGI.pm? Perhaps.)
What do you think about situation around smart match?
Perl 5 has long had the design idea that variables should be polymorphic
while operators should be monomorphic. In other words, you can see $a +
$b and know that's it's addition (no matter what $a and
$b contain) and you can see $a . $b and know that
it's concatenation (no matter what $a and $b
contain).
Smart match was different. Any time you deviate from a core design principle of a language, you have to consider the pros and cons carefully. Smart match looks like a tool intended to solve several different problems all at the same time. In the absence of a strict set of monomorphic variable types, you can't look at the code and immediately understand what's going to happen.
It's similar to the problem of each() on references; you can't
tell if each $foo is going to give you the keys and values of a
hash or the indexes and values of an array.
Where do you get the energy to write your programming related blog posts regularly?
I've always been a writer, and like any habit you develop over time, you build up muscles (literal and figurative). By now it's a habit.
With that said, my day job and personal life are busy enough that my frequency of posting has dropped from several times a week to weekly. It would be nice to get a little more free time.
Was it hard to quit after several years working on Perl 6 and related stuff?
Yes and no.
It hadn't been enjoyable for a long time, for a variety of reasons. I'd put in 9 years of work doing un-fun things like fixing segfaults and finding optimizations. Finally I couldn't justify working on it in my business hours, because I had enough paying work where it wouldn't have helped, and I had enough other potential things to do in my spare time that I actually enjoyed.
On the other hand, if you work on something for 9 years you'll probably feel some sense of attachment to it. I'm proud of some of the work we did and I learned a lot, but if you told me in 2001 or 2002 what would have happened by 2013, I'd have spent my efforts elsewhere.
That lesson took me a lot of time and trouble to learn. I felt guilty for a while, thinking that Parrot would suffer if I weren't there fixing bugs and writing code. But then I realized that if Parrot weren't useful or usable for anyone else, maybe me not working on it was a good thing. If a project can't survive when it loses developers—if it's not being used for anything productive or if no one cares enough—then maybe the resources being used on it would be used better elsewhere. Certainly that was the case for me personally.
I spent almost a decade working on all of those projects, so I feel like I did what I could to make them succeed. If someone else wants to pick up the work I did and do something else with it, the code's out there. But none of those projects are worth my time or energy anymore, and I'm comfortable saying that. If you find yourself in a similar situation, anyone who tries to make you feel guilty for thinking there are more important things than working on software you're not getting any benefit from is being unfair. (Even if it's you trying to tell yourself that.) Donating your free time and talent to create and maintain free software is a gift, and it's a gift you have the right to rescind.
Are you enjoying Perl conferences?
I took the year off from conferences for non-technology reasons and have enjoyed not travelling. With that said, it's always a pleasure to spend time around great people in the Perl community, so I've missed that this year.
