Update: I realize the title will likely be mis-interpreted as an indictment of Perl's speed. No, no. It is just a play on the NYT title... a meditation on the speed of its development.

Dear monks,

I was reading NYTimes.com "Windows Is So Slow, but Why?" (registration required, unfortunada). The following para triggered an analogous thought vis a vis Perl --

And a crucial reason Microsoft holds more than 90 percent of the PC operating system market is that the company strains to make sure software and hardware that ran on previous versions of Windows will also work on the new one — compatibility, in computing terms.

As a result, each new version of Windows carries the baggage of its past. As Windows has grown, the technical challenge has become increasingly daunting. Several thousand engineers have labored to build and test Windows Vista, a sprawling, complex software construction project with 50 million lines of code, or more than 40 percent larger than Windows XP.

"Windows is now so big and onerous because of the size of its code base, the size of its ecosystem and its insistence on compatibility with the legacy hardware and software, that it just slows everything down," observed David B. Yoffie, a professor at the Harvard Business School. "That's why a company like Apple has such an easier time of innovation."

Any new design of Perl has to ensure that legacy code doesn't break. The crown jewel of Perl (besides perlmonks.org, of course) is CPAN. However, if a new Perl decided to break from the past, it would break its ties with CPAN as well. A newer language such as Ruby doesn't have that baggage. There is really no way around this conundrum. Then, there is the accompanying conundrum -- if a new Perl broke away from its past so that it became a radically new language, what attraction would it have for me? Wouldn't I be just as well attracted to replace Perl with Ruby in my world?

So, the designers of the new Perl have an unenviable task -- make the language sufficiently new so it can ditch its substantive cruft, but is still compatible with the bales of crufty code out there AND ditch its formative cruft so it looks modern, yet is not so new that it is like learning a new language.

Almost seems like Apple had it a lot easier than the Perl community has. Suddenly I feel like empathizing with Microsoft and its Windows-woes.

Console me.

--

when small people start casting long shadows, it is time to go to bed

Replies are listed 'Best First'.
Re: Perl Is So Slow, but Why?
by xdg (Monsignor) on Mar 29, 2006 at 00:45 UTC

    Isn't this exactly the design goal for Perl 6? Here's Conway's quote from that page:

    "The Perl 6 design process is about keeping what works in Perl 5, fixing what doesn't, and adding what's missing. That means there will be a few fundamental changes to the language, a large number of extensions to existing features, and a handful of completely new ideas. These modifications, enhancements, and innovations will work together to make the future Perl even more insanely great -- without, we hope, making it even more greatly insane."

    Plus, it's here now with Pugs, so you can start getting excited right away.

    P.S. Apple OS on the new Intel platform has to run legacy code in a slow emulation layer. Why does the NYT think Apple has it so good?

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
Re: Perl Is So Slow, but Why?
by rhesa (Vicar) on Mar 28, 2006 at 23:26 UTC
    I'm sure there are substantial compatibility layers in perl, but I have the feeling those are mostly resolved during the compilation of your perl binary. At least, that's what I gather from the fact that XS modules built against, say, 5.6 aren't binary compatible with 5.8. I don't think perl has the runtime issues that Windows does. That's the big advantage of having source code: you can optimize the build for your platform.

    That doesn't detract from the complexity of the source code, of course, but it doesn't imply that perl is slow. IMHO.

[reply]
Re: Perl Is So Slow, but Why?
by Mutant (Priest) on Mar 29, 2006 at 09:37 UTC
    I don't think backwards compatibility necessarily means a bloated and unweildly system. And I don't think that's the reason why Windows is so big. Linux maintains compatibility for old hardware (in some cases, must older than Windows), and yet it doesn't suffer from the same issues.

    If you're talking about newer versions of Perl retaining hardware compatibility (I don't think you are) then this is a good analogy. Perl is like Linux in that it can be compiled to suit your achitecture.

    If you're talking about Perl having backwards compatibility at a language level, then I don't think this is a huge issue. There's no reason why we can't have Perl5 and Perl6 working side by side. In fact, I believe this is exactly what Parrot is for.

    Perl6 will gramatically be a completely different language, however I believe (and I don't know a lot about P6, so hopefully someone will correct me if I'm wrong) that most of CPAN will work with it (one of the main reasons for the Phalanx project).
[reply]
Re: Perl Is So Slow, but Why?
by wazoox (Prior) on Mar 29, 2006 at 10:20 UTC
    "Windows is now so big and onerous because of the size of its code base, the size of its ecosystem and its insistence on compatibility with the legacy hardware and software, that it just slows everything down," observed David B. Yoffie, a professor at the Harvard Business School. "That's why a company like Apple has such an easier time of innovation."

    Actually, until the advent of the new Intel Macs, most applications since 1984 still worked fine on the latest Apple machines. This may have something to do with "well conceived and thought out hardware and software architecture" versus the "quick and dirty stuff duct-taped together" that drove Microsoft developments for some years :) Fortunately, perl's kin is obviously not from the "quick and dirty" breed.

[reply]
Re: Perl Is So Slow, but Why?
by asz (Pilgrim) on Mar 29, 2006 at 07:10 UTC

    i'm not sure if i understand what i'm talking about (so please correct me if i'm wrong!), but... in Perl 6 you could change the grammar, so you can get (at least syntax-level) compatibility with older versions, like Perl 5 or even Perl 4.

    From What’s new in Perl 6 (The short form) by Dan Sugalski (the link points to a Microsoft Powerpoint file; there is also a HTML version in the Google cache):

    • Perl 6 grammar is really a perl 6 grammar
    • That means you can change it if you want
    • Don’t like . for deref? Change it

    so if i'm not dreaming, you could distribute your application with the grammar for the version of Perl that you've developed against, so you don't have to worry about on what perl version your code will run, because your application will load the correct language version from by you specified grammar file.

    i hope this makes some sense :)

    :)))))
[reply]
Re: Perl Is So Slow, but Why?
by jhourcle (Prior) on Mar 29, 2006 at 12:23 UTC
[reply]
Re: Perl Is So Slow, but Why?
by szbalint (Friar) on Mar 29, 2006 at 13:52 UTC
    As far as I know, thanks to Module::Compile, you'll be able to use Perl 5 modules with Perl 6, so essentially you can have half of the code in Perl 6 and some legacy code in Perl 5 in the coming years...

    Update: This is possible without Perl 6 carrying a lot of legacy cruft, so essentially you're getting the best from both worlds. Also, sixpan is on it's way and currently CPAN has a section for Perl 6 modules already.
[reply]

Back to Meditations