Steve Fink writes:
> I just don't know if I'd bother to switch to Perl6 for a 10% speedup
Speed will *not* be the only reason to switch to perl6. It will (might)
have:
- bytecode compilation
- compile-time checking
- a rational stdlib
- vastly simpler extension mechanism
You can focus on any of those and say that individually no one is
a compelling reason to change. But the complete package sounds pretty
bloody good.
And I've been getting hints from Larry that he's also got a couple of
seriously killer improvements up his sleeve (being the showman that he
is, I suspect he's looking forward to watching our jaws drop when he
finally does tell all).
However, it's definitely worth a brief review of features (after we
get the language design sorted out). Features come in several
different categories, said one of the many PM books on my desk. Some
are to keep up with the Joneses (cue nagging voice: "but PYTHON has
built-in multidimensional arrays"), some will be scratches to user
itches ("I want to foreach by pairs"), some will be new features that
are in the same mould as before ("reduce"), while some will be
features that change the way people and the system work (currying,
interfaces).
When we're working out which bits of the wishlist of features we can
realistically hope to accomplish, we can use these categories of
features to help us decide (as well as what we think we can do). We
will want some (but not many) keeping up with the Joneses features,
we'll want to scratch a good number of user itches (so users say "ooh,
yes, about bloody time I could do that"), but we'll want to include
a few of these radically new features too.
I think that when we don't know what features will be in the language,
it's probably too early to talk about "well, I won't be upgrading".
> > Once again, I'd tend to compile a set of ten problems that represent
> > common XS operations (wrapping a simple function with automatic type
> > conversion, defining custom types, mixing Perl-allocated data with
> > C-allocated data, all the way up to wrapping C++ objects as blessed
> > tied hashes).
>
> Oops. Did you suggest this somewhere and I missed it? This sounds great.
You didn't miss it, I was referring to my similar suggestion for the
benchmark of Perl code: get some things that reflect the typical
spread of tasks, and use that collection to measure improvement on.
In the case of XS, I'd want all the operations to be as simple or
simpler to create (i.e., automatic tools like the C::Scan enhancement
to h2xs) or write (i.e., shorter code because the metalanguage or API
are better).
Nat
