4 ms·

You can tell that the parent post understands all that, right?

hitekker 7y ago
As per usual, the GP sees the matter from a purely technical perspective, which occludes the larger business insight that the top-level comment provides.
- kbenson 7y ago
  I very specifically pointed out that some of it was based on the relationship between the projects. I wasn't defending the situation, as much as providing context of why it was done that included non-technical reasons. To spell it out, Parrot the project started around the same time as Perl 6 the project. Initially, a lot of Parrot's purpose in reality was to be a VM for Perl 6, but Parrot also had a goal of being a good general VM for dynamic languages. From that perspective, I think they were often mentioned together because neither wanted to be overshadowed by the other to the point of obscurity, and they wanted to draw on the general audience each might bring (and there were quite a few people doing stuff in Parrot with nothing to do with Perl 6 eventually). Did it cause problems? Probably, even if you ignore the eventual blowout they had. That doesn't mean it was it was entirely a stupid technical reason by technical people ignoring marketing concerns, as part of the reason I think it was done was purely for marketing. Initially, it might have even helped (a VM for dynamic languages was a big idea back then, I know I saw a lot of people excited about it).
  - rurban 7y ago
    As parrot maintainer I could explain what caused the downfall: Stupid people. It was a CPS compiler, but after they drove the first creators away, a bunch of people who had no idea about compilers nor CPS started destroying it. First the destroyed the jit. The technical justification was bullshit. Then they destroyed the run loops, and finally the CPS (2007 YAPC workshop). This caused every function call to allocate 2 objects, continuation contexts were not reused anymore, but created on the fly for every call. After this desaster they gave up (their new idea was to create a 2nd LLVM, called something with m), and I came back to cleanup the mess. I readded the compiler optimizations, added proper lock-less threading (their current VM is lockful) and started fixing the CPS, the run loops, the GC and the Jit. But before that they decided to kill it off, and rewrote everything by themselves. But not as committee anymore and without the previous leadership, which was a very good decision. It's still a very naive architecture still, that's why it's even slower than python, the slowest scripting language on earth. Realizing that this is futile, I started improving perl5 towards perl6 instead. Just without breaking backcompat. perl11 (5+6)
    - chromatic 7y ago
      As parrot maintainer I could explain what caused the downfall: Stupid people. Reini, it seems like you think everyone who disagrees with you is stupid. This isn't an explanation for anything. We were boxed in for two really good not-primarily-technical reasons: * we had users we didn't want to abandon or cause churn * we had architectural decisions we had to improve Now I know I'm not as smart or as experienced or as knowledgeable as you are, but that doesn't mean I'm a drooling buffoon, and it certainly doesn't mean I don't have good reasons. Sometimes it means I make mistakes. Sometimes they're not even mistakes; sometimes they're just differences of opinion.
      - rurban 7y ago
        > it seems like you think everyone who disagrees with you is stupid. This isn't an explanation for anything. It is the simpliest explanation. In fact it was stupid and arrogant leadership mostly. There was no disagreement, as we didn't say a beep then. They made those stupid decisions all by themselves, and didn't listen to any advice. The better people just silently left, shaking their heads.
        chromatic 7y ago
        It is the simpliest explanation. It's the laziest explanation. Did you ever ask yourself why, for example, all of the calling convention code paths were consolidated into a single code path? It wasn't to make a single, inefficient code path as you claim. It was to provide a gradual transition for clients to a better designed calling convention system which could then be optimized for actual client uses. The goal was never to create the fastest possible VM at every single point in time. That's where I think you never understood the goal of the project, and that's where I think you've never understood the goal of p5p. The goal was to make something that works, continues to work, and can be improved while continuing to work. That's why you're no longer welcome in p5p -- because your goals and your actions are incompatible with that. I wish you understood this. You're very smart and very talented and you have a lot to offer, if you can get out of your own way and accept that people who don't share your exact goals in the exact same way aren't irredeemably stupid.
  - chromatic 7y ago
    Initially, a lot of Parrot's purpose in reality was to be a VM for Perl 6, but Parrot also had a goal of being a good general VM for dynamic languages. This was, initially, for two reasons: * allow Perl 5 code to run in process with Perl 6 code (without linking in libperl) * provide a unified VM on which Perl 5.12 could become Perl 6
    - kbenson 7y ago
      Sure. I just remember a lot of (possibly a bit pie-in-the-sky) talk about how it could be a VM for Perl and Python both. That the more concrete initial plans and to some degree work was to allow good interop between major versions of Perl doesn't surprise me. I'll defer to your memories if they contradict that though, I know you were involved to varying degrees for the first decade or so, and all I did was lurk.
      - chromatic 7y ago
        I think no one was more surprised than Simon himself that his April Fools joke turned out to be the plan.

As per usual, the GP sees the matter from a purely technical perspective, which occludes the larger business insight that the top-level comment provides.

kbenson 7y ago
I very specifically pointed out that some of it was based on the relationship between the projects. I wasn't defending the situation, as much as providing context of why it was done that included non-technical reasons. To spell it out, Parrot the project started around the same time as Perl 6 the project. Initially, a lot of Parrot's purpose in reality was to be a VM for Perl 6, but Parrot also had a goal of being a good general VM for dynamic languages. From that perspective, I think they were often mentioned together because neither wanted to be overshadowed by the other to the point of obscurity, and they wanted to draw on the general audience each might bring (and there were quite a few people doing stuff in Parrot with nothing to do with Perl 6 eventually). Did it cause problems? Probably, even if you ignore the eventual blowout they had. That doesn't mean it was it was entirely a stupid technical reason by technical people ignoring marketing concerns, as part of the reason I think it was done was purely for marketing. Initially, it might have even helped (a VM for dynamic languages was a big idea back then, I know I saw a lot of people excited about it).
- rurban 7y ago
  As parrot maintainer I could explain what caused the downfall: Stupid people. It was a CPS compiler, but after they drove the first creators away, a bunch of people who had no idea about compilers nor CPS started destroying it. First the destroyed the jit. The technical justification was bullshit. Then they destroyed the run loops, and finally the CPS (2007 YAPC workshop). This caused every function call to allocate 2 objects, continuation contexts were not reused anymore, but created on the fly for every call. After this desaster they gave up (their new idea was to create a 2nd LLVM, called something with m), and I came back to cleanup the mess. I readded the compiler optimizations, added proper lock-less threading (their current VM is lockful) and started fixing the CPS, the run loops, the GC and the Jit. But before that they decided to kill it off, and rewrote everything by themselves. But not as committee anymore and without the previous leadership, which was a very good decision. It's still a very naive architecture still, that's why it's even slower than python, the slowest scripting language on earth. Realizing that this is futile, I started improving perl5 towards perl6 instead. Just without breaking backcompat. perl11 (5+6)
  - chromatic 7y ago
    As parrot maintainer I could explain what caused the downfall: Stupid people. Reini, it seems like you think everyone who disagrees with you is stupid. This isn't an explanation for anything. We were boxed in for two really good not-primarily-technical reasons: * we had users we didn't want to abandon or cause churn * we had architectural decisions we had to improve Now I know I'm not as smart or as experienced or as knowledgeable as you are, but that doesn't mean I'm a drooling buffoon, and it certainly doesn't mean I don't have good reasons. Sometimes it means I make mistakes. Sometimes they're not even mistakes; sometimes they're just differences of opinion.
    - rurban 7y ago
      > it seems like you think everyone who disagrees with you is stupid. This isn't an explanation for anything. It is the simpliest explanation. In fact it was stupid and arrogant leadership mostly. There was no disagreement, as we didn't say a beep then. They made those stupid decisions all by themselves, and didn't listen to any advice. The better people just silently left, shaking their heads.
      - chromatic 7y ago
        It is the simpliest explanation. It's the laziest explanation. Did you ever ask yourself why, for example, all of the calling convention code paths were consolidated into a single code path? It wasn't to make a single, inefficient code path as you claim. It was to provide a gradual transition for clients to a better designed calling convention system which could then be optimized for actual client uses. The goal was never to create the fastest possible VM at every single point in time. That's where I think you never understood the goal of the project, and that's where I think you've never understood the goal of p5p. The goal was to make something that works, continues to work, and can be improved while continuing to work. That's why you're no longer welcome in p5p -- because your goals and your actions are incompatible with that. I wish you understood this. You're very smart and very talented and you have a lot to offer, if you can get out of your own way and accept that people who don't share your exact goals in the exact same way aren't irredeemably stupid.
- chromatic 7y ago
  Initially, a lot of Parrot's purpose in reality was to be a VM for Perl 6, but Parrot also had a goal of being a good general VM for dynamic languages. This was, initially, for two reasons: * allow Perl 5 code to run in process with Perl 6 code (without linking in libperl) * provide a unified VM on which Perl 5.12 could become Perl 6
  - kbenson 7y ago
    Sure. I just remember a lot of (possibly a bit pie-in-the-sky) talk about how it could be a VM for Perl and Python both. That the more concrete initial plans and to some degree work was to allow good interop between major versions of Perl doesn't surprise me. I'll defer to your memories if they contradict that though, I know you were involved to varying degrees for the first decade or so, and all I did was lurk.
    - chromatic 7y ago
      I think no one was more surprised than Simon himself that his April Fools joke turned out to be the plan.