Perl 6 -- Too Bloated to Survive? (Core Devs Discuss) • Hacker News Board

Re: Perl 6 -- Too Bloated to Survive? (Core Devs Discuss)

#11

Post by dasil003 » Sat, Jul 31, 2010, 4:17 PM UTC

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.

Re: Perl 6 -- Too Bloated to Survive? (Core Devs Discuss)

#12

Post by draegtun » Sat, Jul 31, 2010, 4:23 PM UTC

dasil003 wrote: post #11

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 r…

Yes I don't know if the OP is being deliberately unaware just to cause a fuss but he/she doesn't seem to understand the difference between Parrot (VM), Rakudo (Perl6 implementation on Parrot) & Perl6 (the spec).

Re: Perl 6 -- Too Bloated to Survive? (Core Devs Discuss)

#13

Post by dasil003 » Sat, Jul 31, 2010, 4:31 PM UTC

alanstorm wrote: post #9

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…

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.

Re: Perl 6 -- Too Bloated to Survive? (Core Devs Discuss)

#14

Post by adamtj » Sat, Jul 31, 2010, 4:34 PM UTC

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

Re: Perl 6 -- Too Bloated to Survive? (Core Devs Discuss)

#15

Post by Dunbar » Sat, Jul 31, 2010, 5:25 PM UTC

dasil003 wrote: post #11

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 r…

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.

Re: Perl 6 -- Too Bloated to Survive? (Core Devs Discuss)

#16

Post by stcredzero » Sat, Jul 31, 2010, 5:27 PM UTC

mahmud wrote: post #10

stcredzero wrote: post #6

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.

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

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

Re: Perl 6 -- Too Bloated to Survive? (Core Devs Discuss)

#17

Post by chromatic » Sat, Jul 31, 2010, 6:41 PM UTC

dasil003 wrote: post #13

alanstorm wrote: post #9

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…

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.

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.

Re: Perl 6 -- Too Bloated to Survive? (Core Devs Discuss)

#18

Post by jpr » Sat, Jul 31, 2010, 8:33 PM UTC

stcredzero wrote: post #6

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.

Sounds pretty much like Go, which I personally don't find all that fascinating, in the same sense that I don't find C fascinating.

I really wish that in the near-ish future some group of people, be it a company, research group or just a bunch of hackers would create something that would cross-breed the best ideas of say Lisp, Haskell and Python in a coherent way to create something really fascinating.