Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Larry Wall's Perl 6 Release Talk [video]

youtube.com

Post reply on HN
Print view View original

61–70 of 70 posts

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

#61

Post by mj41 »

epoch1970 wrote: post #59
mj41 wrote: post #53

Earlier quoted context omitted.

Yes "we" want. And "we" don't understand what is e.g. this about https://en.wikipedia.org/wiki/List_of_Python_software#Python...

That's a perfect example of a much better approach, exactly like I was talking about earlier. There's CPython, the main Python interpreter. It's quite traditional in architecture, and is written in a very portable subset of C. It's the Python implementation that pretty much all Python developers and users happily and successfully use. Then there are the experimental or niche Python implementations. They augment very…

... instead of splintering and delaying the adoption of the language like the many failed partial Perl 6 implementations did.

I'm historian of Perl 6, a bit :-). http://www.slideshare.net/michaljurosz1/perl-family-15-years...

Open source, volunteers, real life, ecosystem, not easy to implement so feature rich language, ... this wasn't planned.

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

#62

Post by chromatic »

epoch1970 wrote: post #45
mrxenu wrote: 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…

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?

Some people will tell you to trust them. I, on the other hand, base my expectations on the history of the project and the actions of the people involved. I don't believe you can turn 15 years of disappointment and underperforming into something usable based on an arbitrary deadline enforced by yet another marketing announcement.

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

#63

Post by justinator »

epoch1970 wrote: post #59
mj41 wrote: post #53

Earlier quoted context omitted.

Yes "we" want. And "we" don't understand what is e.g. this about https://en.wikipedia.org/wiki/List_of_Python_software#Python...

That's a perfect example of a much better approach, exactly like I was talking about earlier. There's CPython, the main Python interpreter. It's quite traditional in architecture, and is written in a very portable subset of C. It's the Python implementation that pretty much all Python developers and users happily and successfully use. Then there are the experimental or niche Python implementations. They augment very…

I would almost think that what you like in Python is now available for Perl 6 (plus loads more!):

You've got MoarVM, which is just like CPython But if you want a different backend - great! Don't have to wait for MoarVM - the folks at MoarVM didn't wait for Parrot to solve their problems (or they'd still be waiting). For example, use JVM, just like Jython.

This is a stark difference to the situation of Perl 5, where there is only one interpreter, and there's little, if any chance of another. There's no Perl 5 language specification (as there is in Perl 6), except the Perl 5 interpreter. Only Perl 5 can parse Perl 5.

Perl 6 got so many things right, it's phenomenal.

Getting things right takes time, and it only happened because so many things went wrong.

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

#64

Post by cygx »

chromatic wrote: post #62
epoch1970 wrote: post #45

Earlier quoted context omitted.

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…

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? Some people will tell you to trust them. I, on the other hand, base my expectations on the history of the project and the actions of the people involved. I don't believe you can turn 15 years of disappointment and underperforming into something usable based on an arbitrary deadline enforced by y…

There obviously is some marketing involved, but in principle, this is less about Rakudo, and more about Larry freezing the 6.0 language version.

One can hope that development focus will then switch from semantics to things like stability, deployment and performance, ie the things you strongly advocated for years ago.

I guess we'll see if it's going to happen that way...

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

#65

Post by epoch1970 »

justinator wrote: post #63
epoch1970 wrote: post #59

Earlier quoted context omitted.

That's a perfect example of a much better approach, exactly like I was talking about earlier. There's CPython, the main Python interpreter. It's quite traditional in architecture, and is written in a very portable subset of C. It's the Python implementation that pretty much all Python developers and users happily and successfully use. Then there are the experimental or niche Python implementations. They augment very…

I would almost think that what you like in Python is now available for Perl 6 (plus loads more!): You've got MoarVM, which is just like CPython But if you want a different backend - great! Don't have to wait for MoarVM - the folks at MoarVM didn't wait for Parrot to solve their problems (or they'd still be waiting). For example, use JVM, just like Jython. This is a stark difference to the situation of Perl 5, where t…

It doesn't matter how many things Perl 6 got right when they got the most important thing completely wrong: the availability of a usable and reliable implementation!

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

#66

Post by chromatic »

justinator wrote: post #63
epoch1970 wrote: post #59

Earlier quoted context omitted.

That's a perfect example of a much better approach, exactly like I was talking about earlier. There's CPython, the main Python interpreter. It's quite traditional in architecture, and is written in a very portable subset of C. It's the Python implementation that pretty much all Python developers and users happily and successfully use. Then there are the experimental or niche Python implementations. They augment very…

I would almost think that what you like in Python is now available for Perl 6 (plus loads more!): You've got MoarVM, which is just like CPython But if you want a different backend - great! Don't have to wait for MoarVM - the folks at MoarVM didn't wait for Parrot to solve their problems (or they'd still be waiting). For example, use JVM, just like Jython. This is a stark difference to the situation of Perl 5, where t…

Don't have to wait for MoarVM - the folks at MoarVM didn't wait for Parrot to solve their problems (or they'd still be waiting).

This historical revisionism continues to be tiresome.

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

#67

Post by Mithaldu »

giancarlostoro wrote: post #27
codeflo wrote: post #26

So, like probably many people, I was very hyped about Perl 6 in the early 2000s, followed the mailing lists and so forth, but became disappointed and stopped caring when it became painfully clear that there had been no net progress for a decade. So please excuse my skepticism, because I'm still fascinated by Perl 6's ideas and potential. But is this another "Rakudo Star" where they just take whatever current mess the…

I keep wondering the same, especially when perl.org mentions nothing about Perl 6. It would be really nice if they showed some sort of sign there about Perl 6. Instead all we get is Perl 5.

Perl.org is a completely different organization than the people around Perl 6, just how Perl 6 is a completely different language than Perl 5.

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

#68

Post by chromatic »

cygx wrote: post #64
chromatic wrote: post #62

Earlier quoted context omitted.

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? Some people will tell you to trust them. I, on the other hand, base my expectations on the history of the project and the actions of the people involved. I don't believe you can turn 15 years of disappointment and underperforming into something usable based on an arbitrary deadline enforced by y…

There obviously is some marketing involved, but in principle, this is less about Rakudo, and more about Larry freezing the 6.0 language version. One can hope that development focus will then switch from semantics to things like stability, deployment and performance, ie the things you strongly advocated for years ago. I guess we'll see if it's going to happen that way...

While it may be technically true that "Perl 6.0 released!" is an accurate headline if you define "Perl 6.0" as "the test suite for the 6.0 language version", I suspect that almost everyone reading that headline will expect to see a stable language implementation.

Given the reception to the past year's worth of discussion around "Get ready to party", it seems irresponsible to me to continue with these semantic distinctions, as they're lost on the intended audience.

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

#69

Post by dragonwriter »

rurban wrote: post #5
visarga wrote: post #4

How fast is Perl 6 nowadays?

Faster than Perl5 with Moose, but slower than similar languages with similar features. But there are not many with this impressive feature set.

> Faster than Perl5 with Moose, but slower than similar languages with similar features. But there are not many with this impressive feature set.

Which languages with "similar features" are you comparing to Perl 6 here, and (given the second sentence) are the feature sets really similar?

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

#70

Post by dragonwriter »

epoch1970 wrote: post #45
mrxenu wrote: 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…

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

Why not? A core implementation with its own VM (MRI+YARV for Ruby from 1.9 on, for instance) seems to be pretty common for languages.

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

But that's exactly what Rakudo + MoarVM offers. For the Ruby comparison, Rakudo is analogous to MRI, MoarVM is analogous to YARV.

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

And why can't Rakudo be that implementation?

> We want something proven and familiar.

Well, clearly, it won't be proven till its been around for a while in production use, and won't be familiar till you've used it for a while. But I don't see any reason that Rakudo (which is used for some things exposed to the public now) can't be the thing that ends up "proven and familiar"?

> Unfortunately, we aren't getting that with Rakudo and MoarVM

In what concrete way is that true?

Post reply on HN