4 ms·

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!
    - chromatic 12y ago
      Whether that was intended, unintended or the opposite of what was intended seems to be what we are really talking about here. Let's assume the Rakudo developers acted in good faith per your reasonable default. The effect is still that Parrot is all but abandoned, multiple productive developers with decades of practical experience attempting to implement P6 no longer contribute to either Parrot or Rakudo, and Rakudo isn't obviously more usable than it was three years ago. The effective delivery date of P6 is still "some time in the future". The fourth anniversary of Rakudo Star is approaching and it hasn't met its goals. Even if Rakudo were released in a stable, 6.0 form today, I still wouldn't use it for anything I care about because I don't trust its developers to deliver usable software reliably.
      - 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!
  - chromatic 12y ago
    Whether that was intended, unintended or the opposite of what was intended seems to be what we are really talking about here. Let's assume the Rakudo developers acted in good faith per your reasonable default. The effect is still that Parrot is all but abandoned, multiple productive developers with decades of practical experience attempting to implement P6 no longer contribute to either Parrot or Rakudo, and Rakudo isn't obviously more usable than it was three years ago. The effective delivery date of P6 is still "some time in the future". The fourth anniversary of Rakudo Star is approaching and it hasn't met its goals. Even if Rakudo were released in a stable, 6.0 form today, I still wouldn't use it for anything I care about because I don't trust its developers to deliver usable software reliably.
    - kbenson 12y ago