September 2010 Archives

Is it possible to think too highly of Moose? Most of what I want in a deprecation policy is in Moose's deprecation policy. Loosely rephrased (so believe the official published Moose policy, not my interpretation of its words):

• It's better to do things right than to do things the way everyone's always done them previously.
• Undocumented behaviors are unsupported behaviors. They can and will break.

Consider technologies which lack defined upgrade, version, and obsolescence paths: Microsoft Windows, SMTP, PHP, the JVM.

Consider technologies which have defined upgrade, version, and obsolescence paths: Perl 6, Moose, the Linux kernel.

Which would you rather use? Java the language has the patina of type safe collections, but Java bytecode (apparently) can't change to support real type safety. PHP has never met a half-baked feature-adding patch it doesn't like, even if that patch gets in the way of something better a few years in the future. (I half expect PHP 6 to restart development by adding drive letters as namespace anchors, say C:\This\is\my\PHP\Namespace.) Various Windows kernels have included workarounds for bugs in specific DOS programs and 16-bit Windows programs.

I suppose if you see programming as an occasional exercise where you blurt out a few pages of code and spend the rest of your life hoping never to touch that machine again, there's value in nothing ever changing (though here's the source code to old versions; go crazy).

Meanwhile, if the price I pay for using Moose or Perl 6 or whatever is that I need an explicit declaration of the version I intend to use and I need to pay attention to upgrades but in return my code gets a little faster, a little cleaner, and a little more correct, that seems like a bargain. After all, I use these tools because they make me more productive. Why would I limit myself with the baggage of having to support accidental, undocumented features used by code I can't even prove exists?

(The Parrot world once had a brief debate over whether our deprecation policy covered the names and orders of struct members in Parrot's C data structures. Imagine wanting to clarify the name of a variable and having to wait three months even if accessing that code from outside of libparrot represented an egregious violation of encapsulation so much that you'd have to copy and paste literal source code between files. The flip side of the "Sane deprecation is good" argument is "Design and document an effective API". Then again, you have to be able to recognize insane APIs, which is not an easy task when you have Stockholm Syndrome from suffering under the reign of actively hostile interfaces.)

Optimization is the art of moving bottlenecks around in your ecosystem until you've reached acceptable levels of resource consumption.

(These bottlenecks and resources may be compilation time, memory usage, response time, hardware, programmer time, run time, quality, complexity, maintainability, accuracy, and correctness.)

The reason experienced developers suggest optimizing for clarity, simplicity, and maintainability first is that almost no one considers clarity, simplicity, and maintainability valid targets for optimization, nor do we treat them as such. (Perhaps we would if we had mechanisms to measure them or metrics to measure their absence, but we don't.)

I don't believe in version numbers, at least to tell you anything other than one release is more recent than another. A significant segment of programmers which disagrees: some people really won't believe that Perl 6 actually exists until someone slaps the mythical 1.0 (or 6.0?) tag on Rakudo.

(Usually I put on my philosopher hat and suggest that, as far as ontological arguments go, existence of a thing usually precedes the need to argue whether that thing looks there in your living room, but programmers have a weird deontological attachment to labels, where it's okay for a beta not to work because it's a beta. Kant's Software Development Process within the Limits of Reason Alone is a long discredited hoax created by bored CMU students in the early '80s.)

"1.0 means stable", I hear. 1.0 means "usable" or "mature" or "complete". Legions of enslaved programmers await that glorious day when we pry open the hatch of their galleys and smite their chains and allow them to use software every commit of which has been public for years. Apparently slapping a version number greater than 1 on something summons angels.

With no small irony do I admit to helping perpetuate the practice of releasing software which does not, in one sense or another, actually exist in a usable form. You've used it too. I use it every day. It gets millions of uses, and (or so you might believe), the entirety of Western Civilization and some of the East too might crumble if Serious Businesses realized that it's not really usable.

This is the most useful piece of software I've ever written. It's even part of the Perl 5 core (and it's been there for years, darn their reckless endangerment of Serious Corporations everywhere)! It's Test::Builder, currently at version 0.96.

If you sneeze at it funny or scrape your chair or if you passed by someone on the subway who owns a ferret or something, it might break and delete your data and set your server room on fire and certainly you can't rely on it, because who knows what evil lurks in the spaces caused by that missing 0.04!

It gets worse; T::B has infected the CPAN as well. We'll have to excise it from every corner of every test module and every build or configuration dependency. You just can't trust its beady eyes. What nine year old can you trust?

I know, I know. You think you can make it work for your platform. You've run its tests and you've skimmed its code and you've looked at its bug queue and you've read its documentation, and you truly believe that—in this one case—you can get by with using software which doesn't exist in a useful, usable form because you're a grown up software developer and you know how to evaluate things for your own purposes. Besides, even RHEL includes it as a package, and you know they're still waiting to see if this desktop computing thing will ever take off. (Sure, maintaining backward compatibility with Hollerith cards is a pain, but have you seen the size of those support contracts?)

You might try that, but you'd be wrong. After all, who are you to decide what might work for your specific environment? You're merely a professional with training and experience and local information on your business requirements and coding standards and your own common sense and good judgment.

Who would ever believe you over a monotonically increasing real number?

The solution is clear. If we want to solve the software crisis, we should reclaim from our hard drives the imaginary software sucking up otherwise valuable inodes. The bad news is that we'll have to delete perl5i (but the good news is that we'll finally be rid of that pernicious iPad).

Fellow Parrot committer Andrew Whitworth raised the question how Parrot can become a mature platform for language development. His argument is that a focus on threading and a focus on JIT is necessary for enterprises or language communities to consider Parrot a useful platform.

I can see his point, and yet (as usual) I challenge the terms of the debate itself.

Edit: Andrew has responded at Woe is Parrot. I appreciate the nuance in a discussion of success criteria.

Is Perl 5 not a "mature" platform because it favors a shared-nothing (by default) threading model? Is Python 3 not a "mature" platform because it has a global interpreter lock? Was Java an immature platform until you could rely on its memory model and the presence of native—not green—threads on every platform on which you depended? (I used Blackdown Java for quite a while on GNU/Linux.)

Is Perl 5 not a "mature" platform because it lacks a JIT? Python 3000? Ruby? PHP? C++? Does linking against LLVM automatically turn an "immature" platform "mature"? Does Zend's opcode cache promote PHP from a toy language into a Language For Serious Internet-Scale Business? (Does it whiten your teeth? Does it freshen your breath? Does it provide a flea barrier to your pets while making you irresistable to members of the appropriate gender?)

That's one way to define "mature".

I prefer defining "mature" by answering the questions "Does the software do what its developers claim it does?" and "Can you rely on the developers to make and meet their commitments?"

I don't understand the argument that a tool must support a particular use case for some people to consider it "mature"; is Perl less "mature" than Java because LAMP applications tend to prefer a shared-nothing architecture with a distributable (and optional) cache over a single beefy box with a shared-everything memory cache.

Likewise, is Perl 5 anything less than capable because of the existence of PDL or Python because of NumPy?

(Did Gmail only become a serious application after the invention of TraceMonkey? Does the fact that I wouldn't use Visual Basic and Access or Foxpro to write a small business application mean that you can't write an effective small business application in either? Does the standard Unix pre-forking network server pattern doom all implementations to history's "Here's a nickel kid, come back when you're ready to play with real software!" dustbin?)

Instead of "mature", perhaps it's more useful to discuss the project's current strengths, its desired strengths, and its roadmap to support new uses effectively. Otherwise I foresee endless debates over who has the more enterprisey needs, and I can think of very few duller, less meaningful arguments.

You may have heard about the recent release of source code of a project called Diaspora. After raising $200,000, the developers spent three and a half months writing 6,500 lines of code. As the developers themselves wrote, We know there are security holes and bugs....

Many people will write many things about Diaspora, but none of them are particularly interesting to me. Instead, the discussion of the Slashdot story Security Concerns Paramount After Early Reviews of Diaspora Code fascinated me—especially the repeated assertion that "this is pre-alpha code".

I don't know what that means, and yet it appears to be conventional wisdom.

Does the software not work? (Apparently not well, if it's full of bugs and security holes.) If not, why release it at all?

Is the software not finished? (What does finished mean, anyway? Abandoned? Superseded by another project? Bug-free? None of these seem to apply.)

Does the project not do everything its stakeholders want it to do? (See also "finished".)

Is the project difficult to install? (If so, why not say that directly?)

Does the project need optimization? (If so, why not say so?)

Does the project not pass its tests? (If so, why release? Does it even have tests?)

Each of these questions reveals one of two underlying assumptions:

• We don't expect the software to work at all.
• We don't expect the software to do everything we want it to do yet.

In the first case, there's little value in making a public release. It's purely a publicity mechanism: here's what $200,000 bought you. We really did write code this summer, we promise. That's all well and good, but that's not very interesting to me, as software that doesn't work at all might as well not exist. (I haven't looked at the Diaspora code, so I have no opinion on its efficacy or quality. That's not the point at all.)

I understand the second case only as a truism. If the world of software development had any serious history of releasing projects which, on their first public release, did everything most users wanted and never had subsequent releases, I might be able to muster up some surprise that not every feature everyone could possibly want is present in this first public release. (Again, I have neither opinion nor comment on how well Diaspora's code meets public expectations.)

In short, "it's pre-alpha code" is a deeply silly comment, as if the speaker were sagaciously stroking a long, flowing beard while imparting the wisdom that there may be more releases in the future which add new and improve existing features.

Such is the way of software development (especially FLOSS development), which shouldn't be much of a surprise to anyone by now.

I keep returning to this theme because "it's pre-alpha software!" is a lazy refrain to often used as an excuse for bad behavior on the part of users as well as developers. Developers too often use it to justify working on lots of features, completing few of them, and throwing a greasy wad of code over the wall which may or may not be useful. Users too often use it to console themselves that buggy, incomplete, late, and half-polished software is worth using anyway or (my pet peeve) that software that doesn't do everything it will eventually do is probably not worth using now, even if it is.

In other words, because many developers can't ship working software reliably, those developers who can probably don't, and we'll argue with them up and down instead of actually testing their assertions. Software is difficult. Let's all eat pie.

I'm not sure there's a solution besides regular releases and a sane scheduling of features. Your project doesn't have to do everything everyone's ever dreamed it might someday do right now, but the features you ship this month really ought to be usable. Forget all of these cutesey linguistic games with the Greek alphabet (adding prefixes because you've run out of letters before α?). Be a grownup. Document what works and let us decide for ourselves if it's worth using.

(Note: version numbers of less than 1.0 are a different rant, one about change management. I'm thinking of you, CPAN authors.)

What's more readable, ten lines of Python or ten lines of Perl?

What runs faster, ten lines of Haskell or ten lines of Perl?

What's more scalable, ten lines of Java or ten lines of Perl?

What's more maintainable, this program or that program?

Did you account for the relative experience of the programmer or programmers? How about special domain knowledge? The presence or absence of specific libraries? Documentation? Deployability?

Which program is more correct? Did you measure? Do you have a definition of sufficient correctness? Should the program account for errors which are unlikely to happen? Do you have space or time constraints?

How long did the program take to write? How long did it take to debug? Did you test it? How did you test it? Who has to maintain it? What kinds of maintenance is necessary?

Are there idioms you have to translate between languages? What are the possibilities that you'll get the translation wrong? What are the nuances of one implementation you've overlooked in translation?

How long does the program have to last?

Even if you've measured and analyzed and satisfied your understanding of every important constraint I've mentioned (as well as those important constraints I haven't mentioned), do the specific details of your project generalize over other projects?

Put more pithily:

• We are not all Google, Yahoo, Facebook, Twitter, Amazon, eBay, or Craigslist.
• We are not all Paul Graham.
• Sometimes I don't care about error checking for a one-off job that will take minutes to write, seconds to run, and save me eight hours of manual work.
• Sometimes I have to deploy code to systems where I can't upgrade existing software (and sometimes I have to install my own dependencies).
• Sometimes the most important part of a project is to enable a team of developers to make the right change quickly rather than writing a bare-bones blog in 15 minutes.
• Sometimes understanding the problem is a lot more important than the specifics of the implementation language.
• Sometimes optimizing a program is more about not writing code than writing the fastest possible code in the fasted possible language.
• Most of the code I write looks nothing like the code in the Great Computer Language Shootout for many important reasons.

• Most of the people I work with are intelligent, capable, experienced people willing and able to learn new things.
• I wouldn't hire anyone to maintain code who hasn't demonstrate some ability to learn the problem domain as well as the language or languages in question and the relevant libraries.

Please try to keep these messy details of the real world in mind the next time you debate programming languages on the Internet.

Chris Yocum recently argued that Perl (5) can be difficult for lazy and undisciplined programmers. I agree; when the default of a language or ecosystem are difficult, laziness wins.

Isn't that an axiom of Perl? Laziness wins, so let the compiler and runtime and libraries do the work so that lazy people will still get their jobs done well?

The question is "What do you encourage?" Which design decisions does your language allow people to make with the least friction? (Leave out the people who distrust arrays and so they use the filesystem to process aggregate data structures, line by line—I've seen this, but not in Perl. These people need more help than language design; this is active malice and hostility toward programming and programmers.)

I come back to the example of Moose because it's a great example. Moose doesn't explicitly say the right way to handle instance variables is through accessors, even though that's probably the best way to handle instance variables. Moose also doesn't explicitly say that the best way to initialize instance variables is through named parameters passed to a constructor, even though that's a great approach. Instead, Moose makes those seem natural and easy such that you must be actively malicious (or be very curious, or have very specific, special needs in your project) to stumble upon a different approach.

Moose doesn't explicitly teach encapsulation is good! I'm not sure how well you can teach that, until the student has experienced the problem of poor encapsulation. Even so, you can teach the student good habits and you can hope that osmosis will drill in the point that encapsulation of instance variables leads to fewer problems.

Compare that to the Perl 5 documentation about how you can bless any type of reference, how you can manipulate data structures, and—oh, look over there at that blessed typeglob in core libraries!

The old Perl 5 way of doing something special when you need something different than default is to cram something else in a C-shaped box to fit the C-shaped prejudice of the core Perl 5 VM. After all, experienced C programmers know that an object is just a struct with an extra pointer hanging off it for method dispatch. (Larry has since resolved not to borrow features from Python wholesale.)

(Incidentally, this is why many novice programmers who've just learned Ruby think that Ruby is more flexible than Perl: Perl 5's Perlish API for metaprogramming is horribly ugly because of early and foolish consistencies. Even so, Perl 5 lets you manipulate more things than Ruby does because while ugly is skin deep, its manipulexity is chromosonal.)

The Moose approach is simpler: there's an official metaobject protocol with a very Perlish interface and no distinction between the Perl side and the C side. (You can't teach consistency either, but you can certainly demonstrate its presence and its absence.)

The lesson from all of this is simple: if you want to help the lazy programmers in the middle of the spectrum, make their lives easier by making the right thing so easy to do that their laziness will prevent them from doing the wrong things.

Perl 5.8.8 was released on 31 January 2006. There have been six stable releases of Perl 5 since then, including Perl 5.8.9 on December 14 2008. Yet if you install an Enterprise Linux Distribution such as RHEL 5.5 or CentOS 5.5, the base system Perl will be an ancient version of Perl 5.

Warning, some tongue-in-cheek rhetoric ahead.

I realize that Red Hat makes its money from businesses who believe computers are scary black boxes that fall over when you think "Maybe I'll say 'Boo!' at them!" and so it's very much worth Red Hat's time to charge lots of support dollars to release untouched versions of software for businesses which never upgrade their software not to upgrade to, but I'll eat my hat if that leads to any of those support dollars making Perl 5.8.8 more robust, more secure, less buggy, faster, or better to use.

(The previous paragraph is not entirely serious. I'm not wearing a hat, for example.)

Of course, Red Hat (like all good hearted operating systems) uses Perl 5 as part of the core system because it's so useful to get things done. Making any change at all to the core Perl 5 would mean that Red Hat or Fedora volunteers would have to figure out some way of verifying that changes are okay, and if not, they'd have to file bug reports and get them resolved somehow. That's a lot of work!

Red Hat (and other distributions) can distribute the versions of software they want. If they're happy with an ancient Perl 5, let them write their software. They make their choices and they pay the penalties.

Spoiler alert: the remainder is completely serious.

I can't, however, in good conscience recommend that anyone writing a new Perl 5 project in late 2010 use the system Perl 5 for anything other than installing App::perlbrew and then immediately installing a modern release of Perl 5, such as the shiny new Perl 5.12.2. It won't hurt, and you'll have access to wonderful features and improvements and—most important—you'll get support from the Perl 5 community which makes great things for you to use.

It's great that Perl has been a useful Unix tool for such a long time, and it's very good that distributions use it for their core utilities. Yet we shouldn't let their inability to manage software in conjunction with upstream get in the way of users trying to do useful things.

The ancient core Perl 5s installed by default by so-called Enterprise distributions are dead to me. They're the Internet Explorer 5 of the programming world: sufficient only to upgrade to something better. (Wouldn't it be a finer world if they could install their creaky old core Perl 5 in a core do-not-use-this directory of its own and give users something better by default?)

I use perldoc all the time (the command-line version). I don't know how to be a productive Perl programmer without perldoc -f or perldoc Module::Name. Nor would I try.

One of Perl 5's selling points is that includes copious documentation of the core language and common tasks. If you've skim perldoc perltoc once in a while, you'll find documentation you really ought to read as well as documentation you will wish you had read previously.

Then you'll come across something like perlobj which, bless its little heart, really isn't that helpful anymore. It gives far too many implementation details along with helpful-sounding but ultimately unpleasant advice. (Explaining how to use indirect method invocation before warning not to use it in the final paragraph of the section? A lengthy discussion of garbage collection? A comaprison of Perl 5's default OO with C++? Code examples which show how to bypass method dispatch altogether as a didactic technique on how method dispatch works?)

That's not the worst file in the documentation.

Writing documentation is difficult. Writing good documentation is very difficult. Editing existing documentation is thankless and fragile and prone to arguments: someone invested hours in writing that documentation a decade ago. We should celebrate that work and offer our most sincere gratitude to everyone who's helped create the voluminous Perl documentation. Even so, when documentation has grown a layer of mold (or when our understanding of the best way to do things has changed), we need to do users the favor of giving them the best advice we have.

Sadly, we'll never see Programming Perl 4E, but we can work to improve the core documentation in terms of advice, accuracy, organization, and completeness. (Even a prominent link to the TPF Perl 5 wiki for "Object Best Practices" in the documentation could keep it relevant in seven years when so-called enterprise distributions begin to ship a Modern Perl, but that's a far different need.)

If you're in the Portland, Oregon area, come to the Portland Perl Mongers September 2010 Meeting on Wednesday, September 8.

Not only will Schwern talk about Test::Builder 2 (Test::Builder is the foundation of the Perl Testing Revolution), but I'll talk about what novices must understand about Perl 5 before they can become adepts.

We're experimenting this month with a combination of novice-friendly primers and deeper subjects. We'd love to attract more people interested in Perl but not necessarily experts as well as people who've never written much Perl at all. Tell your friends.

... and for a preview of my talk, I'll explain:

• The two types of context in Perl 5
• What context really means, and why you already understand it
• What implicit variables really mean and why you already understand them
• What concision means and why it's not as scary as you think
• How to chunk Perl expressions into parts you already understand
• How to navigate the Perl 5 documentation

If you can't make the meeting, I'm sure a podcast will eventually appear. You could also read the draft of Modern Perl chapter 1 for an overview.

Perl is in better shape now than ever, but there's much left to improve. (I wrote Five Features Perl 5 Needs Now almost two years ago, and four of five are available in whole or in sufficient substitute, so that's great progress.)

Rather than criticize Perl for what's going wrong (as if I were any position to do so), I prefer to suggest new areas of improvement.

One of the biggest possible improvements to the world of Perl 5 is a replacement for many cases of XS. Ryan Jdoubi's Ctypes for Perl was on my original list, and it's still on my list.

Why is this important?

XS can be inscrutable. Try reading the documentation, spread out between perlxstut and perlapi, with liberal use of the Cozens and Jenness book Extending and Embedding Perl and, ultimately, trawling through—even copying and pasting—chunks of the Perl 5 core which seems to do what you want.

Now debug typemap problems, problems with contexts in threaded versus unthreaded builds, and the vagaries of Makefile syntax across various platforms, not to mention the joy of detecting whether you have the right version of a shared library and its development headers on a version of an operating system you've never seen, let alone used, and (oh yes) Windows.

It's no wonder people want pure-Perl modules when possible.

It's also no wonder that, with all of the copying and pasting and reading of the Perl 5 source code in lieu of a working, understandable example of real-life XS code we can modify to our own purposes, far too many CPAN modules and an unkonwn and scary amount of DarkPAN modules abuse the Perl 5 internals in such a way that upgrading to a newer version of Perl seems like soul-swallowing black magic.

You try refactoring the internals sometime, then watch the black smoke come in from the next monthly bleadperl release and sob softly as you put back all of the mess and hope for the best.

If Perl 5's internals have much hope of refactoring and cleanup and sanity, the less XS code the better. Ctypes for Perl can help by reducing the need for XS. If most of the XS modules which are XS only because there was previously no other obviously better way to pass data between Perl and shared libraries, migrating them to Ctypes can remove the need for XS. Improving the interface between Perl and C is much easier because only Ctypes needs to change.

We won't entirely get rid of XS, but we can minimize its use to those projects which really, really need it The fewer of those, the easier they are to audit and review and port, if necessary.

The cleaner the internals of Perl 5 (and the better its extension interfaces in sanity, cleanliness, safety, composability, and documentation), the more possibilities for further development and improvements.

(I also expect that modules which use Ctypes instead of XS will be smaller, faster, easier to write, less memory hungry, and easier to install and to redistribute.)

Eighteen months after I started this site, the Modern Perl book is almost out, as is Using Perl 6. Perl 5.10.1, Perl 5.12.0, Perl 5.12.1, and (very nearly) Perl 5.12.2 are out, with Perl 5.14 coming next spring (not month, as I mistakenly typed). Spring means, of course, April or May 2011. (Sorry, southern hemisphere; you should elect a volunteer release manager.)

Rakudo Star has had two impressive releases, which brings Perl 6 to ever more people. The Parrot VM had its 1.0 and 2.0 and 2.3 and 2.6 releases, and if you want an order of magnitude performance improvement in Rakudo Perl 6, the Parrot 3.0 series will deliver some impressive gains through the Lorito reorganization.

I've spent a lot of time critiquing the Perl language and community and even more time critiquing perceptions of Perl from within and without. I'm glad to review what's going right. It's easy to make a list of great new features of Perl and the community, but I can limit it to my favorites, in terms of immediate and longer-term significance.

By no means are these the only important developments in Perl in the past 18 months; please by all means let us all know what you find most important in your own journals and talks and presentations.

• The revitalization of Perl 5 core development has amazed me. Regular monthly releases have become boring, as they should be. A rotating series of release managers helps avoid the burnout that's claimed every Perl 5 pumpking up to this point, and it helps to make the process of releasing a new stable version of Perl 5 easier. That's why you can have confidence upgrading to Perl 5.12.2 when it comes out, and why in a year Perl 5.10.1 will look old.
• I've wanted Plack for Perl for ages; I've long thought Python's WSGI is a good example of the "There should be one obvious way to do it philosophy" (it works much better for interfaces to well-defined problem domains than language features). The rapid adoption of Plack for so many web frameworks and libraries within Perl—as well as the number of backends supported by Plack—has solved many of the deployment problems of Perl web applications. It also allows greater collaboration on middleware, such as debugging and profiling tools.
• Ancillary tools such as perlbrew and cpanminus have demonstrated that very simple interfaces devoted to solving the most common problems can improve the user experience immensely. I've known how to maintain my own user- and app-specific Perl 5 installations for years, but I've never wanted to maintain the morass of symlinks necessary to do so. Now I don't have to. Similarly, cpanminus lets me install CPAN modules often in the time it takes the official CPAN client to download the indexes.
• Regular releases of the first Perl 6 distribution (Rakudo Star) demonstrate the power and consistency and disruptive potential of Perl 6 to even more people. Every month brings new features and improvements. Every bug report and new module written and benchmark help the development community make it an even better platform for new projects.
• Schwern made the CPAN forkable through gitPAN, and the world is better for it. Public distributed version control for Perl 5 improves the experience of submitting changes, and public distributed version control for CPAN distributions has helped me submit and publish more changes too. Noticing a typo in documentation on search.cpan.org has become almost an enjoyable experience, if I can find the appropriate repository on Github, fork it, make my changes, and submit a pull request within five minutes. Often I can.

I look forward to several other projects in the world of Perl, such as Ryan Jendoubi's Ctypes for Perl 5 and the ongoing attempts in the Perl 5 core to rein in a sane set of functions for extensions to use. I've heard that various help forums have become more helpful and less abusive (especially #perl on irc.perl.org). I've even noticed a shift in how community members talk about marketing, especially as the discussion has changed from "Marketing? That's for those sick Java fans!" to "Hey, look at all of the cool stuff we're doing with Perl!"

We can and should still make improvements, but if the past year and a half is any guide, we can safely shift our cautious optimism for the present and future of Perl to regular optimism.