Can dynamic languages scale?

January 24, 2008 Opinion 3 comments

Ted Neward has written an article on the problems of scaling up projects based on dynamic languages:

While a dynamic language will usually take some kind of performance and memory hit when running on top of VMs that were designed for statically-typed languages, work on the DLR and the MLVM, as well as enhancements to the underlying platform that will be more beneficial to these dynamic language scenarios, will reduce that. Parrot may change that in time, but right now it sits at a 0.5 release and doesn’t seem to be making huge inroads into reaching a 1.0 release that will be attractive to anyone outside of the “bleeding-edge” crowd.

Alas, he has to end with “Perl just sucks, period.” Even as we work forward with Parrot and Perl 6, the continued public perception of Perl doesn’t change. 🙁

Which language to inflict on clients?

January 9, 2008 Business, Opinion 2 comments


Originally uploaded by reedwade

Brenda Wallace posted a colleague’s picture of a whiteboard from their office today.
Her post says “dunno which technology to inflict on my clients next, so we had a brainstorm. looks like TCL won.”

The whiteboard reads:

Lisp is bitter
PHP is DancingBear
Python is beige
Erlang is imaginary
Ruby is a fad
Java is angry
Tcl is cute
Perl is ready for retirement

Certainly I don’t think Perl is ready for retirement, but it’s interesting to see what people think about Perl, and about all its brethren.

Stop worrying and learn to love Perl 6

December 28, 2007 Opinion, 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

Why Perl 6 needs to be deemphasized and renamed

December 28, 2007 Opinion, Perl 6 18 comments

Paul Cory has contributed what I hope is the first of many guest editorials on Perlbuzz. — Andy

Recently, Andy Lester wrote about the zombie question that haunts
Perl: Where
is Perl 6?
One of the questions he posed was:

“And to everyone else, who is willing to help in this task, to help keep the fires of anticipation burning in the public?”

My advice would be to not keep the fires of anticipation burning in the public. For the good of the language, Perl 6 needs to be deemphasized in public, and, in addition, renamed.

How Keeping Perl 6 Front-of-Mind Hurts

1) It emphasizes the “inadequacies” of Perl 5.

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.

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?

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.

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.

Basically, the more we push Perl 6, the more we Osborne ourselves.

How Keeping Perl 6 Front of Mind Helps

I got nothing. Honestly, I can’t think of a single positive for trying to keep public anticipation burning.

How Deemphasizing Perl 6/Changing its Name Helps

1) Allows us to focus on the strengths and successes of Perl 5.

2) Allows us to tell the development and improvement success story of Perl 5, which is as good as that of any other scripting language.

3) Removes uncertainty that can be used against Perl when companies and developers make decisions about which language to use.

4) Finally, by changing Perl 6’s name, to something like PerlNG or PerlFG, we can get away from the “It’s just a 1 point upgrade,” problem and have a basis for which to talk about it as a “research project.” That allows us to both avoid talking about delivery dates, and allows to talk about how cool stuff from PerlNG is finding its way back into Perl 5.

5) Gets us away from all the negatives listed above.

How Deemphasizing Perl 6/Changing its Name Hurts

1) It might be harder to get folks to work on PerlNG if it’s not “just around the corner.” I happen to think that can be overcome with inside-the-community marketing.

For the record, I greatly appreciate all the work that folks have put into Perl 5 and Perl 6. Nothing here should be taken as a criticism of how the actual development gets done, nor of the talent or the commitment of the developers.

I don’t question the desirability of Perl 6 either. I can see how, when it’s finally finished, it will be an improvement over any language available.

However, from a Communications standpoint, it’s obvious that there are significant problems in communicating about perl to the world at large.
Perl 6 has been a Public Relations disaster, one that has made it harder to attract developers, other contributors, users and companies.

Again, from a Communications/PR standpoint, our goal should be to stop shooting ourselves. And that means taking the public focus off Perl 6 as much as possible.

Paul Cory is the Webmaster for the Wake County Public School System in
Raleigh, North Carolina. He started using Perl nine years ago to
automate some particularly tedious Website updates, and has progressed
to the point where Perl glues the entire system website together.

Where is Perl 6? The question that won’t die

December 26, 2007 Business, Community, Opinion, Perl 6 20 comments

Every so often I get asked that dreaded question “When is Perl 6 coming out?” Sometimes it’s a local Perl Mongers meeting, and sometimes it’s an email like below, from a reporter at cnet.com, in response to my Perl 5.10 announcement:

What’s up with Perl 6/Parrot? I’ve never covered the issue terribly
closely, but it seemed that there was one school of thought that argued
for some universal virtual machine and another that wanted to keep Perl
more with its duct-tape-of-the-Internet roots. Please feel free to set
me straight in this area–I have only passing familiarity.

Is Perl going to stay on a dual 5.x and 6.x track? When is 6 due? How
about 5.12?

Stephen Shankland
reporter, CNET News.com
blog: http://www.news.com/underexposed

This is not at all uncommon as a perception. People just don’t know about Perl 6, don’t know about Parrot, and certainly have never heard of Pugs. Here’s what I replied:

Perl 6 is a rewrite of the Perl language. It will feel Perly, and yet become more modern as it pulls in influences from languages like Ruby and Haskell.

Technically, Perl 6 is just a language specification, and there are at least two implementations underway. One of the Perl 6 implementations is named Pugs, and is written in Haskell, on a project led by Audrey Tang. The other Perl 6 implementation is being written to run on top of Parrot. Parrot is a virtual machine for running modern dynamic languages like Perl, PHP and Ruby, among others. The intent is to have Parrot bytecode generated by one system, say, Perl 6, easily interact with any other language’s Parrot bytecode.

Yes, Perl 5 and Perl 6 will stay in dual development. Perl 5 has such a huge installed base, it won’t be going away any time soon after Perl 6 exists.

There is no due date on Perl 6, and never has been. At this point it’s still sort of a big research project. Fortunately, some of the development in Perl 6 has found its way into Perl 5.10, such as the “say” keyword and some regular expression improvements.

I don’t think the Perl 5 Porters have even started thinking about a timeline or feature set for 5.12 yet, since 5.10 has only been out for eight days now. From my monitoring of the perl5-porters list, we’re just trying to make sure that problems people are reporting with 5.10 are not actually problems with 5.10 itself.

Let me know if you have any other questions.

I’ve published this open response for two reasons. First, I wanted the core Perl community to get an idea of what outside perception of us is like. People know bits and pieces of what we here in the Perl core echo chamber know.

Second, I wanted to raise the flag again of how outsiders want to know more about Perl 6, and that the first, and in many cases only, thing that they want to know is “Where is it and when will it be out.” I’ve never felt that the Perl 6 development team has ever been interested in addressing the concerns of those who ask.

Note that I’m not talking about giving a timeline, or a schedule, because of course Perl 6 is being created by volunteers, and there’s no point in giving a schedule if the project can’t realistically hit it. What I did say was “address the concerns.” Maybe the project can’t give the people want they want, but is there something they can give to help satisfy the hunger, and keep people interested?

For that matter, I’ve never felt that anyone on the Perl 6 development team even saw it as a reasonable question to ask. I’ve always seen the question answered with angry, defensive replies. Such a problem to have! People clamoring to use your project!

It’s amazing to me that we have any goodwill left, any interest, that Perl 6 hasn’t been written off as permanent vaporware. To the Perl 6 community, I ask, what can we as the rest of the community do to help keep people interested in Perl 6? Do you see that as a reasonable goal? And to everyone else, who is willing to help in this task, to help keep the fires of anticipation burning in the public?

State of the Onion 2007: Let’s go scripting

December 7, 2007 Opinion 2 comments

It makes me sad to hear Perl programming called “scripting”. “Stop saying script” is a common refrain of mine. I gave a lightning talk about this at OSCON 2007, and a few hours later, Larry Wall, Perl’s creator, gave his State Of The Onion in the same room, and reviewed my lightning talk like so:

_   /|
U    ack --thpppt!

Well, if you’re gonna get dissed, might as well be by Larry, right? To read why he disagrees with me, see his just-published transcription of the State Of The Onion. I agree with his points, and yet, my core concerns about “scripting” being seen as not really programming still stand. How to combine the two?

Perl gratitude, 2007

November 22, 2007 Community, Opinion 1 comment

Here in the US, it’s Thanksgiving, a day of eating lots of food,
watching football, and sometimes, just sometimes, expressing gratitude
and giving thanks for those things that make life wonderful.

Here are the things I’m grateful for in late 2007, in no
particular order after the first.

Google Code

Google’s project hosting
has been a godsend. It’s changed the way I do open
source projects. It has leapfrogged SourceForge for ease of
maintenance, and the bug tracker trumps RT
for CPAN
that we’ve been using for so long. Add that to the
integration with Google Groups which makes it trivial to create
mailing lists, and it’s at the tops of my list for 2007. I can’t
say enough good about it.

The readers of Perlbuzz

Eleven weeks ago, Skud and I started this little website called
Perlbuzz as an alternative to
the “more traditional outlets” for news in the Perl world. The
response has been tremendous. We get 600 RSS readers every day,
and have had over 10,000 unique visitors in that time. It makes
me happy that our little venture is used and appreciated by the

Test::Harness 3.0

It’s been over a year in the making, but the new version of the crucial
Test::Harness 3.0
means more flexibility for module authors, and
lots of UI improvements for people who just want to run prove
and make test.

Mark Dominus

MJD is so much a fixture in Perl it’s easy to forget that he’s
there. For 2007, though, never mind all the things he’s done for
Perl in the past, or the hours I’ve spent being enthralled in talks
of his. His Universe Of Discourse
is the single most intelligent blog out there, and sometimes
it just happens to be about Perl.

Andy Armstrong

Was Andy Armstrong always around, or did I just not notice? His
time and dedication spent on climbing on board with Ovid and Schwern
and the rest of the Test::Harness 3.0 crew has been invaluable in
getting it out. Plus, he’s a really swell guy anyway.

Dave Hoover

When I finally despaired of the amount of time and frustration
it took to organize content for Chicago.pm‘s Wheaton meetings,
Dave Hoover stepped up and volunteered to take it over. I’m thankful,
but not as much as I hope the other Chicago.pm folks are.


I’m all about having the machine keep an eye out for the stupid things
we do, and the goodness of Perl::Critic
is always impressive. You won’t like everything Perl::Critic says about your code,
but that’s OK. It’s an entire framework for enforcing good Perl
coding practices.

The Perl Community in general

The Perl community is populated by some tremendous folks. Some
names are more known than others, but these people help make daily
Perl life better for me. In no particular order, I want to single
out Pete Krawczyk, Kent Cowgill, Elliot Shank, Liz Cortell, Jason
Crome, Yaakov Sloman, Michael Schwern, Andy Armstrong, Ricardo
Signes, Julian Cash, Jim Thomason, chromatic, Chris Dolan, Adam
Kennedy, Josh McAdams and of course Kirrily Robert. If you think
you should be on this list, you’re probably right, and I just forgot.

My wife, Amy Lester

Because even if she doesn’t understand this part of my life, she
at least understands its importance to me.

I’d love to hear back from any readers about what they’re thankful for. I’m thinking about having a regular “Love Letters to Perl” column where people write about what they love in Perl.

Schwern has killed off Perl 5.5, and I thank him

November 18, 2007 Opinion, Perl 5 3 comments

I applaud Michael Schwern’s announcement today that he will no longer be supporting Perl 5.5 in any of his modules. Toolchain modules like Test::More and ExtUtils::MakeMaker will be compatible with Perl 5.6.0, and others with 5.8.0. As Schwern puts it, “5.5 is effectively end-of-lifed.” And not a moment too soon, I believe. Perl 5.6.0 came out seven years ago, and 5.8.0 five.

Schwern’s breaking point was seeing the Perl Survey results that only 6% of respondents use Perl 5.5. Most of all, he points out:

Finally, I’m coming around to chromatic’s philosophy: why are we worried about
the effect of upgrades on users who don’t upgrade? Alan Burlson’s comments
about Solaris vs Linux are telling: if you’re worried more about supporting
your existing users then finding new ones, you’re dead.

I applaud Schwern’s radical break from the past. No longer will he be “hamstrung from
using ‘new’ features of Perl,” as he puts it. This will allow him the freedom to do more great things as I fully expect he will.

Most of all, I’m glad that he just did it. No committee, no call for consensus, no poll of people to see what everyone thought. JFDI, baby, JFDI.

Who among us will be the first to write a module that takes advantage of Perl 5.10’s new features, urging us all forward, instead of mired in the mud of the past? I can’t wait to see it happen.

Evolution requires mutation

October 11, 2007 Opinion 15 comments

In the past couple of days, I’ve seen some counterproductive
social behaviors that help scare away community members and lead
to boring monoculture: Taking a public dump on the projects of others when they do not directly affect you.
It’s rude, it discourages future risk taking in everyone,
it goes against the very nature of open source that has
brought us here today, and it leads to monoculture. I’d
like people to stop.

Mutation #1: kurila

Gerard Goossen recently released
a fork of Perl 5 that includes some speedups and tweaks
that seem to scratch Gerard’s itches, as well as bundling extra
modules. I’m right now trying to get an interview with
him to find out more about his project and the reasons
behind it, because there are probably some interesting
lessons in there. However, the disapproval on the Perl 5 Ports list
was swift and severe.

All forking based on the Perl 5 syntax and code base,
throwing away CPAN compatibility, seems to me to be a
complete worthless waste of time.

So what? Who is anyone to say how Gerard is to use his time?
Is there any harm here? No? Then leave the guy alone, please.

Mutation #2: lambda

Eric Wilhelm released lambda,
a distribution that lets you
use the Greek character lambda (&#955) as an alias for sub
, apparently as a nod to Python’s lambda
keyword for anonymous functions. Immediately people jumped
on him saying that the module should go into the Acme::
namespace, as if the namespaces of CPAN mean anything in
2007. There was also this cluck-cluck from someone I figured
would be more encouraging (and later apologized, as it turns out):

Well, if you want to use it in your own code and your work’s code,
that’s fine (because I’m sure you find typing CONTROL-SHIFT-EL so much
easier than “sub {}” 🙂 but if it shows up in your CPAN modules, you
might get a few complaints since this sugar, while a really nifty hack,
adds nothing complex but does screw up older editors and will confuse
the heck out of a lot of maintenance programmers.

Personally, I figure that if someone’s a smart enough
programmer to do a hack like the lambda module, he or she
is also smart enough to figure out potential downsides.
And so what if he doesn’t? What’s the harm here?

Mutation #3: perlbuzz

Perlbuzz itself has always come under this umbrella of disapproval. Even before
we announced the site, Skud and I have fended off the comments saying “We already have
use.perl.org, we don’t need Perlbuzz.” Maybe not,
but why do you care if we start the site? Why does it bother you? And why do you
find it necessary to tell us that we’re embarking on a waste of time?

I hope that in the past few months, the work that Skud and I have done have shown
you, the reader, that Perlbuzz is a worthwhile addition to the Perl community,
and a valuable news source that overlaps other news sources while not being a subset.
What if Skud and I had listened to the tsk tsk of the doubters?
Perl would be right where we it was before, with nothing new.

Evolution requires mutation

Why are we so quick to take a dump on the projects of others?
The only way anything interesting happens is that people
try weird, new things and see what sticks. What if Larry
had listened to those way back when who said “Ah, we’ve got
Awk and shell tools, we don’t need Perl?”

I fear our tendency to monoculture. I want crazy new projects to thrive,
not get squashed at their very infancy. Next time someone comes out with a project
that you think is silly, congratulate the person rather than scoffing at it. Who
knows what it might lead to?

(And a big thank you to Jim Brandt for the “Evolution requires mutation” idea.)