6 ms·

> The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM an

> The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing. The reason the implementation is named (Rakudo), is because there's a spec, and originally there were a few people making implementations. There was good effort from individuals on C and C# versions that were more monolithic, and Rakudo was where most the community work went since it was designed in a way to be more cross platform (it's mostly implemented in the minimal NQP languages, which is "not-quite perl". It's a much easier thing to port to a VM, and then you get like 90% of the language features already designed and working). The reason the VM is noted is because it changed a couple of times. Bringing the VM name into it lets people know that if it's different, maybe it will have fixed their main performance complaints. To my knowledge, they haven't used parrot in a decade or so, and there's actually some bad blood between the VM and Perl 6/Rakudo (which had different teams, another reason to brand with both. So, Perl 6 is the standard. There have been multiple implementations to varying degrees of completeness, including but not limited to Rakudo, Pugs, and Niecza. Those implementations have generally targeted one or more VM targets, including Parrot, MoarVM, Java, .Net and custom VMs. It may or may not have hurt adoption seeing this terminology, but it was there for a reason, because it denoted very large important aspects of what was going on behind the scenes, and in some cases doing otherwise could have worked against some relationships that were going on between projects.

jannotti 7y ago
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)
davidw 7y ago
> So, Perl 6 is the standard. There have been multiple implementations to varying degrees of completeness, including but not limited to Rakudo, Pugs, and Niecza. Those implementations have generally targeted one or more VM targets, including Parrot, MoarVM, Java, .Net and custom VMs. That sounds like a really solid foundation to build a business on... I think if people are willing to look with an unbiased eye, there are a lot of software marketing lessons to be learned from the rise and fall of Perl. It got a bunch of stuff right back in the day.
- hitekker 7y ago
  Do you have some articles or reading that you'd recommend on Software Marketing vis-a-vis Perl?
  - davidw 7y ago
    No - I'm just saying that it objectively gained a lot of popularity because they did some things right, and then lost it again because they got some things wrong. Of course part of that is technical, but part of 'marketing' is understanding what your users want and delivering it to them. This article I wrote about Tcl a while back is what I'm talking about: https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...
    - dragonwriter 7y ago
      > I'm just saying that it objectively gained a lot of popularity because they did some things right, and then lost it again because they got some things wrong. Yeah, but you keep pointing to things that are exactly like many successful projects as wrong, like having a different name for the language vs. an implementation vs. backends used by the implementation. I will suggest that the two things they actuallt got wrong were: (1) Calling it “perl”, and (2) Taking forever. And, really, those two in combination: even being as distinct as it is, had it stabilized in a reasonable period of time, and had once it stabilized a reasonable transition path been provided, it might have been another Python 2 to Python 3 problem, but not a complete disaster. Conversely, ha for been a new experimental language and not “Perl 6”, taking forever to stabilize would have been more tolerable.
dragonwriter 7y ago
> So, Perl 6 is the standard Well, more accurately, it's the language name (like SQL). Standards include Perl 6.c, and Perl 6.d (Like SQL-2011 and SQL-2016)

jannotti 7y ago

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)

davidw 7y ago

> So, Perl 6 is the standard. There have been multiple implementations to varying degrees of completeness, including but not limited to Rakudo, Pugs, and Niecza. Those implementations have generally targeted one or more VM targets, including Parrot, MoarVM, Java, .Net and custom VMs. That sounds like a really solid foundation to build a business on... I think if people are willing to look with an unbiased eye, there are a lot of software marketing lessons to be learned from the rise and fall of Perl. It got a bunch of stuff right back in the day.

hitekker 7y ago
Do you have some articles or reading that you'd recommend on Software Marketing vis-a-vis Perl?
- davidw 7y ago
  No - I'm just saying that it objectively gained a lot of popularity because they did some things right, and then lost it again because they got some things wrong. Of course part of that is technical, but part of 'marketing' is understanding what your users want and delivering it to them. This article I wrote about Tcl a while back is what I'm talking about: https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...
  - dragonwriter 7y ago
    > I'm just saying that it objectively gained a lot of popularity because they did some things right, and then lost it again because they got some things wrong. Yeah, but you keep pointing to things that are exactly like many successful projects as wrong, like having a different name for the language vs. an implementation vs. backends used by the implementation. I will suggest that the two things they actuallt got wrong were: (1) Calling it “perl”, and (2) Taking forever. And, really, those two in combination: even being as distinct as it is, had it stabilized in a reasonable period of time, and had once it stabilized a reasonable transition path been provided, it might have been another Python 2 to Python 3 problem, but not a complete disaster. Conversely, ha for been a new experimental language and not “Perl 6”, taking forever to stabilize would have been more tolerable.

dragonwriter 7y ago

> So, Perl 6 is the standard Well, more accurately, it's the language name (like SQL). Standards include Perl 6.c, and Perl 6.d (Like SQL-2011 and SQL-2016)