| > Given that the multiple backend strategy only succeeded in replacing an existing backend with another backend several years later without achieving any of the interoperability goals of the JVM or CLR, I'm not even sure how to speculate on the reasoning behind that decision. Umm. It runs on MoarVM, JVM, and JavaScript. How is that not multiple backends? If I remember correctly, the JVM port predates the existence of MoarVM. Granted the JVM port has only ever been a second tier backend. Partially because it only supports Java's level of Unicode support. --- > You haven't addressed my point that I personally spent multiple months offering to make Parrot better fit NQP/PCT for P6 and was repeatedly rebuffed. Yeah, because that really wasn't the main problem. The main problem with Parrot was that the intermediate NQP/PCT code supporting it needed a complete rewrite. The intermediate code for supporting MoarVM, JVM, and JS are all very similar. They are also significantly different to how Parrot was handled. There is relatively little backend specific code in Rakudo itself for the three current ones. There was a lot of backend specific code in Rakudo for Parrot. Instead the vagaries of the different backends is mainly handled by NQP. That means that if you made Parrot work better the way Rakudo-on-NQP-on-Parrot was at the time, it would have been a wasted effort. --- Imagine the effort you were talking about doing was like tunnelling through a mountain. The problem is that Rakudo-on-NQP-on-Parrot was going around the mountain instead. Sure you would have reduced the total length. The problem is that you would have to create a new tunnel in a different direction once Rakudo-on-NQP-on-Parrot instead started tunnelling straight through the mountain to meet you. Pretty sure that's why they told you to not do that. |
Two thoughts.
First, that wasn't my plan. We were actively working on the Lorito plan to reduce the total amount of C in Parrot and eliminate the need to write C to extend Parrot, just as you suggested needed to happen in another reply.
Second, it would have been nice to sit down and come up with a plan, rather than Jonathan and Patrick deciding all of this on their own, not telling Parrot developers, and then spending years complaining that Parrot developers weren't responsive to their needs even after their antics had chased away pretty much all Parrot developers.
Granted the JVM port has only ever been a second tier backend.
Ah, so frittering away a bunch of developer time and developers helped them halfway reach a goal years later.
As predicted.