October 2013 Archives

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.

I haven't written this entry yet. To be notified when I do, write your own entry somewhere, drop me a note, and I'll add my reasoning as a comment to your post. (I promise.)

Warning: rant ahead which extrapolates from a single documented data point.

From The Once and Future Rubinius:

The simplest statement about the status of Rubinius is that there are now zero people paid to work on the project.

Many community-developed projects have corporate sponsorship. A lot of projects have companies which support the software. Others have foundations to handle donation. Still others have a loose alliance of consultants whose contracts allow them to release some, most, or all of the code under free software licenses.

If you follow the Hacker News Daily Gosizdàt dispatches from VC-istan, you'll soon learn that free and open source software is how two teenagers can drop out of college and found the next multi-billion social network for dogs to share pictures of recipes.

Sometimes one of those actual successes will release software to the world as a whole (WebKit, LLVM, Go, HipHop (and, yes, that list is full of irony; consider the Google black hole of talent into which promising free software developers disappear and useful software fails to escape)). Usually the startup will implode into a neutron star full of self-satisfaction, taking with it tens of thousands of lines of unmaintainable code no one wants anyway. (Although the world really could use one more WordPress plugin for caching static requests and one more web request routing plugin for Node.js, but only if the latter manually parses HTTP headers.)

Even when a company succeeds at prying cash from the tech-necrotic hands of a venture capitalist (usually involves sacrificing your soul, or at least controlling equity), that sudden influx of resources usually doesn't make it to the underlying technology that helped that company build something to separate VCs from money.

(You'd think the class of person which helps itself to shiny new Macbooks and iGadgets every year because they "deserve high quality engineering in [their] tools" would throw a bone to the software they use as alternatives to stacks from Microsoft and Oracle, but I've only known one startup which went so far Apple as to deploy to Mac mini servers.)

Maybe that's okay, but maybe funded startups are vampire squids which take advantage of free and open source software without doing much to ensure that it survives longer than their doomed startups.

Startup culture has never been efficient; the business model works if there's one huge hit and a couple of moderate successes for every couple of hundred failures. Free software is different. The business model works as long as there's someone willing and able to release new versions of the code (even if that new version is merely a packaging improvement or a one-line bugfix or a correction to a typo in the documentation).

Unlike a startup, community-developed software is not necessarily beholden to customers or even users. It is beholden to the interests and abilities of its developers. If that interest or ability wanes, the software may not survive. (The code will still exist, but will it persist for long in a usable form? Who knows.)

It's well and good that startups can build themselves ever more cheaply and well with software released under free and open licenses, but if they're not contributing back to that software somehow after they've built successful businesses, they're cheating themselves (and the next generation of businesses).

After all, a business which has the revenue to support a dedicated sales force is probably foolish to use word of mouth as its sole advertising and sales strategy. Why should we consider it any less foolish to use the time and interest of unpaid volunteers as its technology infrastructure strategy?

Laziness is a virtue in programmers, but like any virtue, it's easy to take it too far (or not far enough), in which it becomes a vice.

When my career in technology started, I was a system administrator. If you think programmers are lazy, you don't know many really good system administrators. My rule was "If I'm bored four days out of five, I've done my job well." A bad system administrator will ignore problems. A good system administrator will prevent problems, often through a combination of automation and monitoring.

That discipline is good for programmers, too. (Programmers need a healthy sense of paranoia about all of the things that could go wrong, from anything like hardware failures to interaction with real users who never, ever, ever read instructions.)

That laziness is bad for programmers, too.

When I first released Modern Perl: the book, I didn't render an HTML version because I was falsely lazy. I didn't want to do the work of turning the plain XHTML templates into something attractive and usable.

Eventually (second edition), I did add the book's text in entirety to this web site. It took a couple of days of spare time to fit everything together in a way that made me happy enough, or at least didn't make me too unhappy.

For at least most of 2013, I've meant to go back and add simple SEO optimizations to the chapters, for things like meta descriptions and better titles. Doing it the quick and easy way will take me an hour.

The problem is, I want to do it right. I know I'll have a new edition of the book ready to go in the next couple of months, and then I'll have to spend another hour or two getting the on-page SEO elements back in place. I don't want to do that manual work twice. Instead, I'd rather automate the entire process so that I can type one command and render the book in multiple formats all ready for the printer, for electronic delivery, and for plain static HTML hosted on this site.

In other words, I've put off doing something simple which will help people find what they're looking for because it'll take at most an hour of manual work in favor of not spending several hours automating that process.

That is false laziness, and it affects far more that my hobby projects. I have to fight it on almost everything I do. (When I was a child, I spent an afternoon attempting to invent a machine which would make my bed for me, because that was more interesting than spending 90 seconds to make my bed.)

What's the solution? I'm not sure. In my professional work, the relentless push to deliver good data to clients and to satisfy the business requirements of a growing business helps me remember that my goal as a programmer is to produce value. Undelivered value isn't value at all. That's no excuse to do a sloppy job or release code I'm not proud of, but it's a constant reminder that my work isn't some theoretical exercise of perfection. It has to exist and it has to work.

The reticence to do something because I think there might be an abstraction or automation or simplicity that I'll eventually get to? That's dangerous, if it keeps me from doing useful and necessary things.