Good project! I've been tinkering with something similar for pinball, arcade, and other coin-operated machines. Lock-in for hardware and software there is a real bummer, but managing payments and security is worth the cost.
Maybe until the 2001 O'Reilly layoffs. Tim hired Larry for about 5 years, but that was mostly working on the third edition of the Camel. A handful of other Perl luminaries worked there at the same time (Jon Orwant, Nat Torkington).
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....
Excellent point in the last paragraph. Python, JavaScript, Rust, Swift, and C# all have/had business models and business advocates in a way that Perl never did.
This is an embarrassing context to admit, but here goes.
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.
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.)
JSON::PP and Cpanel::JSON::XS don't have this problem somehow.
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.)
It's a language implementation gotcha, not really a library problem. The internal data structure used to represent values is polymorphic and uses flags to represent the types of operations performed on the represented data (numeric, string, etc).
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.
That's because it didn't work reliably. There were at least a couple of situations where Perl would have had to guess which operation you were trying to perform, so the feature was a source of potential bugs.
IIRC was by and large advertised as such from the get go
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".
AFAICT, O'Reilly's first Ruby book was "Ruby on Rails", published 2006. O'Reilly's "The Ruby Programming Language" wasn't published until 2008.
O'Reilly published Matz's Ruby in a Nutshell in 2001, but it didn't sell very well. When I worked there, I encouraged more Ruby publishing but only after I published the "Rolling with Ruby on Rails" articles (January 2005) did that argument get much traction.
The Pragmatic Programmers released their first Ruby programming book in 2000, by way of comparison (and Dave introduced me to DHH in 2004, which is how I decided to seek out the Rails articles).