Front page | perl.perl6.language |
Postings from January 2001
Re: JWZ on s/Java/Perl/
From: Jeanna FOx
January 29, 2001 09:58
Re: JWZ on s/Java/Perl/
Message ID: 3A75A645.CC31A485@vulpes.com
David Mitchell wrote:
> Jeanna FOx <Jeanna@vulpes.com> wrote:
> > Everybody seems to be missing the fact that jwz bitching about Java's
> > "32 bit non-object ints" means that at least he thinks they could be
> > salvaged. What would he think of Perl's "224 bit non-object ints"?!
> > Don't get smug because Perl can iterate over an array of anything. The
> > price we pay is incredibly expensive.
> Perl6's vtable implementation of scalars and arrays etc should
> allow lightwight arrays of integers (eg 32 bits) which still appear
> to the rest of Perl (and the programmer) to be arrays of full-blown SVs.
Doubtful. It looks like we're still going to have a relatively
heavy-weight SV (sometimes called a PMC for Perl Magic Cookie). This
is currently 3 words in Perl 5 and it ain't shrinking for Perl 6. So
while it's true that Perl 6 will get "lighter and faster", it doesn't
come close to what jwz thinks of as "light and fast". He's expecting 32
bits per int *total* (boxed values with 31 bit range and a 1 bit type
mark) and a byte/native code compiler that's able to work with the data
in native (unboxed) form when it's type safe to do that. And transparent
auto-promotion to bigints. And built-in ints implemented as real objects
that he can sub-class. And type-restrictions using typedef that can
sub-type without the cost of sub-classing.
Perhaps you meant that Perl 6 is going to have homogeneous arrays, in
which case an array of ints would keep 32 bits (per value) of int data in
the array and auto-generate the extra flags and stuff when a value is
extracted from the array. That's possible, but it's a special case of small
ints. You already know how jwz likes special cases.
It also looks like some features are impossible to turn off -- like the
mandatory locking that jwz hates about Java. It's not safe to turn it
off, but it's not really safe with it on either. Some people would rather
loose the illusion of safety to get better performance.
I'm not saying any of this is a mistake; I agree with most of the Perl 6
design direction. My only point is that we must maintain perspective and
not be all things to all people. IMHO it's impossible to change Perl to
the point where jwz would use it (or not hate using it... ;)