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....

So, I guess the counterfactual line of enquiry ought to be why Perl didn't, or couldn't, or didn't want, to pivot towards stronger commercial backing, sooner.

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.

https://www.modernperlbooks.com/books/modern_perl_2016/

It helped me write a bunch of maintainable Perl code still in production.

    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.)

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.

The fact that they need to literally fortune-tell from Perl guts if something is a number or a string is telling as literally every other mainstream language including current dialects of Pascal has this problem solved. But I'm most unimpressed by the fact that merely looking at a variable will mutate its internal representation enough for there to be externally-visible effects.

It doesn't matter if JSON::XS is looking at the internals wrong, or if it's Perl's behavior at fault: from whichever angle you look at it, the whole thing is a tangled mess of wrongness.

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.)

      ~ perl -MJSON::XS -E 'my $d = {foo => 42}; say encode_json($d); $d->{foo} eq "bar"; say encode_json($d);'                                                                                                   
    {"foo":42}
    {"foo":"42"}
      ~ perl -MJSON::PP -E 'my $d = {foo => 42}; say encode_json($d); $d->{foo} eq "bar"; say encode_json($d);'
    {"foo":42}
    {"foo":42}
      ~ perl -MCpanel::JSON::XS -E 'my $d = {foo => 42}; say encode_json($d); $d->{foo} eq "bar"; say encode_json($d);'
    {"foo":42}
    {"foo":42}

However, it "works as documented" when the implicit conversion is the other way around:

      ~ perl -MCpanel::JSON::XS -E 'my $d = {foo => "42"}; say encode_json($d); $d->{foo} == 0; say encode_json($d);'
    {"foo":"42"}
    {"foo":42}

Nothing in the typelessness of the language, though, makes it necessary to flip any internal state of a variable, though, any time its usage context changes. Especially if the state is readable by public API. Even in a typeless language, the "primary" type of the thing, if it's queryable by anything at all, should intuitively be what it's being set to by assignment or other kind of explicit mutation.

https://perldoc.perl.org/perlnumber

May your tribe increase.