3 ms·

MoarVM's first commit You mean the first commit committed to a repository which survived long enough to be made public, eventually. Even so, if you look at the

MoarVM's first commit You mean the first commit committed to a repository which survived long enough to be made public, eventually. Even so, if you look at the timestamps on those first commits, you realize that either the design of the VM leaped from someone's head fully-formed like a virtual Athena, or (as was widely known at the time) that someone had been designing and playing with ideas for much longer. Maybe look at the chronology again? The one where Rakudo developers told Parrot hackers not to implement sixmodel to replace Parrot's default object system (the one which one of those Rakudo developers had, in fact, actually implemented) during the period where it was obvious that those Rakudo developers were in fact designing their own VM? Who am I to believe, you or my own lying eyes?

kbenson 12y ago
The one where Rakudo developers told Parrot hackers not to implement sixmodel to replace Parrot's default object system (the one which one of those Rakudo developers had, in fact, actually implemented) during the period where it was obvious that those Rakudo developers were in fact designing their own VM? Hmm, I read that as Rakudo devs trying to keep Parrot devs from starting a project that they may not want to continue in the future (given your statement it was obvious they were looking into developing their own VM). If the decision has been made, trying to reduce fallout seems wise to me, given also that they weren't public on the new direction, which I don't know the details of why.
- chromatic 12y ago
  I should have been more clear. The message wasn't "No, not ever." It was consistently "No, not yet."
  - kbenson 12y ago
    I'm not sure that changes the equation from where I'm standing. When you want to keep someone from wasting time but can't/won't explain why, using "hold off"until you can finally explain seem the logical choice since "don't do that" gives away too much. Again, I'm not addressing the given that information needs to be kept hidden, I don't know the reasoning for that. It just seems odd to me that this gets singled out as a negative when I see it as trying to make the best of a bad situation. I'm only following up on this because it seems an apt example of the emotionally driven arguments I was referencing before. I see at least several possibilities. 1) There is information I'm don't know or am not inferring correctly, 2) we have some mismatch in values that is causing us to interpret the same situation differently, 3) your emotional context causes you to interpret the situation differently (non-rationally), or finally, I have to admit it's possible 4) my emotional context is causing me to interpret the situation non-rationally. The outside appearance to me, as stated previously, is #3. That of course in no way makes it the most likely answer. (Sorry if you find this boring, I find it interesting as it mixes two interests of mine).
    - chromatic 12y ago
      I'll try to be as clear as possible, at the risk of sounding like a humorless pendant. When Rakudo announced it wanted to rewrite NQP to run on multiple backends, the stated justification for not relying on Parrot in the long term was twofold. First, because Parrot developers didn't treat Rakudo as the most important hosted language. Second, because Parrot didn't provide the features Rakudo wanted--in particular, its object model was unusable by Rakudo. Those reasons are tied together; the second was used as proof of the former. You can also throw in the deprecation policy as a supporting reason, but that makes things more complicated because Rakudo developers wanted it in place for some things ("you can't change things in Parrot and break our code") and wanted it gone for other things ("why can't you just fix this thing?"). I have a problem with both reasons #1 and #2, because I have multiple examples of Parrot developers offering to do make changes to help Rakudo. In my case, I was told not to do them. In the case of sixmodel, the stated impetus behind #2, Andrew and others (who had been accused of not wanting to help Rakudo) were continually volunteering to write the very code that Rakudo developers said they wanted and were continually told "No, not yet." (See Raiph's links, for a few of many examples. See the #parrot and #parrotsketch logs for many more.) Meanwhile, Rakudo developers were continually complaining how Parrot developers were not interested in helping Rakudo and how Parrot was technically a bad fit, citing sixmodel as an example. I interpret that response as something other than good faith. I believe that's why Parrot developers left; there's no point to sticking around in that situation.
      - kbenson 12y ago
        Thanks, that does explain a lot of your reasoning more clearly. I'm not sure I can change my assessment of the situation though, as the relative timings of these events, which I think matter greatly, aren't known to me, and the Rakudo interpretation of these circumstances isn't known to me either. I believe the Rakudo response can be explained by their belief that the special relationship between projects was unsalvageable, and the was forward was no longer in Parrot. In that case I try to fall back on my default, which is to assume people will act in their best interests while also trying to minimize damage and discomfort to others unless given cause. Whether the actions of the Rakudo developers indeed did cause a major Parrot exodus is something I'll easily cede at this point. Whether that was intended, unintended or the opposite of what was intended seems to be what we are really talking about here (because I believe intention can matter, not in assignment of blame, but as possible mitigation of scale). The irony of this is that Parrot seems to now well and truly be a P6 focused VM, as the only work done on it (besides rurban and util) is by Rakudo devs to fix bugs or make small changes to new Rakudo stuff works. Why rurban still bothers is beyond me, AIUI he's still got p2 to work on. In any case, you've been more than a good sport in humoring me in all this; you put up with more from me than I would have imagined. Thanks!
raiph 12y ago
> if you look at the timestamps on those first commits jnthn churns out great design off the cuff and generates rapid sequences of brilliant and clear commits. I've been following #perl6 for a couple years so I've gotten used to it. (I wasn't surprised when I recently found out he has a first class honors degree in cs from cambridge.) That said, confirmation bias is an ever present danger so I still investigated a lot more than just the timestamps on the first commits before I posted my prior comment. Here's the graph of contribution over time: https://github.com/MoarVM/MoarVM/graphs/contributors https://github.com/MoarVM/MoarVM/graphs/contributors Imo the pacing and content of the repo's early commits (all jnthn) are typical for jnthn. > Rakudo developers told Parrot hackers not to implement sixmodel The period you're talking about is early 2011 thru early 2012. The only two Rakudo devs that are relevant in this context are jnthn and Patrick. If jnthn was telling Parrot devs not to implement 6model throughout this period, why, on May 31st 2011, did he write several 6model docs in response to a request by lucian? Why didn't he just tell lucian not to implement 6model? http://irclog.perlgeek.de/parrot/2011-05-30#i_3827733 http://irclog.perlgeek.de/parrot/2011-05-30#i_3827733 http://irclog.perlgeek.de/parrot/2011-05-31#i_3833670 http://irclog.perlgeek.de/parrot/2011-05-31#i_3833670 If Patrick was telling Parrot devs not to implement 6model, why, on July 6th, 2011, did he suggest a two month delay of doing so with whiteknight? Why didn't he just tell whiteknight not to implement 6model? http://irclog.perlgeek.de/parrot/2011-07-06#i_4072930 http://irclog.perlgeek.de/parrot/2011-07-06#i_4072930 On february 2012, two months before jnthn started the extant MoarVM repo, not_gerd wanted to know some stuff so he could implement 6model. Again, why didn't jnthn just tell him not to implement 6model? http://irclog.perlgeek.de/perl6/2012-02-06#i_5109668 http://irclog.perlgeek.de/perl6/2012-02-06#i_5109668 > during the period where it was obvious that those Rakudo developers were in fact {developing} their own VM If it was obvious that Rakudo devs were developing their own VM in 2011, why did nobody mention it in 2011?

kbenson 12y ago

The one where Rakudo developers told Parrot hackers not to implement sixmodel to replace Parrot's default object system (the one which one of those Rakudo developers had, in fact, actually implemented) during the period where it was obvious that those Rakudo developers were in fact designing their own VM? Hmm, I read that as Rakudo devs trying to keep Parrot devs from starting a project that they may not want to continue in the future (given your statement it was obvious they were looking into developing their own VM). If the decision has been made, trying to reduce fallout seems wise to me, given also that they weren't public on the new direction, which I don't know the details of why.

chromatic 12y ago
I should have been more clear. The message wasn't "No, not ever." It was consistently "No, not yet."
- kbenson 12y ago
  I'm not sure that changes the equation from where I'm standing. When you want to keep someone from wasting time but can't/won't explain why, using "hold off"until you can finally explain seem the logical choice since "don't do that" gives away too much. Again, I'm not addressing the given that information needs to be kept hidden, I don't know the reasoning for that. It just seems odd to me that this gets singled out as a negative when I see it as trying to make the best of a bad situation. I'm only following up on this because it seems an apt example of the emotionally driven arguments I was referencing before. I see at least several possibilities. 1) There is information I'm don't know or am not inferring correctly, 2) we have some mismatch in values that is causing us to interpret the same situation differently, 3) your emotional context causes you to interpret the situation differently (non-rationally), or finally, I have to admit it's possible 4) my emotional context is causing me to interpret the situation non-rationally. The outside appearance to me, as stated previously, is #3. That of course in no way makes it the most likely answer. (Sorry if you find this boring, I find it interesting as it mixes two interests of mine).
  - chromatic 12y ago
    I'll try to be as clear as possible, at the risk of sounding like a humorless pendant. When Rakudo announced it wanted to rewrite NQP to run on multiple backends, the stated justification for not relying on Parrot in the long term was twofold. First, because Parrot developers didn't treat Rakudo as the most important hosted language. Second, because Parrot didn't provide the features Rakudo wanted--in particular, its object model was unusable by Rakudo. Those reasons are tied together; the second was used as proof of the former. You can also throw in the deprecation policy as a supporting reason, but that makes things more complicated because Rakudo developers wanted it in place for some things ("you can't change things in Parrot and break our code") and wanted it gone for other things ("why can't you just fix this thing?"). I have a problem with both reasons #1 and #2, because I have multiple examples of Parrot developers offering to do make changes to help Rakudo. In my case, I was told not to do them. In the case of sixmodel, the stated impetus behind #2, Andrew and others (who had been accused of not wanting to help Rakudo) were continually volunteering to write the very code that Rakudo developers said they wanted and were continually told "No, not yet." (See Raiph's links, for a few of many examples. See the #parrot and #parrotsketch logs for many more.) Meanwhile, Rakudo developers were continually complaining how Parrot developers were not interested in helping Rakudo and how Parrot was technically a bad fit, citing sixmodel as an example. I interpret that response as something other than good faith. I believe that's why Parrot developers left; there's no point to sticking around in that situation.
    - kbenson 12y ago
      Thanks, that does explain a lot of your reasoning more clearly. I'm not sure I can change my assessment of the situation though, as the relative timings of these events, which I think matter greatly, aren't known to me, and the Rakudo interpretation of these circumstances isn't known to me either. I believe the Rakudo response can be explained by their belief that the special relationship between projects was unsalvageable, and the was forward was no longer in Parrot. In that case I try to fall back on my default, which is to assume people will act in their best interests while also trying to minimize damage and discomfort to others unless given cause. Whether the actions of the Rakudo developers indeed did cause a major Parrot exodus is something I'll easily cede at this point. Whether that was intended, unintended or the opposite of what was intended seems to be what we are really talking about here (because I believe intention can matter, not in assignment of blame, but as possible mitigation of scale). The irony of this is that Parrot seems to now well and truly be a P6 focused VM, as the only work done on it (besides rurban and util) is by Rakudo devs to fix bugs or make small changes to new Rakudo stuff works. Why rurban still bothers is beyond me, AIUI he's still got p2 to work on. In any case, you've been more than a good sport in humoring me in all this; you put up with more from me than I would have imagined. Thanks!

raiph 12y ago

> if you look at the timestamps on those first commits jnthn churns out great design off the cuff and generates rapid sequences of brilliant and clear commits. I've been following #perl6 for a couple years so I've gotten used to it. (I wasn't surprised when I recently found out he has a first class honors degree in cs from cambridge.) That said, confirmation bias is an ever present danger so I still investigated a lot more than just the timestamps on the first commits before I posted my prior comment. Here's the graph of contribution over time: https://github.com/MoarVM/MoarVM/graphs/contributors https://github.com/MoarVM/MoarVM/graphs/contributors Imo the pacing and content of the repo's early commits (all jnthn) are typical for jnthn. > Rakudo developers told Parrot hackers not to implement sixmodel The period you're talking about is early 2011 thru early 2012. The only two Rakudo devs that are relevant in this context are jnthn and Patrick. If jnthn was telling Parrot devs not to implement 6model throughout this period, why, on May 31st 2011, did he write several 6model docs in response to a request by lucian? Why didn't he just tell lucian not to implement 6model? http://irclog.perlgeek.de/parrot/2011-05-30#i_3827733 http://irclog.perlgeek.de/parrot/2011-05-30#i_3827733 http://irclog.perlgeek.de/parrot/2011-05-31#i_3833670 http://irclog.perlgeek.de/parrot/2011-05-31#i_3833670 If Patrick was telling Parrot devs not to implement 6model, why, on July 6th, 2011, did he suggest a two month delay of doing so with whiteknight? Why didn't he just tell whiteknight not to implement 6model? http://irclog.perlgeek.de/parrot/2011-07-06#i_4072930 http://irclog.perlgeek.de/parrot/2011-07-06#i_4072930 On february 2012, two months before jnthn started the extant MoarVM repo, not_gerd wanted to know some stuff so he could implement 6model. Again, why didn't jnthn just tell him not to implement 6model? http://irclog.perlgeek.de/perl6/2012-02-06#i_5109668 http://irclog.perlgeek.de/perl6/2012-02-06#i_5109668 > during the period where it was obvious that those Rakudo developers were in fact {developing} their own VM If it was obvious that Rakudo devs were developing their own VM in 2011, why did nobody mention it in 2011?