

Perl 6 -- Too Bloated to Survive? (Core Devs Discuss) - supporting
http://lwn.net/Articles/397968/

======
dasil003
I've never been a real Perl hacker, more of an admirer from afar. I mention
that because I'm pretty close to the ideal "objective observer" that chromatic
mentions.

dskoll certainly has valid concerns, but he turns into a real asshole as the
thread continues:

 _I believe the improvements in speed and memory required to make Perl 6
competitive with Perl 5 are unprecedented in the history of computer science._

This is a ridiculous statement, of course things have been optimized by 95%
before. Given the specific explanations given by the devs about the wholly
unoptimized state of the project along with planned optimizations, it seems
well within the realm of possibility.

I'm not sure what the chip on this guys shoulder is, but it sounds like he
just wants perl5. He gives no consideration for the innovation and creativity
behind perl6. If he doesn't give a shit about all the advanced features then
stick with perl5 for god's sake, it's well proven and it's not going
_anywhere_. But to argue ad nauseam about the impossibility of an "adequate"
optimization from a totally ignorant position is pretty offensive.

~~~
Dunbar
The one thing I've learned in the years I've worked with Perl is to never
underestimate the ability of the Perl community to achieve the incredible.

To compare the performance of the mature, optimized Perl 5 core to the freshly
baked, feature rich Perl 6 is shortsighted in the extreme.

The Perl 5 runtime is hard to extend, meaning that using the modern additions
to the language (notably Moose), comes with a significant start up penalty.
This can not be easily overcome.

Perl 6 has a Grammar, Perl 5 only has an implementation (only perl5 can parse
Perl5). There is a lot of opportunity for making Perl 6 nice and fast,
certainly fast enough for the larger complex applications it is designed to
support.

Perl 6 is not trying to compete with Perl 5 on one line throw away scripts.
Not yet anyway.

------
jameskilton
This is also thoroughly debunked in another article posted here an hour ago or
so:

[http://www.modernperlbooks.com/mt/2010/07/an-accurate-
compar...](http://www.modernperlbooks.com/mt/2010/07/an-accurate-comparison-
of-perl-5-and-rakudo-star.html)

Comes across to me like chicken-little syndrome.

~~~
draegtun
Here's the HN post referred to: <http://news.ycombinator.com/item?id=1563618>

------
adamtj
Rather, premature optimization is the root of _nearly_ all evil. Without it,
you apparently get trolled.

------
stcredzero
The time is ripe for the next "big" language + framework to come on the scene.
I predict it will be a compiled language with rapid compilation and advanced
debugging/runtime monkeypatching, such that most of the advantages of dynamic
languages will be subsumed. It will also support some advanced way to handle
concurrency.

~~~
mahmud
Why do you think "compiled" is the opposite of "dynamic"?

~~~
stcredzero
I don't, but much of the rest of the world does.

------
spooneybarger
the comments are the most interesting part of this. original poster makes lots
of assumptions, many of which are challenged by people who know the raduko
code.

~~~
draegtun
Yes the OP comments throughout contain a lot of historical inaccuracies about
Parrot & Rakudo.

The ParrotVM team did publish a precise roadmap a few years back and I believe
the optimization wasn't due to circa version 3 or 4? (ParrotVM is currently at
2.6).

NB. Unfortunately I can't find the original roadmap I'm referring to at moment
because it may not have made the Rakudo move from svn to git?

------
alanstorm
This reminds me of a lot of the "discussion" surrounding the Mozilla project
back in the pre 1.0 days.

Non Project Member makes a decent point about performance, but does so in an
incredibly presumptuous, entitled, non-helpful way.

Project Members make a lot noise and had waves about pre-production, non-
optimized versions, etc., but never come out and say "Yes, version n+1 of our
project will most likely use more ram and run slower on the same hardware as
version N of our project"

~~~
dasil003
chromatic says a factor of 2.0 is a worthwhile target
(<http://lwn.net/Articles/398051/>). I think that's the best you'll get since
good developers—especially perl6 developers—generally are copiously
optimistic.

~~~
chromatic
We haven't reached the point of dramatic optimizations yet. We're making some
architectural changes in Parrot (the Lorito project) to allow for tracing JIT,
bytecode optimizations, and slimmer deployment of dependency-traced
applications.

------
pinksoda
Bloated? No.

Needs some optimizations? Sure.

