Stop worrying and learn to love Perl 6

| 12 Comments

Andy Armstrong graciously provides his take on Perl 6. I've even left those crazy Brit spellings. -- Andy

Perl needs Perl 6 and the wider Perl community needs to understand why.

When I first got into computers I worried, briefly, that everything I learnt would inevitably be outmoded. I don't want to scare anyone unduly but there will come a time when Perl 5 is outdated. Slow, ugly, verbose, arbitrary: it will become all of those and worse.

That is the fate of all languages. At least I hope that's the fate of all current languages. These days if I really want to scare myself I need only imagine that the current state of the art is is a good as it ever gets. If that doesn't worry you try to imagine a parallel universe in which our understanding of computers hit a glass ceiling any time in the past fifty years. Imagine COBOL as pinnacle of language design, 64k as a generous helping of memory, punched cards baby! Happy days, certainly, but I'm glad we were able to leave them behind.

As more of the world depends on computers there's a growing force that slows change. The enemy of evolution in language design is the installed user base. In the case of a successful language like Perl millions of people may now be affected by an incompatible language change. The Perl 5 Porters must always balance the needs of the future with those of the past and that places an upper limit of the rate at which Perl 5 can mutate.

What to do? How do you move forward if you're constantly looking over your shoulder? You take advantage of a fortunate property of software: that it is possible to simultaneously care for and conservatively develop the current active branch of a language and forge into the future with a clean new version. Two siblings: the elder healthy, but constrained by responsibilities, the younger relatively free and able to learn from the elder's mistakes without repeating them. Perl 5 and Perl 6.

"But Perl 6 is taking too long..."

But Perl 6 is taking too long to mature. More than seven years is embarrassing, right? Not really. Perl wasn't really the Perl we know and love until Perl 5. For the first ten or so years Perl was a lesser language. Sure, the step from Perl 5 to Perl 6 will be bigger than the step from 4 to 5. The jump from 4 to 5 was in its time the biggest seismic shift the Perl world had seen. There's a trend there; the steps are getting bigger all the time. There was no significant dynamic language movement when Perl 1 entered the world. Perl 6 is gestating in a rather different environment.

Perl 5 is not yet decrepit. Rumours of its death greatly exaggerated (or imagined). Perl 6 doesn't yet need to come of age so it makes sense for it to continue to mature in a relatively protected environment. As long as Perl 5 remains viable it's sensible to give Perl 6 the space it needs to grow because when its time comes it's going to face stiff competition from its elder and from Ruby, Python and others.

Rather than impatient foot tapping, Perl 6 needs the help and nurture of the Perl community. The Perl 6 development process is transparent and open. Anyone with something useful to contribute will be welcomed. If you self-identify as a Perl person then Perl 6 is in part your responsibility. And if you can't usefully contribute then, please, quietly reflect on the debt of gratitude you owe to those who do. They're working to guarantee your future.

Perl 6 is not a liability

Perl 6 is not a liability. There's no need to be defensive about it. Paul Cory would like to rebrand Perl 6 into the shadows. That's the kind of Stalinist revisionism favoured by corporations that realise that their "next big thing" has become an embarrassing albatross. It's a response to Perl 6 that the circumstances do not require.

Here are his reasons:

1) It emphasises the "inadequacies" of Perl 5.

All languages have inadequacies, imperfections, miss-features, cruft. Perl 5 is no different. Fortunately, instead of brushing them under the rug, the Perl 6 team is actively seeking to right those wrongs. A question: would you rather use a language that's maintained by people who are a) in denial about its inadequacies or b) actively developing a new language based on recognised shortcomings? I hope that's a rhetorical question.

2) It makes the development community look unorganized, at best. People comparing at the development pace of Python, Ruby and PHP to Perl 6 are likely to come to harsher conclusions about the community's focus, viability and competence, based on Perl 6's seven-year, and counting, gestation period.

Those hypothetical people are wrong and I don't want to be part of a community that panders to their views. The Perl 5 Porters are doing a great job of continuously improving Perl 5 within the constraints that popularity brings. The Perl 6 team are laying the foundations for the next generation of Perl. Perl 5 and Perl 6 have a mutually beneficial relationship: features, tools and ideas are traded freely between the two groups. It's healthy, responsible and creative.

Python and Ruby have, to their credit, somewhat similar splits between far sighted strategic development and tactical improvements to the current language generation. PHP is a bizarre bazaar that does not provide a model other language communities should emulate.

3) It creates uncertainty: what happens to Perl 5 when Perl 6 finally drops? How much new stuff will I have to learn? How will my existing code work, or not, if I upgrade? Why should I invest time in Perl 5 if Perl 6 is just around the corner, and will be far superior?

Learning to deal with an uncertain future comes with the territory of computing. Continual improvement necessarily means that things will change.

Perl 6 is visible proof that we have vision. Perl 5 is visible proof that we can maintain an extremely high quality programming language. These facts combined should give observers confidence about the health of Perl. As a community we certainly need to work to allay fears and calibrate expectations. But let's not start by hiding one of our greatest assets, ok?

4) It creates frustration inside the community. Perl 6 has been "coming soon" for 7.5 years now. It's hard to remain excited about something that long with no payoff.

Welcome to the world of free software. Instead of waiting for Godot we can go and meet him half way; help him carry his load. Let's be explicit here: if Perl is part of your life or career and you're tired of waiting for Perl 6 help make it happen.

You don't have to contribute code to help. Learn more about Perl 6 so you can explain it to others. If you find it hard to learn make it easier for others: write an article that explains some of the important points, give talks, learn so you can teach.

5) The story is confusing: Pugs? Haskell? Parrot? Two development tracks? I thought this was about Perl? Yes, I have an idea of what those things are, but most folks outside the community (and a fair few inside, I'd wager) don't know, don't care, and shouldn't have to.

If the story is confusing we need to tell it more clearly. That doesn't justify changing the underlying technical narrative.

In a commodified world criticism and spending discretion are the consumer's only levers. We crave influence over the things we consume. In the absence of direct influence over a product's design we use criticism as a proxy for control. We hope that they'll make the next version better as a result.

Criticism is still valid in the free software world but it's importance is de-emphasised. You can criticise or you can help. In fact you can criticise and help.

It's important that Perl 6 is not immune from scrutiny but if you're frustrated that it's taking a while then volunteer. The Perl 6 team is small at the moment; small enough that a few well placed contributions can make a real difference. Let's not default to bitching about it when we have the opportunity of contributing to its success.

Why not make 2008 the year you do something for Perl 6?

Andy Armstrong has been developing Perl programs and following the language's progress since Perl 4.036. He has released more than thirty CPAN modules and is currently working to help both the Perl 5 and the Perl 6 teams to implement parallelised execution of their test suites

12 Comments

Perl6 isn't a liability, but CPAN sure is.

Yes, I can write in Pugs right now and be happy. But The minute I think about converting a project to Pugs/6, I immediately realize that I don't have 99% of the other modules I use in v6 form. No DBI. No DBIx::Class, no anything, and who want's to start from scratch reinventing other wheels? (Yes, I know I can use v5 modules n v6...but then why not just stick to 5).

It's going to be hard to hit critical mass with Perl6 when all the modules we've come to know and love aren't along for the ride. Cart. Horse. Chicken. Egg. Damned if you do, damned if you don't.

This whole series of articles is really nice. It's great to see some quality information and reasonable thought on the subject after years of... well, you know.


Tangential to that, I'm glad to see perlbuzz becoming a place where the whole Perl community -- which, in my experience, is actually a fragmented pseudoentity than one actual group, even just among those who would consider themselves core developers or hardcore users.


As an example, this article ends with an exhortation to get involved and says that you don't have to code to help. Well, let's say that I'd like to use some of my spare cycles on Perl 6. Where do I go? Are there people willing to act as points of contact or do I need to just lurk in one of several possible IRC channels? Are there introductory/bootstrapping docs, or do I just have to start teaching myself Haskell and/or Parrot (Parrot is actually the more frightening option, because it seems to be not a single thing but a family of stacked languages and tools)?


Even people who have been engaged with portions the Perl community for years (counting myself here) can be uncertain and confused about what Perl 6 is and how the hell to go about getting a grip on it -- particularly (to continue using myself as an example) the sort of people who are pretty good at Perl 5 but don't have the time to learn 1d6 new languages and develop an understanding of the finer points of virtual machine design.


Don't take this the wrong way. I'm not scaremongering or hating on Perl 6. I legitimately would like to learn more and help out -- language design fascinates me -- but have been legitimately confused, and felt malinformed, for years. As a result my feelings on Perl 6 slowly slid from Anticipation to Apathy to a mild Antipathy. And I'm willing to bet I'm not the only one who fits this pattern.


To end on a less bitchy note, I know from personal experience how difficult it can be to articulate to outsiders exactly what a large project is, especially one which breaks many preconceptions. And it only gets harder when the project is in flux due to lessons learned being applied on-the-fly. These circumstances also exacerbate the problem of producing introductory materials and allocating resources to bringing new people up-to-speed. I'm aware that the sort of things I'm asking for are the most difficult to produce. It's also what I'd be most willing to start helping out with.


Okay, I'm done talking now :)

A good place to start is the Perl 6 Internals mailing list:

http://www.nntp.perl.org/group/perl.perl6.internals/

Just signing up and watching the traffic will give you an idea of which way the work is headed.

@Christopher:

The fact that most of our favorite CPAN modules have not been ported to Perl 6 is part of what gives the language freedom to evolve and grow, as Andy mentioned. I have no doubt that, as Perl 6 reaches maturity, we will all get busy making sure our favorite modules will be available.

In fact, some of us relish the opportunity to invent a better wheel :) Not to mention the freedom to clean up all the cruft we've maintained out of courtesy to our established user base. The CPAN is not a liability -- it is storehouse of ideas that will give us a good start at making Perl 6 as TIMTOWTDI and DRY as Perl 5 is today.

Bravo!! Fantastic article and discussion on a great new medium. Perl Buzz rocks!!!

It's good to see such a well put together reply to my editorial. Unfortunately, my original editorial did not communicate as clearly as I would have hoped, based on what Andy Armstrong said above.

So, using his rebuttal as a guide, I'm going to try to clarify some places where my ideas were garbled in transmission.

Before I start, though, I think I need to correct an overall shortcoming in my original piece.

I neglected to make clear that I was talking primarily, with one exception, about communicating with the world outside the Perl community. I also completely failed to say anything about how that audience differs from the Perl community, and how that affects our attempts to communicate with them

That outer world is not as knowledgable about Perl, and not invested in Perl, as the Perl community is. As a result, it has a limited desire to hear complex, long narratives, and a limited ability to parse complex narratives accurately, especially if those narratives contain seemingly contradictory points. A perfect example of the kind of narrative that confuses this audience would be something like:

"Perl 5 has reached the end of its rope. The internals are so bogged down, it's difficult to improve, so we're pulling our top development squad off to build and entire new and improved Perl from scratch. That's Perl 6, coming ... well, we're not sure. Sometime in the next decade, we think. Perl 5, by the way, rocks, so don't stop using it."

To communicate effectively with the external audience, you have choose your narratives carefully, limit the number of narratives you put out, and do your best to limit how those narratives compete with each other. You have to keep it simple and short, because you have only a limited window of time in which to communicate. This means you have to focus your narratives to be successful.

Yes, this means you lose a lot of nuance, and you end up glossing over a lot of complexities. That's how public communications works in this age of dying journalism and short attention spans. We have to adapt.

Now, on to the point-by-point:

Paul Cory would like to rebrand Perl 6 into the shadows. That's the kind of Stalinist revisionism favoured by corporations that realise that their "next big thing" has become an embarrassing albatross.

While first line is correct, the second line is a fundamental distortion of what I said. I suggested no rewrites of history, no attempts to deny the history of Perl 6 and what has been said about it previously.

I did suggest was that we move the public spotlight off Perl 6 and put it on Perl 5. Yes, that puts Perl 6 into the shadows, but since it's not ready for the stage, and won't be for an undetermined while yet, that's where it belongs. The spotlight shouldn't shine on Perl 6 until it's ready to strut. And by strut, I mean ready to release in a generally usable state.

I also suggested a name change, which is probably where the bogus comparison to Stalin came from. I did not make the suggestion hoping to rewrite history, but to more accurately reflect the state of the project and remove some of the unintended negative perceptual effects of the name.


1) It emphasises the "inadequacies" of Perl 5.

All languages have inadequacies, imperfections, miss-features, cruft. Perl 5 is no different. Fortunately, instead of brushing them under the rug, the Perl 6 team is actively seeking to right those wrongs. A question: would you rather use a language that's maintained by people who are a) in denial about it's inadequacies or b) actively developing a new language based on recognised shortcomings? I hope that's a rhetorical question.

I obviously wasn't clear, as Andy completely missed my point here.

My point was not that we should publicly dance about singing "Lalalalala!" and pretending Perl 5 doesn't have issues.

My point with this statement and it's companion from later in the editorial: "Allows us to focus on the strengths and successes of Perl 5," was this:

You don't succeed by talking primarily about your weaknesses.

When the dominant narrative is about your problems, instead of your strengths, you lose. Mind share, market share, appeal, and support all dwindle.

Look at Internet Explorer 6. When was the last time you heard about it's strengths? Is its market share decline over the past few years really a surprise when the public conversation, the dominant narrative, has been focused almost soley on its problems?

Yes, Perl 5 isn't perfect, and I don't advocate that we tell anyone that it is. But when we talk about Perl and Perl 5 with the outside world, we want to focus on our strengths and successes, because we want them to focus on our strengths and successes.

2) It makes the development community look unorganized, at best. People comparing at the development pace of Python, Ruby and PHP to Perl 6 are likely to come to harsher conclusions about the community's focus, viability and competence, based on Perl 6's seven-year, and counting, gestation period.

Those hypothetical people are wrong and I don't want to be part of a community that panders to their views.

Changing how we communicate about Perl to correct and prevent misconceptions in the greater public is not pandering. Speaking to the greater public in a way they can process and understand is not pandering. It's good communications.

The Perl 5 Porters are doing a great job of continuously improving Perl 5 within the constraints that popularity brings. The Perl 6 team are laying the foundations for the next generation of Perl. Perl 5 and Perl 6 have a mutually beneficial relationship: features, tools and ideas are traded freely between the two groups. It's healthy, responsible and creative.

Python and Ruby have, to their credit, somewhat similar splits between far sighted strategic development and tactical improvements to the current language generation. PHP is a bizarre bazaar that does not provide a model other language communities should emulate.

Agreed, on all points. I never questioned the work being done, or the need for it. I questioned the efficacy of how we communicated that work.

3) It creates uncertainty: what happens to Perl 5 when Perl 6 finally drops? How much new stuff will I have to learn? How will my existing code work, or not, if I upgrade? Why should I invest time in Perl 5 if Perl 6 is just around the corner, and will be far superior?

Learning to deal with an uncertain future comes with the territory of computing. Continual improvement necessarily means that things will change.

Uncertainty is a constant, true. However, when the uncertainty level gets too high, people and organizations look to migrate to less uncertain circumstances. Uncertainty about the future of Netscape is an oft-cited reason for my workplace going Internet Explorer-only many years ago: lots of other people and companies making that same decision for that same reason killed Netscape. Our communications with the greater public should not create unneeded uncertainty.



Perl 6 is visible proof that we have vision. Perl 5 is visible proof that we can maintain an extremely high quality programming language. These facts combined should give observers confidence about the health of Perl.

That's good. I can see the beginnings of an effective narrative there.

As a community we certainly need to work to allay fears and calibrate expectations. But let's not start by hiding one of our greatest assets, ok?

It's not one of our greatest assets until we figure out how to communicate effectively about it. And, to this point, we've done a pathetic job of managing expectations.



4) It creates frustration inside the community. Perl 6 has been "coming soon" for 7.5 years now. It's hard to remain excited about something that long with no payoff.

Welcome to the world of free software. Instead of waiting for Godot we can go and meet him half way; help him carry his load. Let's be explicit here: if Perl is part of your life or career and you're tired of waiting for Perl 6 help make it happen.

True, but beside the point. The point is that continually hyping something that doesn't arrive has a corrosive effect on community morale and interest.

This points to an communications breakdown inside the Perl community. We need to do a better job of keeping the community educated about what's happening, engaged in the process, and of managing expectations. Detail information seems to be easily available, but effective quick-hitting overview stuff, and expectation management seem to be missing at this moment. That seems as if it might be changing, though.




5) The story is confusing: Pugs? Haskell? Parrot? Two development tracks? I thought this was about Perl? Yes, I have an idea of what those things are, but most folks outside the community (and a fair few inside, I'd wager) don't know, don't care, and shouldn't have to.

If the story is confusing we need to tell it more clearly. That doesn't justify changing the underlying technical narrative.

I don't recall suggesting that the underlying technical narrative be changed. I suggested we talk less about Perl 6 and more about Perl 5, especially to the greater public.

This highlights a problem I see. The reality is that we need a simplified narrative for the greater public. There seems to be a misconception that "simplified" equals "untruthful" or "deliberately misleading". Or, to be blunt, that we need to lie and bullshit about Perl in public.

I was not and am not advocating lying, bullshitting or the use of any deception. That is poor public communications, and would only come back to hurt us.

However, choosing to talk more about Perl 5, its strengths, successes and constant improvement, and less about Perl 6, is not deceptive. Coming up with a simplified, positive narrative about Perl 6 that communicates effectively (and truthfully) with the greater public is not deceptive. It's pragmatic, and it's needed.


And now, for a completely positive post, here are some draft potential narratives for use in communicating with the greater public:

Perl 5

Perl 5 is stable, ultra-capable, scripting language used by thousands of programmers daily and by some of the biggest, busiest Web sites in the world. Perl 5 is under active development, with a core group of programmers releasing a constant stream of improvements and enhancements, and vast group of programmers constantly updating and expanding the unequalled CPAN shared code archive.

Today, Perl 5 is the perfect choice projects of any scale or methodology, including those using the popular MVC design paradigm. As for tomorrow, Perl 5 will continue to improved and enhanced well into the next decade, and most likely, beyond.

Perl 6

Perl 6 is an ambitious project to push Perl's capabilities beyond the envelope of what is currently considered possible. It is the distillation of the community's 20 years of experience in creating scripting languages, fused with new technologies, the best ideas from other languages and a vision of what a scripting language can do. Current Perl users need not worry, though - the end result will still be Perl, just better.

Perl 6 doesn't have a set delivery date. Pushing the envelope this far has required the Perl 6 team to write Perl 6, from the underlying Virtual Machine on up, from scratch, and renders making accurate predictions about timelines impossible. Perl 6 will be announced when it is ready, and not before. If you're curious, you can follow the progress of Perl 6 development at http://planetsix.perl.org/ .

Perl 5 and Perl 6

Perl 5 and Perl 6 are being developed in parallel. This parallel development will continue long after Perl 6 is released. Perl 5 has a long life ahead; it is too important, too vital, and too capable to bury prematurely.

For the "Where do I start?" and "How do I get involved?" sorts of questions, the answer should always include "Start by checking out the official Perl 6 and Parrot wikis". These wikis are intended to answer all those sorts of questions, plus much more.

You can find the wiki links under "Other Sites" in the right column of PerlBuzz. Here they are for your convenience:

http://www.perlfoundation.org/perl6 -- Official Perl 6 Wiki

http://www.perlfoundation.org/parrot -- Official Parrot Wiki

Please post these links where appropriate.

Contributions of content (and relevant links) plus corrections are always welcome and encouraged.

Thanks for the clarification Paul and apologies for any misinterpretations on my part.

Whatever other differences of opinion we may have (probably more minor than the headlines suggest) I agree completely that we need to step (virtually) outside the Perl community and get better at seeing Perl the way the rest of the world sees it. And *that* is certainly a way anyone who's interested can help.

I hate to be a spelling pedant (well ok, I secretly enjoy it, but shh, don't tell anyone), but I'm pretty sure that "in denial about it's inadequacies" is an error no matter which side of the Atlantic you're on...

hmm...People who are using the Perl5 they are crazy about it and they are also looking for new release of Perl6 and that will really help them in a great way..

I am also at hand in this great programming language....http://www.5050webs.com

Leave a comment

Job hunting for programmers


Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.