Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015 • Hacker News Board

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#131

Post by b2gills » Mon, Feb 02, 2015, 4:58 PM UTC

kbd wrote: post #104

perlgeek wrote: post #40

I'm a Perl 6 core developer (compiler, test suite, docs, design documents, infrastructure). Ask me anything :-)

Something I've wondered for a while: why was the decision made to write yet another dynamic language VM+JIT (MoarVM) instead of taking advantage of all the work the PyPy folks have done and using PyPy for Perl 6? Was PyPy even evaluated as a possible target?

Why would we want to write Python code to get a new Perl6 backend which doesn't have quite the same object system that Perl6 needs?

At any rate I think that an implementation of 6model (the basis for Perl6 objects) on PyPy would likely be too slow to really make it worth the effort. ( If you really want to try I'm sure there are People who would help you )

There are currently 3 backends for the Rakudo implementation of Perl6: Parrot, JVM, and Moar.

The fastest one currently is the one designed to meet the needs of Rakudo: MoarVM. (in many benchmarks) It of course makes sense that a VM designed for Perl6 would work better for Perl6.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#132

Post by kbd » Mon, Feb 02, 2015, 5:40 PM UTC

b2gills wrote: post #131

kbd wrote: post #104

Earlier quoted context omitted.

Something I've wondered for a while: why was the decision made to write yet another dynamic language VM+JIT (MoarVM) instead of taking advantage of all the work the PyPy folks have done and using PyPy for Perl 6? Was PyPy even evaluated as a possible target?

Why would we want to write Python code to get a new Perl6 backend which doesn't have quite the same object system that Perl6 needs? At any rate I think that an implementation of 6model (the basis for Perl6 objects) on PyPy would likely be too slow to really make it worth the effort. ( If you really want to try I'm sure there are People who would help you ) There are currently 3 backends for the Rakudo implementation…

I think you misunderstand how PyPy works, not to mention making baseless claims (it'll be too slow), which is why you've been downvoted.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#133

Post by kbenson » Mon, Feb 02, 2015, 5:50 PM UTC

chromatic wrote: post #129

kbenson wrote: post #121

Earlier quoted context omitted.

That's... an odd way to start a response in which you are very obviously being uncharitable yourself in assessing the motivations and actions of real people. What's more, you are doing it as a non sequitur. I'm really not sure what you're trying to say here. How is a later project being able to look at what came before and try to determine what decisions were good and bad of the prior project and trying to avoid them…

After the first Rakudo Star release, I personally volunteered to spend my Parrot time fixing bugs which affected Rakudo, improving the performance of Rakudo, and adding features for Rakudo, in that order. I offered several suggestions (including native registers, better profiling, object system improvements) and was repeatedly told not to work on them. I will say this, though: there was no friction to working on the…

Ah, we've had this discussion before. No need to rehash it here, I think I was clear before, and I don't see you changing your stance.

I still don't see what place it has in this thread. It's irrelevant to the fact that a project could learn from all of it's predecessor's successes and mistakes, while not carrying any of the historical baggage. You have a point you want to make, I get that, but if you feel to need to inject it into something at best tangentially related, at least lay the foundation so it makes sense when people read it.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#134

Post by chromatic » Mon, Feb 02, 2015, 6:24 PM UTC

kbenson wrote: post #133

chromatic wrote: post #129

Earlier quoted context omitted.

After the first Rakudo Star release, I personally volunteered to spend my Parrot time fixing bugs which affected Rakudo, improving the performance of Rakudo, and adding features for Rakudo, in that order. I offered several suggestions (including native registers, better profiling, object system improvements) and was repeatedly told not to work on them. I will say this, though: there was no friction to working on the…

Ah, we've had this discussion before. No need to rehash it here, I think I was clear before, and I don't see you changing your stance. I still don't see what place it has in this thread. It's irrelevant to the fact that a project could learn from all of it's predecessor's successes and mistakes, while not carrying any of the historical baggage. You have a point you want to make, I get that, but if you feel to need to…

I believe some of the "historical baggage" lumped on Parrot and, by extension, its developers came from deliberate design and project decisions of the Rakudo developers. I'm happy to lay out what I believe the Parrot team did wrong (and have done so in detail elsewhere), but I've long grown tired of the historical rewriting that goes on in the P6 world.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#135

Post by b2gills » Mon, Feb 02, 2015, 7:10 PM UTC

chromatic wrote: post #116

ugexe wrote: post #107

Earlier quoted context omitted.

This is not Perl 5. They are not the same language. Any whatever language you currently favor is Just Another Language that will be (or has been) displaced by [Current Fad Language]. Perl 6 hasn't even had its "Show HN: flappy bird/blog platform/etc" flavor-of-the-month phase yet, and you still claim its too late for the language? You come off as someone who does not want to expand their developer tools, because ther…

Perl 6 hasn't even had its "Show HN: flappy bird/blog platform/etc" flavor-of-the-month phase yet, and you still claim its too late for the language? After almost 15 years in development, surely that lack should indicate something.

I'm actually glad it took this long.

If it didn't it would probably be like all these other new languages which only attempt to improve upon the art of programming in one or two aspects.

Another good thing about it taking so long is that it took a few tries before anyone figured out a decent way to implement Perl6. If everybody had just settled for the first halfway decent implementation, we would have been bridled with a language that was half as good as it could be. And the worst thing about that is that there would be people relying on the features the way they were implemented then, making it far harder to break backwards compatibility and get here in as little time as it has so far taken. ( There is still at least one big breakage that will come before Perl6 is officially released )

That's ignoring a few stumbling blocks like illness and some mismatch between the goals of Parrot and Rakudo. Without which it could have been done possibly 5 years sooner.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#136

Post by SwellJoe » Mon, Feb 02, 2015, 7:27 PM UTC

latk wrote: post #127

SwellJoe wrote: post #71

Earlier quoted context omitted.

When did Python become faster than Perl 5? I'm not trying to be argumentative, but the last realistic comparisons I did had Perl running quite a bit faster. For example comparing ack to grin, which are very similar projects in Perl and Python respectively...at the time, admittedly several years ago, ack was an order of magnitude faster than grin. I also wrote a few log parsers in both Perl and Python (at a time when…

Perl5 has a lot of historical baggage that makes certain things difficult to do efficiently. For example, how objects work. There is an insane amount of indirection involved for a simple method call, and this indirection can't generally be removed if we want Perl5 to stay highly backwards-compatible. Numerics aren't particularly efficient either. Perl5's opcodes are very high-level. That makes each individual opcode…

I understand all that (though it's useful to cover it for folks who might not know). But, is Python faster? It carries some baggage of its own. I guess PyPy may be able to make some sorts of problems faster, and it was still nascent at the tail end of when I was using Python; I think it existed, but was nothing more than a proof of concept. Even now, I think it's a pretty limited subset of Python deployments that use PyPy.

And, you speak of numerics, which is a good example of Python's wheel house. When I worked in Python it was at Enthought (the company run by the folks who created Numeric, SciPy, and who sponsors a lot of scientific computing Python projects). Perl definitely doesn't have the numbers performance of a hybrid Python+Fortran or Python+C++ system, like you can build with Python, Numeric, SciPy, etc.

So, even back then, Python was (probably) faster than Perl in that category (Perl has science and bioinformatics libraries, which may have been comparable back then, but certainly aren't now), and I guess it's unfair to compare Perl's strength to Python's weakness, and vice versa.

Nonetheless, I suspect Perl is not slower than Python in the general case. One would probably have to talk about specific tasks and implementations to figure it out.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#137

Post by pwr22 » Mon, Feb 02, 2015, 9:31 PM UTC

chromatic wrote: post #134

kbenson wrote: post #133

Earlier quoted context omitted.

Ah, we've had this discussion before. No need to rehash it here, I think I was clear before, and I don't see you changing your stance. I still don't see what place it has in this thread. It's irrelevant to the fact that a project could learn from all of it's predecessor's successes and mistakes, while not carrying any of the historical baggage. You have a point you want to make, I get that, but if you feel to need to…

I believe some of the "historical baggage" lumped on Parrot and, by extension, its developers came from deliberate design and project decisions of the Rakudo developers. I'm happy to lay out what I believe the Parrot team did wrong (and have done so in detail elsewhere), but I've long grown tired of the historical rewriting that goes on in the P6 world.

Could you link to your elsewhere. I'm keen to learn more of the P6 history, good and bad

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#138

Post by pwr22 » Mon, Feb 02, 2015, 9:48 PM UTC

rurban wrote: post #19

mfrager wrote: post #11

I hope Perl 6 has better runtime speed and memory efficiency because those are the only downsides of Perl 5. However I seriously doubt that will be the case. Perl 6 will most likely be more bloated and slow, but I very much hope that I'm wrong. Just for reference my company's software is all built with Perl 5 and runs great. Most of the execution time is within the database calls so there is no impact from using Perl…

With perl5 + Moose, perl6 beats perl5. In startup time and run time. With simple small scripts the small startup footprint of perl5 still elevates it over perl6. perl6 has much more features than perl5, it's a completely different world. I wouldn't call that bloat.

Wonder how Moo compares?

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#139

Post by chromatic » Mon, Feb 02, 2015, 10:40 PM UTC

pwr22 wrote: post #137

chromatic wrote: post #134

Earlier quoted context omitted.

I believe some of the "historical baggage" lumped on Parrot and, by extension, its developers came from deliberate design and project decisions of the Rakudo developers. I'm happy to lay out what I believe the Parrot team did wrong (and have done so in detail elsewhere), but I've long grown tired of the historical rewriting that goes on in the P6 world.

Could you link to your elsewhere. I'm keen to learn more of the P6 history, good and bad

I wrote my experiences with Parrot in specific:

http://www.modernperlbooks.com/mt/2013/02/goodnight-parrot.h...

I did not write but agree with this view of the Parrot Foundation:

http://whiteknight.github.io/2015/01/14/parrotfoundation.htm...

Similarly, this retrospective from another ex-Parrot developer has similar feelings about the P6 language:

http://whiteknight.github.io/2015/01/14/parrotfoundation.htm...

I personally wrote several parts of "Theme, Pragmatics, and Purpose in Programming Language Implementation":

http://outspeaking.com/words-of-technology/theme-pragmatics-...

... and I had several discussions which led to the writing of "Why Perl Didn't Win" and did some minor editing to it recently:

http://outspeaking.com/words-of-technology/why-perl-didnt-wi...

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#140

Post by pwr22 » Tue, Feb 03, 2015, 12:40 AM UTC

chromatic wrote: post #139

pwr22 wrote: post #137

Earlier quoted context omitted.

Could you link to your elsewhere. I'm keen to learn more of the P6 history, good and bad

I wrote my experiences with Parrot in specific: http://www.modernperlbooks.com/mt/2013/02/goodnight-parrot.h... I did not write but agree with this view of the Parrot Foundation: http://whiteknight.github.io/2015/01/14/parrotfoundation.htm... Similarly, this retrospective from another ex-Parrot developer has similar feelings about the P6 language: http://whiteknight.github.io/2015/01/14/parrotfoundation.htm... I pers…

Thanks for sharing. I never knew you were so involved back then or that people were being treated that way