Live data from Hacker News

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

blogs.perl.org

111–120 of 148 posts

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

#111
post #64

Earlier quoted context omitted.

The new VM seems to be a good foundation, hopefully the Whipuptitude and Manipulexity can be made performant in high-use operations.

We try to :-). Specifically, there are designs underway to implement e.g. hyper operators - those things that apply an operator to an array of values, irrespective of order - by SIMD instructions on the hardware level. If you're interested you're very welcome to come and check it out. [edit] - there is also some progress in speeding up list operations, because as it turns out making all lists lazy is not a really goo…

Is there a mailing list where such things are discussed?

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

#112
post #96

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

What are the risks still left? What things might happen/not happen that would prevent release on this schedule? Or in other words what is still left to do that is not just routine work, but actually might not be possible (or not possible in the timeframe)? Or in even more informal language, what's the holdup? :)

I'm also interested in an answer to this question. Perl 6, as a feature set, looks awesome and I'd really consider replacing my use of Python with it, espcially because of the gradual typing and fast startup time (assuming Perl 6 follows Perl 5 in this regard; my initial experiments haven't been encouraging though).

In general, I think there's huge latent demand for a relatively fast, "next-gen" scripting language, as even Python is showing its age in terms of the programming styles it doesn't support, and has no plans to.

Will it really be released by the end of this year? Obviously the history of this project induces a healthy bit of skepticism. My two cents would be that the dev team should just release it next week and fix the inevitable warts gradually.

On a related note, should I, as someone who does not know Perl, bother learning Perl 6 yet? Or is it likely to change a lot before release?

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

#113
post #94
post #67

Earlier quoted context omitted.

Well, that's a good point, really. The JVM and the CLR do run many (dynamic) languages quite efficiently. On the other hand, that is in no small part due to the man-centuries spent trying to optimise both the JVM JIT and the language-to-JVM compiler. And as a counter-example, luajit2 was built by one man (mostly) over the course of a few years, and runs very efficiently indeed, in no small part due to the lua-specifi…

Thanks, I think this basic "you go to code with the developer resources you have, not the developer resources you might want or wish to have at a later time" is desperately under-appreciated in software architecture

you go to code with the developer resources you have, not the developer resources you might want or wish to have at a later time

Ha! My experience with Rakudo was "you go to the developer resources you have, tell them not to change anything, then tell them you're going to throw away their work in favor of something you haven't written yet" and then complain when they leave.

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

#114
post #46

Earlier quoted context omitted.

IIRC the new VM (MoarVM) is around for quite a short time and it replaced Parrot in a dramatically short time. What are the advantages of MoarVM over Parrot and why were we stuck at Parrot for so long before giving it up?

> What are the advantages of MoarVM over Parrot Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. That means cleaner design, less memory footprint, faster execution. > and why were we stuck at Parrot for so long before giving it up? Rakudo works on Parrot. Why drop support for it? Once you frame the question that way, the answer be…

Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage.

I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago, but wanted to couch their "Let's burn it all down and start over" in much more careful terms which allowed them to take advantage of Parrot's stability when marketing P6 to the outside world while using Parrot's concomitant lack of development to prove that they'd made the right choice.

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

#115
post #30
post #17

Earlier quoted context omitted.

Modern scripting languages with... parametric polymorphism, built-in parallelism/concurrency, grammars, constraint-based multiple dispatch, etc.? Yes, it will be very important to build up a Perl 6 community and an ecosystem of libraries. That being said, if you want to talk about modern scripting languages, Perl 6 seems like a good choice. Ok, to be fair to functional programmers a lot of these things are old featur…

I can't seem to reply to chromatic, but my point here was to address one of the parent post's specific criticisms, that of being "modern". At least here on HN, rising languages such as Go, Scala, Elixir, and Clojure offer many of these features to help address developers' pain points. The authors of Go have themselves expressed surprise that their real audience ended up being disaffected Python programmers. If we wan…

I just wanted to touch upon how Perl 6 offers many of these things.

Sure, but in the world where I write software, my teams need code with a working ecosystem of documentation, tooling, libraries, trained or trainable developers, deployment and monitoring, and stability. I can get that from Go, Scala, and Clojure (haven't looked at Elixir).

Looking at P6's laundry list of features may be interesting from a language geek perspective, but it doesn't help me solve real problems for the foreseeable future, and there are plenty of interesting languages further ahead in the queue of things to learn.

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

#116
post #107
post #29

Earlier quoted context omitted.

Late to having a large, committed community and momentum. 15 years ago, Perl was Real Big (although I think even then PHP was starting to eat its lunch). If you launched Perl 6 then, you had a lot of active Perl projects you could talk into switching. Now, Perl 6 is Just Another Language, and it faces most of the struggles any new language/runtime would face, plus the added burden of carrying everyone's preconception…

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.

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

#117
post #112
post #96

Earlier quoted context omitted.

What are the risks still left? What things might happen/not happen that would prevent release on this schedule? Or in other words what is still left to do that is not just routine work, but actually might not be possible (or not possible in the timeframe)? Or in even more informal language, what's the holdup? :)

I'm also interested in an answer to this question. Perl 6, as a feature set, looks awesome and I'd really consider replacing my use of Python with it, espcially because of the gradual typing and fast startup time (assuming Perl 6 follows Perl 5 in this regard; my initial experiments haven't been encouraging though). In general, I think there's huge latent demand for a relatively fast, "next-gen" scripting language, a…

> On a related note, should I, as someone who does not know Perl, bother learning Perl 6 yet? Or is it likely to change a lot before release?

I don't think so. Everything I've read in recent years has indicated that the grammar is stable, which implies that the operators and planned feature set are also stable.

If you want to melt your brain, you can take a look at STD.pm6, the official grammar for Perl 6, which is also written in Perl 6:

https://github.com/perl6/std/blob/master/STD.pm6

Recent changes seem to be very minor.

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

#118
post #64

Earlier quoted context omitted.

We try to :-). Specifically, there are designs underway to implement e.g. hyper operators - those things that apply an operator to an array of values, irrespective of order - by SIMD instructions on the hardware level. If you're interested you're very welcome to come and check it out. [edit] - there is also some progress in speeding up list operations, because as it turns out making all lists lazy is not a really goo…

Is there a mailing list where such things are discussed?

We don't really use a mailing list, but we do have an IRC channel on freenode: #moarvm. Although just as often MoarVM-specific issues are discussed on #perl6

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

#119

Earlier quoted context omitted.

> What are the advantages of MoarVM over Parrot Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. That means cleaner design, less memory footprint, faster execution. > and why were we stuck at Parrot for so long before giving it up? Rakudo works on Parrot. Why drop support for it? Once you frame the question that way, the answer be…

Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago, but wanted to couch their "Let's burn it all down and start over" in much more careful terms which allowed them to take advantage of Parrot's st…

> I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago

I think you are being uncharitable. It's clear now as it has always been to me that the Rakudo developers wanted a working, fast VM that provides the needed features. Since Parrot couldn't deliver this, it was just naturally to look for alternatives.

Also, it makes me sad that you argue a lot about Rakudo's and Parrot's past, but seem to neglect their current state or the future. Could it be that you care more about how Parrot will be remembered, then about how it does today?

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

#120
post #96

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

What are the risks still left? What things might happen/not happen that would prevent release on this schedule? Or in other words what is still left to do that is not just routine work, but actually might not be possible (or not possible in the timeframe)? Or in even more informal language, what's the holdup? :)

As always in open source projects, there's the risk that a major contributor might drop out.

Barring that, there are three major technical things we want to tackle before the release: native, shaped arrays (compact storage of arrays/matrices of machine-sized types), the Great List Refactoring (GLR; mostly about speeding up list iteration and making things more consistent), and some Unicode-related tasks.

Any of those might prove more difficult than expected. I personally see the biggest risk in the list refactoring, because lists are rather central to the language as a whole.

Post reply on HN