chromatic

When I joined in 2002, there were only a couple of developers in general, and no one sponsored to work on or evangelize any specific technology full time. Sometimes I wonder if Sun had more paid people working on Tcl.

I don't mean to malign or sideline the work anyone at ORA or ActiveState did in those days. Certainly the latter did more work to make Perl a first-class language on Windows than anyone. Yet that's very different from a funded Python Software Foundation or Sun supporting Java or the entire web browser industry funding JavaScript or....

Back when Parrot was a thing and the Perl 6 people were targeting it, I profiled the prelude of Perl 6 to optimize startup time and discovered two things:

- the first basic block of the prelude was thousands of instructions long (not surprising) - the compiler had to allocate thousands of registers because the prelude instructions used virtual registers

The prelude emitted two instructions, one right after another: load a named symbol from a library, then make it available. I forget all of the details, but each of those instructions either one string register and one PMC register. Because register allocation used the dominance frontier method, the size of the basic block and total number of all symbolic registers dominated the algorithm.

I suggested a change to the prelude emitter to reuse actual registers and avoid virtual registers and compilation sped up quite a bit.

    use v5.40;

    ....

(I'd argued for that feature for years with my `Modern::Perl` feature bundle; glad to see that can be deprecated now.)

Perl 6 was intended from the start to be the next major release of Perl (at various times, a replacement for a 5.10 or 5.12 or 5.14), and it was intended to have a backwards compatibility mode to run 5.8 (or 5.10 or 5.12) code in the same process, with full interoperability.

As time went by, that plan became less and less likely. Some people came up with the idea that Perl and P6 were "sister languages", both to have new major releases. I think this happened sometime around 2009 or so, maybe as early as 2007.

Also by 2011 or so, the P6 developers effectively scuttled the backwards compatibility plan and code written to that point, but I've argued that their plan to replace Parrot was a mistake enough here and elsewhere already. (Sometimes I wonder, now that MoarVM is older than Parrot was when Parrot was declared unsuitable, if they've achieved their promised speed and compatibility goals.)

From my reading of the documentation of the former (especially the MAPPING section), it has the same problem for the same reasons.

the whole thing is a tangled mess of wrongness

Perl has monomorphic operators and polymorphic values. Every time someone tries to flip that, whether encoding arbitrary data structures to monomorphic values via a polymorphic visitor pattern, the smart-match experiment, or (as I already mentioned in this story's comments) polymorphic operators for data structure dereferencing, these problems occur.

Regardless of whether anyone believes that Perl's operator/value design is good or useful, that's how the language works. Working at cross purposes is an exercise in frustration. (I'll leave analogies about duck typing, contravariance, casting, and type erasure to people who like debating programming language design.)

The only reliable way to serialize a value with a desired type is to request that type explicitly--as one might do to represent a large integer or very precise decimal in JavaScript or JSON, for example.

It was not. For many years it was advertised as the next version of Perl (with the intent being perhaps a Perl 5.10 release and then no more major releases with the 5 version number), then years later a "sister language", and then finally now (but not retroactively) a "completely new language in the Perl family".