How to Sell Perl 6
With a beta of Perl 6 probably being less than two years away, many of us wonder about its future. I'm optimistic. While I've been paid for programming in other languages, I specialize in Perl. I know it well, I'm comfortable with the language and I'm so excited about the new features of Perl that I, like so many other programmers, am eagerly awaiting the opportunity to take her out for a spin.
My other motivation may seem a bit strange, but I have a strong loyalty to the Perl community. The language certainly has its quirks, no doubt about it, but it's you, the community, which makes it worthwhile. You've taught me how to program. Before, I was your typical hack. Now, by engaging with the community, learning from some very bright individuals, and spending a lot of spare time dabbling on YAUP (Yet Another Unfinished Project), I've learned quite a bit about computer science, project management, and fatter paychecks. You've taken me overseas and across the country. In short, you're great. You're also in a bind and that bind is Perl 6.
(There are some comments in the following that might be viewed negatively, so I don't name the people associated with them. They can out themselves if they choose -- assuming they're on Perlmonks)
My goal in this is to start some discussion about the future and maybe figure out where Perl is headed, where we want it to go and what it will take to get it there. I'm not a leader in the Perl community and I don't claim that participating in this discussion will have any great benefit, but I hope it might just spark a few ideas and perhaps allow individuals to better plan for their professional future.
This is almost a side issue, but I've heard it enough that I've felt it worth addressing. Many of you, by now, have heard the ``never rewrite!'' mantra. Joel Spolsky argues it passionately, chromatic seems sold on the idea and Netscape hung itself by ignoring it. In fact, despite once being skeptical, I now agree that scrapping any sufficiently large program and rewriting it from scratch is usually the kiss of death.
Perl 6, so far, seems to have avoided many of the ``no rewrite'' problems by still having a robust, useful product available during the rewrite. Perl 5 is still being actively upgraded and the Perl 6 development process has led to a burst of Perl 5 activity. This has maintained interest in Perl and has given us a position that many ``for profit'' firms can only envy. Thus, I think those who predicted doom due to a complete rewrite were wrong, but they can hardly be blamed for said prediction. It's right more often than not.
Many people seem to be afraid of Perl 6, though. Some major players in Perl have publicly stated that they see no reason to switch to Perl 6 when it comes out. At least one has recanted (that I know of), but others feel that the new Perl won't be Perl.
Yet another person has told me he's scared to death of Perl 6. His business is heavily dependent on Perl 5 and the upcoming Perl 6 puts him in a curious position -- which Perl does he market? Trying to market both might be a disaster, but switching horses at the wrong time could be even worse.
In fact, your author once considered switching to Java due to fears about the Perl market collapsing. Now, I have a great, stable job, but I do know I'm in a smaller pond than some other languages. Perl 6 may turn it into a lake or a puddle.
Perl 6 had to happen, though. Perl's very popularity started showing its weaknesses. The limits of Perl typically mean that larger projects require more highly skilled, expensive programmers to use it effectively and this can tremendously reduce the supply of developers (moreso, I would suggest, than some other languages). Companies that didn't understand this would hire less skilled developers and possibly conclude that Perl itself was a bad idea; programmers are loathe to admit (or recognize) they're the ones to blame.
For example, when working on small projects, we don't worry too much about the fiddly bits -- how often do you need a linked list in Perl? That frees the programmer to think about the problem rather than the implementation. Unfortunately, when working on large projects, you often have to pay more attention to those fiddly bits than you would in, say, Java. Want to subclass Class::MethodMaker to allow chained mutators? If you do, you have to dig into the guts of the module. Newer versions of this module changed an internal scalar to a hashref and this broke code that happened to override the _make_get_set method. You subclass this module at your peril.
A more common example is simply subclassing anything. If the parent class implements an object as a blessed hashref that's pretty much what you're going to do, too. Now, however, you not only need to know what data structure it's using, you have to know the names of the keys. But it gets worse! You also have to know the names of private subs that should not be accidentally overridden. Not knowing those implementation details can make life very difficult.
There are plenty of other issues we can point out about Perl 5, but it's still a pretty darned good language. Perl 6 builds on the strengths of Perl 5, fixes the problems that were there and offers bucket loads of programming goodness -- while still making easy things easy. Sticking to Perl 5 would have made that tough.
So the question remains, whither Perl 6? Will it wither (ha!) on the vine or will it bear sweet, paycheck laden fruit? (OK, I never claimed my analogies were great.) Really, it boils down to two simple concepts: supply and demand.
If there is no Perl 6, no one can choose it. When a company is considering a programming language, two of the most important things they look at are the supply of software packages for it and the supply of developers. Almost universally, a new programming language initially has an adoption lag while companies wait to see if it's going to be supported. Fortunately for Perl, backwards compatibility has been a serious goal and and Project Ponie, sponsored by Fotango (go, Arthur, go!), has the potential of allowing most Perl 5 code to run unmodified. This will be a huge boon. If successful, the supply of software packages supporting Perl will simply not be an issue.
Developers, however, are another issue. If there are few Perl 6 developers, companies will be very reluctant to switch. Ponie does not solve this problem. Even if you urge your company to switch to Perl 6 on the basis that your developers can write in Perl 5, the obvious question is ``then why don't we stick with Perl 5?'' Of course, if your company's never used Perl in the first place, it's an even harder switch. Programmers are going to have to knuckle down and learn the new language and convince the market that there are enough of them out there. Perl 6 is relatively easy to learn if you already know Perl, but we need to start now rather than wait to see how things are going to play out.
Demand is the tough part. Demand is closely tied to price. Perl, despite the popular misconception, is not free for a company. They have to hire developers. The salaries they're willing to pay are often based upon the perceived return on investment. This means that the Perl community needs to convince management that Perl 6 will save them even more money than Perl 5. Coroutines are nice, but your boss doesn't care. She also might not care that you can easily interface Perl 6 with other languages. If they're so great, why aren't we using them instead of Perl?
Part of the problem here lies in how Perl is explained. If we say ``Perl 5 wasn't very scalable but Perl 6 is,'' then we've just blown much of the benefit of the CPAN and Ponie. Oops! However, this seems to me to be one of the biggest benefits. I used to say ``Java's safe and Perl is powerful.'' With Perl 6, I think we'll get both, but it can be tricky to explain. Further, as a matter of ethics, I think it would be wrong for any programmer to pitch Perl 6 just because it's Perl. We have to have good, solid reasons for why Perl 6 is the next best thing.
Unfortunately, we don't have Sun's marketing budget. Buying full-page color spreads in magazines they read is probably not going to happen. We'll likely continue in the same "word of mouth marketing" style that built Perl in the first place. While this isn't necessarily bad, it's less likely to have the impact on the decision makers.I think the way to go is to continue to hammer on the speed of development and the resulting cost savings. There's no way a C++ developer is going to build a large application as fast as you will with Perl 6. What? He's got strong typing? So does Perl 6, if you need it. Java has a better OO model? We can debate that with Perl 5, but not, I think, with Perl 6. Further, while Perl 5 was fast enough for many business needs, Perl 6 promises to be faster still and dropping to Parrot assembly or even C, if necessary, is a snap.
Convincing programmers might be even easier. Management usually has the final say in what technologies to adopt, but the techies have influence, if you can sell them. You need procedural programming? Check. OO programming? Check. Functional programming? Check. Logic programming? Check (OK, some might quibble at the last two.) You need a domain specific language? It turns out to be pretty easy. On top of all of this, it turns out to be even easier to learn than Perl 5 (which really isn't that hard once you get over the sigils) and offers them power that few other languages can touch.
I think Perl 6 is going to be big, largely due to Parrot, but also due to some great design choices. I can't say I agree with all of them, but hey, who does? However, Perl 6 is not going to be big unless we can boost demand. That means having plenty of programmers available to mitigate the supply problem and convincing the decision makers that Perl 6 is the answer to their prayers. The latter might be easy, but techie types often don't speak the same language as the business types, so this is up in the air.
So think about Perl 6. Read the Exegeses (and the Apocalypses), subscribe to a Perl 6 list or two and consider what it will take to turn Perl 6 into the next killer app.