At YAPC::NA 2006, The Perl Foundation President Bill Odom gave a short keynote about the state of The Perl Foundation and his plans to encourage the continued success and growth of the Perl language and community. I took some concise notes, and hope to do Bill’s speech and views justice by expanding on them.

A rising tide lifts all boats.

Dynamic languages are getting popular in part because of the lessons we taught people.

One of the valuable results of Java, at least if you use other languages, is that it brought more mainstream acceptance of forty-year-old techniques, such as built-in garbage collection and a (reasonably) portable virtual machine. In a similar way, the practical utility of earlier versions of Perl and Tcl and some of the earlier dynamic languages helped make the current generation of dynamic languages more acceptable.

We do have a perception problem. More often than that, it’s an ignorance problem.

There are lots of architecture discussions where they don’t even consider Perl. “Isn’t Perl dead? Isn’t that the language we used to use for web programming before PHP?”

My boss has never heard “dependency injection” and “singleton” and “design patterns” come from a Perl programmer. He’s heard them from Java programmers. It surprised him — and it surprised me.

Of course, if you evangelize your language as being good for quick and dirty, don’t have to know much about programming tasks, is it clear and obvious that your language and platform can scale well to serious code that you need to rely on?

It’s interesting to consider why so much popular programming language research (and I use that phrase to distinguish academic programming language research, which seems, at least to me, to focus on newer functional languages) takes place with Java. Is it the language’s popularity? Is it its ubiquity? Is it that there’s actually a market for tools and vendors? Or is it that it’s just enough better than C++ as far as learnability and safety that it makes a decent teaching language?

I don’t know.

(Mark-Jason Dominus has an excellent lightning talk called Design Patterns Aren’t, where he explains a view common among users of powerful languages: design patterns are places where your language is not powerful enough to create usable abstractions.)

I leave Perl Best Practices on my desk when certain people come visit.

Here is one problem; Perl still has the perception of unmaintainable, throwaway code in some places. It suffers from being older than PHP, older than Python, and older than Ruby. (It does amuse me that Ruby is an “immature language” about the same age as Java.)

Does the existence of a Damian Conway or a Peter Scott (>Perl Medic) book start to challenge the perception that Perl is not a serious language or that Perl programmers cannot be serious and disciplined? Maybe.

Those good things are not enough.

The other 99% — the Perl programming world that isn’t here, isn’t on Perl Monks, maybe has heard of CPAN.

It’s great that you don’t need a membership card. You can join or not join as you want.

It’s also an untapped opportunity. We haven’t reached out to all of those people yet. There’s more to it than just this thing you downloaded.

Unfortunately, talking to several thousand Perl.com and ONLamp.com and O’Reilly Network readers doesn’t do much directly to help the million or so Perl dabblers and dilettantes in the world, or their co-workers and managers and customers.

How do you find someone who had to choose between Perl and PHP and chose PHP because “Perl is slow and dead and unmaintained” and now has to maintain a mess of PHP 3 or PHP 4 code and is ready to give up on programming altogether? (If you have a good answer for this, I think the PHP folks would like to hear it too.)

I’ve been talking to college students. I want to hear their perspectives. I’m also talking to coops. They can see both the academic and corporate sides. I want their perceptions of the tools, the community, and where we fall short.

They have a lot of sizzle. We have a lot of steak. Look at this huge installed base and the CPAN and the community.

There are places where TPF can have influence and begin addressing these programs. I want to address academic and education areas. We can turn those people into the open source and the Perl developers of the future. We should.

Here’s Bill’s promise and his goal. He wants to start conversations. He wants to hear what other people think and listen to what they have to say. These are young programmers, starting their careers. They have limitless energy and boundless potential. What languages and platforms are they choosing? Why? What makes one more appealing over another?

What changes can we make to Perl to highlight its strengths and address its weaknesses so that it can become a tool of choice again?

(I must point out here that I’m an unrepentant polyglot. I’ve programmed in multiple languages this week on production projects.)

I’m also talking to CxOs. They make big technology decisions. I want to know why. Why do they spend millions of dollars and why are they angry about what they bought?

Wouldn’t it be better to go through that pain without spending that much money? What if you didn’t even go through the pain?

It’s not enough to address existing developers and potential developers. I remember one project where we evaluated our options and decided that Python was the right language for a client project. Unfortunately, management believed the only way we could get the capital to begin was to use a language that the stakeholder had read about in a magazine. I’ll give you four letters and the name of an island to guess what that was.

Plenty of decision makers who set policy trends based on their own perceptions. They have legitimate concerns over risk and support and the available workforce. What can TPF learn from them?

How can we make money, save money, and minimize risk? That’s what CxOs want to know.

Fortunately, a lot of these people have just paid lots of money to 1-800-BIG-COMPANY and they didn’t get the support they want.

Then again, writing big checks doesn’t mean you’ll get the support and the indemnification you want, either. Perhaps paying a smaller check to a dedicated developer just down the hall to liase with the community might have a much better return on investment.

We want to promote some things we’ve forgotten about? The CPAN! The rest of the world wants something like it. It’s where the most interesting stuff is happening in Perl 5.

Why is Perl 5 still important? That huge, ten-year project with 10,000 distributions freely available and freely installable to solve most problems you’re likely to encounter has a lot to do with it.

Don’t mistake that for only a repository of code, either. There’s something special about a language and, more importantly, a community that has produced such a thing.

We need to remind people that Perl 5 is not going away. As much as I’d like to clone Allison and Audrey, we can’t. I can just help TPF stay out of their way.

(Allison is Allison Randal, president emeritus of The Perl Foundation and lead designer of the recently-revitalized Parrot project. Audrey Tang is the founder of the Pugs project, an umbrella for experimental Perl 6 implementations.)

It’s important to note that TPF does little development, preferring to encourage community building and non-development activities.

What can you do? Bill and TPF are looking for contacts at companies and schools great and small to talk about their perceptions and goals and, perhaps, to evangelize Perl and the dynamic way of life.

If you’re a speaker or trainer (or would like to be one), perhaps you could help discover and address the Perceptions of Perl in your area as well.

Contact TPF if you can help.