Live data from Hacker News

Larry Wall's Perl 6 Release Talk [video]

youtube.com

41–50 of 70 posts

Re: Larry Wall's Perl 6 Release Talk [video]

#41

When will a traditional interpreter written in C and running just about everywhere be available for Perl 6? All of the successful scripting languages have one: Perl 5 and earlier, Python, Ruby, Tcl, Lua, PHP, and even UNIX shell scripts. Yet when it comes to Perl 6, we just don't see that. The Perl 6 community has spun its wheels time and time and time again with half-baked interpreters written in an obscure language…

> with half-baked interpreters written in an obscure language like Haskell Because the author thought it to be fun. You know, hackers and all. > or written in Perl 6 itself using half-baked Perl 6 to 5 converters Oh, I don't think that ever happened. You may be thinking of NQP? Which is still a Thing, and it's what Perl 6 is written in, which is amazing. There was also the initial idea that Perl 6 could run Perl 5, b…

> or written in Perl 6 itself using half-baked Perl 6 to 5 converters

Oh, I don't think that ever happened.

That might be a reference to viv, which was used to implement STD (cf http://perl6.org/compilers/std-viv ).

There was also the initial idea that Perl 6 could run Perl 5, but this is proving impossible.

Personally, if Rakudo ever starts outperforming Perl5 for practical workloads, I believe that idea might eventually be revisited.

Re: Larry Wall's Perl 6 Release Talk [video]

#42

Earlier quoted context omitted.

I don't think so - it's still 'slower than similar languages with similar features', so not sure what difference it makes that there aren't many languages to compare against, if when we do compare it's still slower. I'd be interested to see what features there are that make the system slower in general, even when they aren't being used. I did a lot of work in my PhD on making odd features not affect the performance o…

Not directly, sadly. I can make an educated guess though, since Perl 5 has since adopted many of the features thought up for Perl 6. Particularly try looking at its OO features, in regards to roles, parametrized roles, reflection and automated attribute/constructor creation. I can't say with confidence, but i suspect the number of languages having all those features is very low, if existent, and the number of languag…

I'm not sure if Perl 5 has adopted these features, but these features have been implemented in Perl 5 via modules [0], which is excellent - but sadly, this is vastly different than being in core, or even having the modules in core. I don't even think you can set default attributes in Perl 5 methods. You still have to pass around the object, shift it off - a whole lot of boilerplate. Something as simple as that has been proposed, but it's not been in production for Perl 5. (without Moose and friends, of course)

Really, there hasn't been a terrible amount of new features in Perl 5 - and certainly not a new model for OO. Moose is great! And the constant release of CPAN modules is also wonderful, but the core of Perl 5 is full of dragons, which makes backporting features from Perl 6 hard to do in core - and perhaps a good argument can be made against doing that. Example: Moose is a very successful project, but thee given/when statement in the core of Perl was a failure.

[0] http://moose.iinteractive.com/en/

Re: Larry Wall's Perl 6 Release Talk [video]

#43
post #2

Cool. I am glad there has been enough support and supporters over the years to push it to the finish. Compiled native executables, concurrency, async code blocks, and much more. I look forward to learning as soon as I get a chance. Hoping that companies adopt as well.

compile native executables How does that work? is the moarvm bundled in the executable?

It doesn't, no idea where the OP got that idea from. 'Fakecutables' bundling interpreter and bytecode might arrive in the future, though.

Re: Larry Wall's Perl 6 Release Talk [video]

#44

Earlier quoted context omitted.

Really? printf is cool and useful for it's own domain. But there is a reason that languages provide interpolation. And the simplest possible example above is not one of those reasons.

You imply, but fail to make any actual points or explanations.

I'm not going to bother convincing you that printf is not the highest form of string interpolation. Seems like you've got your bases covered pretty well.

Re: Larry Wall's Perl 6 Release Talk [video]

#45
post #37

When will a traditional interpreter written in C and running just about everywhere be available for Perl 6? All of the successful scripting languages have one: Perl 5 and earlier, Python, Ruby, Tcl, Lua, PHP, and even UNIX shell scripts. Yet when it comes to Perl 6, we just don't see that. The Perl 6 community has spun its wheels time and time and time again with half-baked interpreters written in an obscure language…

I don't quite get your point. MoarVM was created specifically for Perl 6, it is written in C and just works. JVM support in Rakudo is just added bonus and you are free to ignore it (like most users do). For 99% users "Perl 6" will mean just "Rakudo + MoarVM" which seems to be exactly what you're asking for. Note that MoarVM is nothing like Parrot. Parrot was a failed project which intended to bring universal VM for a…

I'd like to use Perl 6, but after 15 years of waiting there still isn't an implementation ready for production use.

Rakudo and MoarVM clearly aren't what we, as potential Perl 6 developers and users, want.

They look far too similar to the many other similar Perl 6 failures we've seen.

How are we to trust that Rakudo won't go the way of Pugs, or that MoarVM won't go the way of Parrot, leaving us in a lurch?

Even if they do remain viable, we don't want to have to deal with separate VMs, regardless of whether they're specific to Perl 6 or not.

We don't want to deal with the bugs and compatibility issues that invariably pop up when dealing with separate compilers and VMs.

Like I said, we want the Perl 5, Ruby, Python, Lua, and Tcl type of experience.

We want there to be one consistent implementation that's widely used and trusted.

We want something proven and familiar.

Unfortunately, we aren't getting that with Rakudo and MoarVM, nor from the many other unsuccessful attempts in the past.

Re: Larry Wall's Perl 6 Release Talk [video]

#46
post #18

Earlier quoted context omitted.

Don't forget about the grammar engine - the parsing speed is only in the hundreds as measured in lines of code/s, which is a concern for script startup. I've come up with rather 'creative' workarounds[1] until a more proper solution arrives... [1] https://github.com/cygx/6make/blob/master/6make

He does call it a "compiler" in the video. Maybe that's temporary while it's still unoptimized, or a change in direction?

Perl5 historically has compiled to bytecode and then interpreted the bytecode. I imagine that's what's going on here.

Re: Larry Wall's Perl 6 Release Talk [video]

#47

Earlier quoted context omitted.

Not directly, sadly. I can make an educated guess though, since Perl 5 has since adopted many of the features thought up for Perl 6. Particularly try looking at its OO features, in regards to roles, parametrized roles, reflection and automated attribute/constructor creation. I can't say with confidence, but i suspect the number of languages having all those features is very low, if existent, and the number of languag…

I'm not sure if Perl 5 has adopted these features, but these features have been implemented in Perl 5 via modules [0], which is excellent - but sadly, this is vastly different than being in core, or even having the modules in core. I don't even think you can set default attributes in Perl 5 methods. You still have to pass around the object, shift it off - a whole lot of boilerplate. Something as simple as that has be…

I could write a lot to explain it, but at the end of the day, unless you can accept the following it is not worth the effort.

CPAN is the language, perl is just the VM.

Re: Larry Wall's Perl 6 Release Talk [video]

#48
post #37

Earlier quoted context omitted.

I don't quite get your point. MoarVM was created specifically for Perl 6, it is written in C and just works. JVM support in Rakudo is just added bonus and you are free to ignore it (like most users do). For 99% users "Perl 6" will mean just "Rakudo + MoarVM" which seems to be exactly what you're asking for. Note that MoarVM is nothing like Parrot. Parrot was a failed project which intended to bring universal VM for a…

I'd like to use Perl 6, but after 15 years of waiting there still isn't an implementation ready for production use. Rakudo and MoarVM clearly aren't what we, as potential Perl 6 developers and users, want. They look far too similar to the many other similar Perl 6 failures we've seen. How are we to trust that Rakudo won't go the way of Pugs, or that MoarVM won't go the way of Parrot, leaving us in a lurch? Even if th…

Maybe you should do a little research? Rakudo is backed by the Perl foundation. It's not going away and neither is the MoarVM.

Rakudo + MoarVM is going to be "it" going forward I would think. I guess we'll wait and see. That doesn't mean that other compilers won't come along because that is one of the benefits of Perl 6. All the languages you mention have different versions out there. The only one that doesn't is Perl 5 and that's because only Perl can parse Perl. That's going away with Perl 6 and that's good. Rakudo+MoarVM is great. It still leaves the door open for genius to shine.

Rakudo + MoarVM is exactly what potential Perl 6 developers want. Everything else is just gravy.

I have no idea if Perl 6 will "take off". I hope it gains traction. Watching Larry Wall got me interested enough to install it and start learning it anyway.

Re: Larry Wall's Perl 6 Release Talk [video]

#49
post #43

Earlier quoted context omitted.

compile native executables How does that work? is the moarvm bundled in the executable?

It doesn't, no idea where the OP got that idea from. 'Fakecutables' bundling interpreter and bytecode might arrive in the future, though.

I got it from here (page 33):

http://www.liz.nl/C-DayIsComingYAPCEU.pdf

So probably not "native" executables, but compiling and optimizing nonetheless.

Re: Larry Wall's Perl 6 Release Talk [video]

#50
post #49
post #43

Earlier quoted context omitted.

It doesn't, no idea where the OP got that idea from. 'Fakecutables' bundling interpreter and bytecode might arrive in the future, though.

I got it from here (page 33): http://www.liz.nl/C-DayIsComingYAPCEU.pdf So probably not "native" executables, but compiling and optimizing nonetheless.

That refers to precompilation to MoarVM bytecode. You can do that manually right now, but eventually, a precompilation cache will be managed by Rakudo.
Post reply on HN