Fwd: FOSDEM - perl 6 critic
Gabor Szabo
At FOSDEM I met Arne Wichmann who is a long time sysadmin,
Debian developer and Perl user. We had a short chat in which
he expressed his concerns about the complexity,
the size (memory footprint) and speed of Perl 6,
Without even taking in account the current memory requirements
and speed of Rakudo, I guess, even after lots of improvements
we can expect Rakudo to be significantly slower than Perl 5.10
- at least for start-up time - and significantly more memory hungry.
I know it will do a lot more so the comparison is not fair but that's
not the point.
( For a better comparison that takes in account the features as well see
http://www.modernperlbooks.com/mt/2010/07/an-accurate-comparison-of-perl-5-and-rakudo-star.html
)
He, as a sysadmin would like to do the small tasks in a relatively
small language. He would like to make sure the modules/applications
he will download and will have to support are in such a relatively small
language.
I wrote him my opinion but I think it would be important to address these
issues. (Of course if there already is a page somewhere answer these
concerns I'd be happy to just get a link)
Here is his e-mail. (forwarded with permission).
regards
Gabor
---------- Forwarded message ----------
From: Arne Wichmann <a...@anhrefn.saar.de>
Date: Mon, Feb 21, 2011 at 4:00 PM
Subject: FOSDEM - perl 6 critic
To: ga...@perl-ecosystem.org
Hi...
You gave me your card when we were leaving FOSDEM, it took me some time to
write a mail...
The topic was: why I am very sceptic about perl6...
First, my background: I am a perl hacker since '91 (or so), but mainly I am
a sysadmin. That means, I do not write a lot of code, but I do a lot of
debugging of other peoples code.
From that background, what I have seen in perl6 does not look like a good
idea to me: it is too complex. When I read other peoples code I have to be
able to understand whatever subset of the perl language they choose to use
- which means I have to be able to grasp any concept used in the language.
And given the number and complexity of operators in perl 6 I do not feel
that this is really doable.
My other gripe is that perl5 nowadays already is too big - it takes too
much memory and time for small tasks. But that is only secondary.
cu
AW
--
[...] If you don't want to be restricted, don't agree to it. If you are
coerced, comply as much as you must to protect yourself, just don't support
it. Noone can free you but yourself. (crag, on Debian Planet)
Arne Wichmann (a...@linux.de)
Guy Hulbert
> For a better comparison that takes in account the features as well see
> http://www.modernperlbooks.com/mt/2010/07/an-accurate-comparison-of-perl-5-and-rakudo-star.html
Thanks for posting this.
Can I infer from this article that it is *rakudo*, which is slow, rather
than parrot? I have the impression that I can compile perl6 down to
parrot code and run that separately. If so, it will be interesting to
benchmark both cases.
--
--gh
Will Coleda
Parrot's speed & memory footprint can certainly be improved - it's not
all Rakudo.
--
Will "Coke" Coleda
Moritz Lenz
> On Tue, 2011-22-02 at 17:57 +0200, Gabor Szabo wrote:
>> For a better comparison that takes in account the features as well see
>> http://www.modernperlbooks.com/mt/2010/07/an-accurate-comparison-of-perl-5-and-rakudo-star.html
>
> Thanks for posting this.
>
> Can I infer from this article that it is *rakudo*, which is slow, rather
> than parrot?
There are three different sources for slowness:
1) parrot itself. For example the calling conventions seem to be a major
bottleneck, now that the garbage collector has be sped up significantly
2) rakudo itself. For example the lazy list iteration code could
certainly use some optimizations
3) For some features there's a mismatch between what parrot provides and
what rakudo/Perl 6 needs, which makes rakudo go longer ways, which in
turn implies slowness. A large example of this is that rakudo can't
serialize all built-in types, but rather has to re-generate them at
startup time - which of course is a costly affair.
Cheers,
Moritz
Gabor Szabo
> On Tue, 2011-22-02 at 17:57 +0200, Gabor Szabo wrote:
>> For a better comparison that takes in account the features as well see
>> http://www.modernperlbooks.com/mt/2010/07/an-accurate-comparison-of-perl-5-and-rakudo-star.html
Just to clarify a bit to avoid misunderstandings.
I am not criticizing the speed or memory footprint of Rakudo.
I trust (blindly but still :-) the developers that they will achieve
their goals.
What I am concerned is that people who only get very limited information
about Perl 6 will get (further) be turned off from Perl and Perl 6 due to
whatever reason.
The funny thing is that now that I actually followed the link I provided I can
see I made a similar comment there.
Gabor
Guy Hulbert
Ok. So we'll want to implement algorithms in both perl6 and parrot
assembler then.
--
--gh
Guy Hulbert
> Am 22.02.2011 17:14, schrieb Guy Hulbert:
> > On Tue, 2011-22-02 at 17:57 +0200, Gabor Szabo wrote:
> >> For a better comparison that takes in account the features as well see
> >> http://www.modernperlbooks.com/mt/2010/07/an-accurate-comparison-of-perl-5-and-rakudo-star.html
> >
> > Thanks for posting this.
> >
> > Can I infer from this article that it is *rakudo*, which is slow, rather
> > than parrot?
>
> There are three different sources for slowness:
Thanks for the clarification.
> 1) parrot itself. For example the calling conventions seem to be a major
> bottleneck, now that the garbage collector has be sped up significantly
> 2) rakudo itself. For example the lazy list iteration code could
> certainly use some optimizations
> 3) For some features there's a mismatch between what parrot provides and
> what rakudo/Perl 6 needs, which makes rakudo go longer ways, which in
> turn implies slowness. A large example of this is that rakudo can't
> serialize all built-in types, but rather has to re-generate them at
> startup time - which of course is a costly affair.
>
> Cheers,
> Moritz
--
--gh
Guy Hulbert
> Maybe we just need to lay off of the cute one liners and * operator abuse
> when we demo Perl 6. My guess is that those one liners are not nearly as
> impressive to most workaday coders as the type system, MMD, grammars,
> private data, and method keyword.
Ugh. Give me the one-liners ;-)
I am sympathetic with the rest of your opinions ... though I probably
don't agree with all of them. TIMTOWTDI drives me crazy but it seems to
work!!
--
--gh
Mason Kramer
operators is not remotely a measure of complexity. Neither is "size of the
interpreter at runtime". "Number of things that the language does for you
in a standardized way" is actually a measure of simplicity, not complexity.
That is to say that the extra size of the language & interpreter comes from
the complexity-reducing features that are built in to the language.
Complexity is about such things as seeing action happen in the expected
place, keeping concerns separating, reducing the code to the essential ideas
that are being expressed, self-documentation, and non-redundancy. Perl 6
does a better job of all that than Perl 5 does. Part of the way that Perl 6
accomplishes this complexity reduction is by generalizing and standardizing
the best practices that the software industry has developed since Perl 5 was
written, which means more things are included in the language itself.
Put another way: whether or not there's an operator that does what you need
in a standardized, optimized way, or you roll it together from primitives in
a function declaration that anyone maintaining the code will have to read
and understand on a case-by-case basis, the action that you take in the code
still needs to get done somehow. Perl 6 programs will be smaller, when
measured in LOC, than their Perl5 counterparts. As a maintainer, your
sysadmin should be happy about that.
Maybe we just need to lay off of the cute one liners and * operator abuse
when we demo Perl 6. My guess is that those one liners are not nearly as
impressive to most workaday coders as the type system, MMD, grammars,
private data, and method keyword. These at least are the main features of
Perl 6 from my point of view (even though I fully grant that Perl 6 is
different things to different people - he might be able to get excited about
the behavior of the MAIN type sig, for instance).
I'm not saying anything about performance because I think we're all on "wait
and see" mode right now. I don't think there are any theoretical obstacles
that make Perl 6 fundamentally slower than Perl 5, Python, or Ruby, (right
guys?) and there are actually provisions to let it be faster for certain
applications - particularly the type system.
Moritz Lenz
> He, as a sysadmin would like to do the small tasks in a relatively
> small language. He would like to make sure the modules/applications
> he will download and will have to support are in such a relatively small
> language.
Whatever Perl 6 will turn out to be, it won't be a small language.
If I have any influence, it will be a language that's pleasant to write
and to use (and it largely is already), but it's not small. (Neither is
Perl 5 a small language; Perl 6 is just another step larger).
We can't be everybody's darling, as much as we would love to.
I wouldn't be opposed to stripping down some parts of Perl 6 a bit, and
make them available by loading (core) modules, but that's not the Perl 6
we are working on, but rather a different beast.
Arne Wichmann wrote:
> My other gripe is that perl5 nowadays already is too big - it takes
> too much memory and time for small tasks. But that is only secondary.
Here's the waterbed again: if we push it down on the one side and make
it pleasant to use, other parts (resource usage) go up. That said, early
Java compilers and VMs also sucked in terms of resource usage. We'll
just have to see how well Perl 6 can be optimized, and if/when we can
muster the resources to do it.
Cheers,
Moritz
Frank S Fejes III
> We can't be everybody's darling, as much as we would love to.
That's a fair statement, however do consider that perl5 is still a
darling for many system administrators and command-line warriors who
have long since left awk and sed far behind and never looked back. In
this use case, perl5 still rules, and I would suspect that you
wouldn't want to simply throw away these users. My (admittedly
limited) experience with rakudo leads me to believe that the one-liner
or power-tool usage we've come to expect with perl5 may simply not
exist in perl6.
[frank@zino00 ~]$ echo "a b c" | perl -lane 'print $F[1]'
b
[frank@zino00 ~]$ echo "a b c" | perl6 -lane 'print $F[1]'
===SORRY!===
Unable to open filehandle from path '-lane'
[frank@zino00 ~]$ echo "a b c" | perl -pe 's/b/BEE/ if /^a/'
a BEE c
[frank@zino00 ~]$ echo "a b c" | perl6 -pe 's/b/BEE/ if /^a/'
===SORRY!===
Unable to open filehandle from path '-pe'
These are the kinds of things I do every single day many times per day
without a second thought. It would be a shame IMO if I couldn't
continue to use perl6 in such a fashion. Just my own 2 cents.
Thanks.
--frank
Gabor Szabo
> On Tue, Feb 22, 2011 at 10:46 AM, Moritz Lenz <mor...@faui2k3.org> wrote:
>
>> We can't be everybody's darling, as much as we would love to.
>
Let me just link to the recent blog post of chromatic:
http://www.modernperlbooks.com/mt/2011/02/unifying-the-two-worlds-of-perl-5.html
and point out the link Aristotle posted:
http://www.nntp.perl.org/group/perl.perl5.porters/2011/02/msg169141.html
He enumerates some of the groups of Perl users that have distinctive
usage patterns.
> [frank@zino00 ~]$ echo "a b c" | perl -lane 'print $F[1]'
> b
> [frank@zino00 ~]$ echo "a b c" | perl6 -lane 'print $F[1]'
> ===SORRY!===
> Unable to open filehandle from path '-lane'
> [frank@zino00 ~]$ echo "a b c" | perl -pe 's/b/BEE/ if /^a/'
> a BEE c
> [frank@zino00 ~]$ echo "a b c" | perl6 -pe 's/b/BEE/ if /^a/'
> ===SORRY!===
> Unable to open filehandle from path '-pe'
I am not an expert on Perl 6 but I think the fact that those things you
mentioned don't work on the command line of Rakudo is mainly as
they were not *yet* implemented.
They might not be fully specced yet either.
See the draft version of the specification: http://perlcabal.org/syn/S19.html
I am sure the Perl 6 developer would be happy if you could send
them patches implementing some of those option or if at least
you could write tests that check if the features work.
regards
Gabor
Moritz Lenz
> On Tue, Feb 22, 2011 at 10:46 AM, Moritz Lenz <mor...@faui2k3.org> wrote:
>
>> We can't be everybody's darling, as much as we would love to.
>
> That's a fair statement, however do consider that perl5 is still a
> darling for many system administrators and command-line warriors who
> have long since left awk and sed far behind and never looked back. In
> this use case, perl5 still rules, and I would suspect that you
> wouldn't want to simply throw away these users.
That's correct. But those users chose Perl because they get stuff done
with it, not because it's a small language (and it's not).
> My (admittedly
> limited) experience with rakudo leads me to believe that the one-liner
> or power-tool usage we've come to expect with perl5 may simply not
> exist in perl6.
As Gabor points out, they haven't been implement yet, but they will be.
Cheers,
Moritz
Carl Mäsak
>> My (admittedly
>> limited) experience with rakudo leads me to believe that the one-liner
>> or power-tool usage we've come to expect with perl5 may simply not
>> exist in perl6.
>
> As Gabor points out, they haven't been implement yet, but they will be.
Not always in exactly the same ways as Perl 5, of course. Perl 6 looks
quite different, even on the level of one-liners. Rest assured that
some of us are scouring the corners of Perl 5 for typical one-liners,
and trying to make sure that we have or will have a way to do similar
one-liners in Perl 6. The one-liners don't always end up as short as
in Perl 5, at least not after a literal translation. But they're often
in the same ballpark.
To me, it's an open question whether Perl 6 will be "competitive" as a
one-liner language next to Perl 5. The real surprise in brevity and
convenience comes when one lets go of the Perl 5 mindset and starts
using the list, hyper and reduction operators for processing files.
That's where Perl 6 shines, and Perl 5 has trouble keeping up.
// Carl
Xiao Yafeng
realize I made a mistake most of people made, to avoid knowing, learning new
things. ;)
as a sysadmin since 2000, I definitely need to handle many small tasks also,
a script for fetching files, a script for showing figure, a script for
checking capacity... but when these script keep piling up, you will end up
with a neat way, writing a better program or module to organize those all
stuff. In this term, perl6's grammar, and module management would make our
job more easy to be done than perl5.
sure, sometimes, you still need to handle trivial tasks. In this area, perl6
oneliner works as well as perl5 does.
again, in perl5, you have to often look up some speical variable in perldoc,
many werid expressions confused guys take over your job, and maybe spend
half an hour to explain why this built-in function has an comma but the
other hasn't to newbie.
the advantage of perl5 now is cpan, but because of weak module management,
how to control various modules in script become a big problem to make
headache.
Compared to this, perl6 is more neat, consistent and reasonable. only if
would you love to take one or two hours to read perl6 syntax and try with
rakudo, you would find it's not as complex as you imagine.
In my opinion, the problem of rakudo nowadays is bloody slow, flux grammar
and unproductive. hmm, as a sysadmin, I just hope perl6 could remain some
adminblood, like >>, > in open func etc.
I'm drooling for advent of true Xmas.
In addition, a stripable language is a great idea, I think. thinking of
embedding perl6 interpreter into linux kernel.....
Steffen Schwigon
> Am 22.02.2011 16:57, schrieb Gabor Szabo:
>> He, as a sysadmin would like to do the small tasks in a relatively
>> small language. He would like to make sure the modules/applications
>> he will download and will have to support are in such a relatively small
>> language.
>
> Whatever Perl 6 will turn out to be, it won't be a small language.
And just to complement the many answers:
There *are* small variants of Perl6: Perlito and NQP.
Kind regards,
Steffen
--
Steffen Schwigon <s...@renormalist.net>
Dresden Perl Mongers <http://dresden-pm.org/>