5 ms·

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

xiaq 12y ago
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?
- brrt 12y ago
  I'm the developer of the MoarVM JIT (but not the developer of the MoarVM bytecode specialisation framework, which is typically seen as part of the JIT). The weakness of Parrot VM was it's ambition - to be an efficient VM for all dynamic languages. This may have seemed possible in the past but recent work (i.e. v8, luajit2, etc) has invalidated that; it's much better (and much easier) to build a VM for a specific target than for all possible targets, as there are simply fewer points where you need abstraction. (For instance, NaN is false in javascript boolean context, but not in Perl6). More importantly, MoarVM has been designed and developed by a small set of developers applying all the lessons learned from parrot, while parrot was in many ways an experiment by committee.
  - chromatic 12y ago
    You say potato, I say "Parrot was designed to implement the semantics of both Perl 5 and Rakudo in the same process." You say "It's better to build a specialized VM", I say "Emscripten, Clojure, Niecza, Truffle, and Jakudo."
    - brrt 12y ago
      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-specific choices that have been made. So what I'm trying to say is that there is a second tradeoff, somewhere between programmer efficiency, runtime efficiency, and running time, and that MoarVM is making a better tradeoff for perl6 than parrot is.
      - themgt 12y ago
        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
        chromatic 12y ago
        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.
- perlgeek 12y ago
  > 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 becomes obvious: because there hasn't been big changes to the code generation yet that would make continued parrot support painful. Once we reach that point, the situation will be reconsidered.
  - chromatic 12y ago
    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.
    - perlgeek 12y ago
      > 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?
    - kbenson 12y ago
      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 being uncharitable, and what does that have to do with whether some people wanted something different long ago?
RichardCA 12y ago
I don't see anywhere where it says the project is getting behind MoarVM, and this will be the official runtime that ships. Is this in fact the case?
- kbenson 12y ago
  Perl 6 is a spec, and different implementations are possible and encouraged. Rakudo is an implementation, and targets a few different VMs, including Parrot, MoarVM and the JVM. A lot of effort is being put into making MoarVM a good VM for the intermediate language that Rakudo uses to implement Perl 6, but AFAIK the JVM is kept up to date as well, and Parrot is also where time and expertise exist.
  - RichardCA 12y ago
    Thanks, my intention in asking the question was to see if there is any willingness to speak about what will ship. I don't need a pedantic explanation of the runtimes, I want to know if a decision has been made to get behind one of them. I've been waiting 15 years to hear some actual details about what I can expect when I install this thing.
    - kbenson 12y ago
      Why wait? I assume it will be similar to Rakudo Star, which packages[0] Perl 6 for regular consumption on a semi-monthly (quarterly now?) basis, which you can download windows installers for here[1]. If you aren't on windows, compile, it's not that hard, directions are included in the github repo for Rakudo[2] under INSTALL.txt. You can see more info on that at the Rakudo website[3]. 0: MSI installers for MoarVM and Parrot, I assume JVM bytecode it includes is in there as it stated it ships with "experimental JVM support." 1: http://rakudo.org/downloads/star/ http://rakudo.org/downloads/star/ 2: https://github.com/rakudo/rakudo https://github.com/rakudo/rakudo 3: http://rakudo.org/ http://rakudo.org/
    - SwellJoe 12y ago
      MoarVM is the closest to "ready", and seems to be what most of the developers actually using Perl 6 today are using. But, as the prior post mentioned, Rakudo-JVM and Rakuda-Parrot are also getting closer to ready. All of them will likely "ship", as long as the developers keep working on them, and Perl 6 code will likely run correctly on any of them. Here is the current feature test statuses of the Perl 6 compilers/runtimes: http://perl6.org/compilers/features http://perl6.org/compilers/features Note that the Rakudo-MoarVM runtime is the closest to feature complete, with Rakudo-JVM close behind. In short, you can expect you'll get whichever runtime you install, and if that runtime is ready for production you can expect that Perl 6 will work on that runtime. MoarVM will likely be the first to be ready for production. You may have other reasons for choosing a runtime; if you have a Java/Clojure/Scala shop and wanted a powerful scripting language to integrate into your systems, the JVM runtime might be just the thing. If you wanted the fastest Perl 6 for standalone Perl 6 applications, MoarVM will likely be it (I think, I haven't looked at benchmarks, just guessing). The FFI may be easier to work with in MoarVM, if you need C or other compiled external libraries...but maybe not. I'm not at all familiar with how that works in JVM runtimes, but it seems like it would be more convoluted.
insertion 12y ago
Looking at the release as a whole, I'd be fascinated to hear what features have taken the most time and effort? What turned out to be much harder than expected?
- perlgeek 12y ago
  One big challenge is the sweet spot between flexibility and optimizability. Perl 6 is designed for extensibility, and yet we know at compile time where a given subroutine will dispatch to. Getting the right trade-offs there was no easy task. Another challenge was how to make the type system and built-in types so that stuff works intuitively for a Perl programmer, and still has sane rules in the type system. Finally a thing that's surprisingly tricky is precompilation. You need to serialize types and objects, and then another compilation unit comes, and needs to modify something, so it claims ownership over a piece of serialized data or code. There are way too many nasty corner cases in that area.
DougHaber 12y ago
Forgive me for this, but why is it still called Perl 6? I've been a professional Perl developer for a long time, and I've followed Perl 6 since the first announcements. There is some impressive and really interesting work going on there, but from my perspective it seems to be a new language rather than a new version of Perl. I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl. It seems like the usage of the name "Perl" has actually done a fair amount of damage to the Perl 5 language, and the Perl community. Non-Perl programmers don't understand what is happening. To them, Perl 6 is just the next version of Perl, and the long wait for Perl 6 is a sign of problems within the Perl community. To many of them when Perl 6 comes out it will be the obvious choice to use for new projects, since the name implies it is the new version, even though the reality is that Perl 5 will likely be the correct choice for a large number of new projects for many years to come. Perl has become a punching bag by the uninformed who speak about it as a dying, irrelevant, read-only language. Perl 6 carrying the Perl name has helped reinforce those views, allowing them to incorrectly speak of the lack of new versions, the future versions breaking backwards compatibility, and many of the changes being a strong admission that something was very wrong with Perl 5. When Perl 6 is released there will be a lot of confusion and the common belief will become that Perl 5 is even more irrelevant. So, why not stop using the name "Perl" and call it something different? Wouldn't it be better for everyone if Perl 6 was regarded as a new and separate language?
- perlgeek 12y ago
  > I've been a professional Perl developer for a long time, and I've followed Perl 6 since the first announcements. There is some impressive and really interesting work going on there, but from my perspective it seems to be a new language rather than a new version of Perl. It's both, really. If you use it (and after a while of getting used it), it just feels like perl. > I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl. Well, in retrospect, it might have been a good idea to name it something else entirely. But that's too late now, and nobody has been able to come up with a good new name anyway. And the "Perl" brand is still very strong, so we are loath to give it up. Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.
chrisseaton 12y ago
Some of the presentations I've seen make it look like MoarVM does some kind of AST specialisation before it gets to the JIT. Is there any documentation of how that works?
- perlgeek 12y ago
  Not that I'm aware of, sorry. Some of things it does: * type specialization. It looks at repeated executions of a piece of code, and if the type of a variable or parameter is stable, it assumes it'll be always that way, and specializes the code for that (for example, always picks a method from the same class). And of course it inserts a guard clause to ensure that if the type should change, it takes the slow (but correct) path * inlining * container removal. In Perl 6, things generally become mutable by being inside a container (think pointer), and if the specializer finds cases where that's not needed, it generates better code for them * reachability analysis and elimination of allocations are being worked on, iirc.
  - chrisseaton 12y ago
    Do you know who it might be best to talk to about the AST/bytecode specialisation? I work on a compiler with AST specialisations and I'm interested in their approach.
    - colomon 12y ago
      Check out #moarvm on irc.freenode.net.
dodyg 12y ago
How flexible is the subset type functionality in Perl 6?
- perlgeek 12y ago
  It allows arbitrary code to define the subset. So it's very flexible, but it also means that compiler usually can't be clever about subsets. We can't solve the Halting problem for you.
- raiph 12y ago
  Make sure you also look at the design document section titled "Multiple constraints": http://design.perl6.org/S12.html#Multiple_constraints http://design.perl6.org/S12.html#Multiple_constraints It concludes with: > As a first approximation for 6.0.0, subsets of enums are static, and other subsets are dynamic. We may refine this in subsequent versions of Perl.
ars 12y ago
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? :)
- xaa 12y ago
  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?
  - SrslyJosh 12y ago
    > 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 https://github.com/perl6/std/blob/master/STD.pm6 Recent changes seem to be very minor.
    - ab5tract 12y ago
      Just to clarify, as you responded "I don't think so" to two questions, the language is not going to change too significantly prior to release, so yes you should bother learning Perl 6. No one I've met who has actually bother to use the language has had anything but excitement about it.
kbd 12y ago
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?
- xaduha 12y ago
  http://irclog.perlgeek.de/moarvm/search/?nick=&q=pypy http://irclog.perlgeek.de/moarvm/search/?nick=&q=pypy http://irclog.perlgeek.de/perl6/search/?nick=&q=pypy http://irclog.perlgeek.de/perl6/search/?nick=&q=pypy I think that the initial port of Rakudo to JVM was done by jnthn single-handedly. I don't know how PyPy compares with JVM though.
- b2gills 12y ago
  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.
  - kbd 12y ago
    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.

xiaq 12y ago

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?

brrt 12y ago
I'm the developer of the MoarVM JIT (but not the developer of the MoarVM bytecode specialisation framework, which is typically seen as part of the JIT). The weakness of Parrot VM was it's ambition - to be an efficient VM for all dynamic languages. This may have seemed possible in the past but recent work (i.e. v8, luajit2, etc) has invalidated that; it's much better (and much easier) to build a VM for a specific target than for all possible targets, as there are simply fewer points where you need abstraction. (For instance, NaN is false in javascript boolean context, but not in Perl6). More importantly, MoarVM has been designed and developed by a small set of developers applying all the lessons learned from parrot, while parrot was in many ways an experiment by committee.
- chromatic 12y ago
  You say potato, I say "Parrot was designed to implement the semantics of both Perl 5 and Rakudo in the same process." You say "It's better to build a specialized VM", I say "Emscripten, Clojure, Niecza, Truffle, and Jakudo."
  - brrt 12y ago
    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-specific choices that have been made. So what I'm trying to say is that there is a second tradeoff, somewhere between programmer efficiency, runtime efficiency, and running time, and that MoarVM is making a better tradeoff for perl6 than parrot is.
    - themgt 12y ago
      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
      - chromatic 12y ago
        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.
perlgeek 12y ago
> 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 becomes obvious: because there hasn't been big changes to the code generation yet that would make continued parrot support painful. Once we reach that point, the situation will be reconsidered.
- chromatic 12y ago
  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.
  - perlgeek 12y ago
    > 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?
  - kbenson 12y ago
    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 being uncharitable, and what does that have to do with whether some people wanted something different long ago?

RichardCA 12y ago

I don't see anywhere where it says the project is getting behind MoarVM, and this will be the official runtime that ships. Is this in fact the case?

kbenson 12y ago
Perl 6 is a spec, and different implementations are possible and encouraged. Rakudo is an implementation, and targets a few different VMs, including Parrot, MoarVM and the JVM. A lot of effort is being put into making MoarVM a good VM for the intermediate language that Rakudo uses to implement Perl 6, but AFAIK the JVM is kept up to date as well, and Parrot is also where time and expertise exist.
- RichardCA 12y ago
  Thanks, my intention in asking the question was to see if there is any willingness to speak about what will ship. I don't need a pedantic explanation of the runtimes, I want to know if a decision has been made to get behind one of them. I've been waiting 15 years to hear some actual details about what I can expect when I install this thing.
  - kbenson 12y ago
    Why wait? I assume it will be similar to Rakudo Star, which packages[0] Perl 6 for regular consumption on a semi-monthly (quarterly now?) basis, which you can download windows installers for here[1]. If you aren't on windows, compile, it's not that hard, directions are included in the github repo for Rakudo[2] under INSTALL.txt. You can see more info on that at the Rakudo website[3]. 0: MSI installers for MoarVM and Parrot, I assume JVM bytecode it includes is in there as it stated it ships with "experimental JVM support." 1: http://rakudo.org/downloads/star/ http://rakudo.org/downloads/star/ 2: https://github.com/rakudo/rakudo https://github.com/rakudo/rakudo 3: http://rakudo.org/ http://rakudo.org/
  - SwellJoe 12y ago
    MoarVM is the closest to "ready", and seems to be what most of the developers actually using Perl 6 today are using. But, as the prior post mentioned, Rakudo-JVM and Rakuda-Parrot are also getting closer to ready. All of them will likely "ship", as long as the developers keep working on them, and Perl 6 code will likely run correctly on any of them. Here is the current feature test statuses of the Perl 6 compilers/runtimes: http://perl6.org/compilers/features http://perl6.org/compilers/features Note that the Rakudo-MoarVM runtime is the closest to feature complete, with Rakudo-JVM close behind. In short, you can expect you'll get whichever runtime you install, and if that runtime is ready for production you can expect that Perl 6 will work on that runtime. MoarVM will likely be the first to be ready for production. You may have other reasons for choosing a runtime; if you have a Java/Clojure/Scala shop and wanted a powerful scripting language to integrate into your systems, the JVM runtime might be just the thing. If you wanted the fastest Perl 6 for standalone Perl 6 applications, MoarVM will likely be it (I think, I haven't looked at benchmarks, just guessing). The FFI may be easier to work with in MoarVM, if you need C or other compiled external libraries...but maybe not. I'm not at all familiar with how that works in JVM runtimes, but it seems like it would be more convoluted.

insertion 12y ago

Looking at the release as a whole, I'd be fascinated to hear what features have taken the most time and effort? What turned out to be much harder than expected?

perlgeek 12y ago
One big challenge is the sweet spot between flexibility and optimizability. Perl 6 is designed for extensibility, and yet we know at compile time where a given subroutine will dispatch to. Getting the right trade-offs there was no easy task. Another challenge was how to make the type system and built-in types so that stuff works intuitively for a Perl programmer, and still has sane rules in the type system. Finally a thing that's surprisingly tricky is precompilation. You need to serialize types and objects, and then another compilation unit comes, and needs to modify something, so it claims ownership over a piece of serialized data or code. There are way too many nasty corner cases in that area.

DougHaber 12y ago

Forgive me for this, but why is it still called Perl 6? I've been a professional Perl developer for a long time, and I've followed Perl 6 since the first announcements. There is some impressive and really interesting work going on there, but from my perspective it seems to be a new language rather than a new version of Perl. I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl. It seems like the usage of the name "Perl" has actually done a fair amount of damage to the Perl 5 language, and the Perl community. Non-Perl programmers don't understand what is happening. To them, Perl 6 is just the next version of Perl, and the long wait for Perl 6 is a sign of problems within the Perl community. To many of them when Perl 6 comes out it will be the obvious choice to use for new projects, since the name implies it is the new version, even though the reality is that Perl 5 will likely be the correct choice for a large number of new projects for many years to come. Perl has become a punching bag by the uninformed who speak about it as a dying, irrelevant, read-only language. Perl 6 carrying the Perl name has helped reinforce those views, allowing them to incorrectly speak of the lack of new versions, the future versions breaking backwards compatibility, and many of the changes being a strong admission that something was very wrong with Perl 5. When Perl 6 is released there will be a lot of confusion and the common belief will become that Perl 5 is even more irrelevant. So, why not stop using the name "Perl" and call it something different? Wouldn't it be better for everyone if Perl 6 was regarded as a new and separate language?

perlgeek 12y ago
> I've been a professional Perl developer for a long time, and I've followed Perl 6 since the first announcements. There is some impressive and really interesting work going on there, but from my perspective it seems to be a new language rather than a new version of Perl. It's both, really. If you use it (and after a while of getting used it), it just feels like perl. > I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl. Well, in retrospect, it might have been a good idea to name it something else entirely. But that's too late now, and nobody has been able to come up with a good new name anyway. And the "Perl" brand is still very strong, so we are loath to give it up. Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.

chrisseaton 12y ago

Some of the presentations I've seen make it look like MoarVM does some kind of AST specialisation before it gets to the JIT. Is there any documentation of how that works?

perlgeek 12y ago
Not that I'm aware of, sorry. Some of things it does: * type specialization. It looks at repeated executions of a piece of code, and if the type of a variable or parameter is stable, it assumes it'll be always that way, and specializes the code for that (for example, always picks a method from the same class). And of course it inserts a guard clause to ensure that if the type should change, it takes the slow (but correct) path * inlining * container removal. In Perl 6, things generally become mutable by being inside a container (think pointer), and if the specializer finds cases where that's not needed, it generates better code for them * reachability analysis and elimination of allocations are being worked on, iirc.
- chrisseaton 12y ago
  Do you know who it might be best to talk to about the AST/bytecode specialisation? I work on a compiler with AST specialisations and I'm interested in their approach.
  - colomon 12y ago
    Check out #moarvm on irc.freenode.net.

dodyg 12y ago

How flexible is the subset type functionality in Perl 6?

perlgeek 12y ago
It allows arbitrary code to define the subset. So it's very flexible, but it also means that compiler usually can't be clever about subsets. We can't solve the Halting problem for you.
raiph 12y ago
Make sure you also look at the design document section titled "Multiple constraints": http://design.perl6.org/S12.html#Multiple_constraints http://design.perl6.org/S12.html#Multiple_constraints It concludes with: > As a first approximation for 6.0.0, subsets of enums are static, and other subsets are dynamic. We may refine this in subsequent versions of Perl.

ars 12y ago

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? :)

xaa 12y ago
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?
- SrslyJosh 12y ago
  > 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 https://github.com/perl6/std/blob/master/STD.pm6 Recent changes seem to be very minor.
  - ab5tract 12y ago
    Just to clarify, as you responded "I don't think so" to two questions, the language is not going to change too significantly prior to release, so yes you should bother learning Perl 6. No one I've met who has actually bother to use the language has had anything but excitement about it.

kbd 12y ago

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?

xaduha 12y ago
http://irclog.perlgeek.de/moarvm/search/?nick=&q=pypy http://irclog.perlgeek.de/moarvm/search/?nick=&q=pypy http://irclog.perlgeek.de/perl6/search/?nick=&q=pypy http://irclog.perlgeek.de/perl6/search/?nick=&q=pypy I think that the initial port of Rakudo to JVM was done by jnthn single-handedly. I don't know how PyPy compares with JVM though.
b2gills 12y ago
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.
- kbd 12y ago
  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.