chromatic

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.

I wrote the book Modern Perl by hand, and it's accurate and freely available. I wonder how much of the linked book relies on what I already wrote:

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

I prefer Perl's approach for both:

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

I'm not aware of any published books yet, but I'd like to publish a 5th edition of Modern Perl sometime, and it will include the native object model.

That's fair; I appreciate it.

If there's more than "good editing often improves writing" I didn't see it in the essay.

Your understanding is mostly accurate.

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.

I am. I released a new version of the Modern-Perl library a couple of weeks ago (apropos of this story).

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

someone correct me if I'm wrong but this would apply to well known interpreted languages like Perl 5

Perl uses the same execution method you describe for cPython.

Slashdot and its associated Everything2 site were written in Perl

That really takes me back!

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

You're right, that's exactly what I meant!

I'm surprised there's no example in perlre(1); perhaps I can get that corrected.

No need to copy and then replace:

  my $a =  'Perl';
  my $b =~ s/pe/ea/ir;

This is untrue.

Rakudo on Parrot was slow. If you happened to use a Unicode character in your source file it got dog-slow.

Worse yet, Unicode was an optional feature of Parrot! WTF!!

This is nonsense, and I say that as the person who spent months profiling Rakudo to figure out why it was slow.

Rakudo's parser was (maybe still is) slow because it can't optimize anything, even the <ws> token.

Adding NFG could have helped by allowing fixed-width access to normalized codepoints, but IIRC Patrick told the person who was going to implement NFG not to do it.

Seems like a pattern.

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.

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.

Parrot and Perl 6 diverged

To me this reads like the "mistakes were made" phrasing used when someone wants to be technically accurate but not say anything meaningful.

Regardless of whatever Raku developers and advocates say, I, as a lead developer of Parrot, went out of my way to make it work better for P6. Patrick asked me not to do certain things and so I didn't do those things.

Maybe that was my mistake.

But it's categorically untrue that Parrot wanted to get rid of P6 or considered P6 an afterthought or wasn't willing and able to be receptive to P6's needs, and I'm disappointed that that untruth continues to persist.

If Parrot had provided all that Perl 6 needed at that time, I don't think the multiple backend strategy would have been selected. Why would one?

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.

Also, had Parrot been able to attract other languages to a significant extent, the abandoning of Parrot by Perl 6 would not have been an issue.

You haven't addressed my point that NQP yanking the rug out from most other languages running on Parrot harmed Parrot. That seems like a material concern.

it didn't have a core team welcoming enough to keep anybody vaguely interested in Parrot

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.

The first thing is that Rakudo began technically shifting to a multiple backend architecture in mid 2009

Weird how almost nothing Patrick talked about in that talk panned out -- no JVM backend, no CLR backend (the one that Jonathan talked about in that blog post too), no JavaScript backend, no Tcl, no Perl, no Ruby, no Python frontends.

In fact, it's amazing how that fourth rewrite of NQP ended up not working at all for any of the backends Patrick showed on his slide. Or at least not working yet.

the record shows, commits to Parrot "fell off a cliff" in early 2011, about 6 months after Rakudo Star

How strange that that happened just after the developer summit where I said that the NQP strategy was going to leave Parrot developers in a dead end. Imagine that -- people don't want to stick around on a project that's continually undercut by bad technical decisions.

Thanks for finally confirming what I've been saying for years.

That was my era too, but it's definitely true that Dan lost interest in P6 well before he stepped down, and Leo never seemed to have a specific interest in P6.

I just know second-hand that something broke the trust between the Perl 6 and Parrot developers around the first Rakudo Star release. And that strengthened the notion that another backend for Perl 6 was needed.

If I recall correctly, that's about the time Jonathan started complaining that the Parrot object model didn't work very well for P6 and wrote his own for PCT, which is still weird to me because he was the primary implementer of the Parrot object model in Parrot. (I don't remember the dates, but he also wrote an object model in C# and another in Java, which you mentioned in another comment.)

I tried for a long time to migrate the PCT object model back into Parrot, but both Jonathan and Patrick told me repeatedly it wasn't a priority, so I stopped offering.

I'm not the only person who had this experience; I remember someone else having a similar experience with Unicode support.

OOC, which official hagiography are you referring to?

The one that says "Parrot dumped P6, so the P6 developers had no choice but to write their own VM".

I was there. That's not true at all.

Parrot was always intended to support multiple languages, from Simon's original April Fools joke to Larry's dual desire to run both P6 and Perl in the same process on the same VM as well as to make CPAN available to all dynamic languages in the same process on the same VM.

That's why Dan and Guido had a bet that Parrot would run Python faster than CPython, and that's why Parrot attracted contributors like Sam Ruby.

It's definitely true that, as P6 dragged on and burned out a lot of contributors (including multiple project managers), many Parrot contributors thought that coupling Parrot's success to P6 was a mistake, but I can't see that as a change in focus because the multi-language focus was a goal from the start.

Granted, Parrot did wander in the wilderness for a while waiting for the P6 design process to proceed, and Parrot did evolve in some unfortunate directions because of that. The rest of this comment covers 2007 onwards though.

Your question about components is particularly interesting, because of what really happened.

A couple of P6 developers wrote PCT, a set of tools and libraries to make developing compilers and languages on Parrot easier. This was a good thing, and Parrot users and developers started migrating their language implementations to that toolkit.

The PCT developers refactored and revised this a couple of times, and to make that easier, eventually they took the code out of the Parrot tree and started syncing PCT into the Parrot tree on a semi-regular basis.

I was working with them weekly to fix Parrot bugs, improve Parrot performance, and add Parrot features to reduce the amount of code necessary in PCT. Thus it's difficult for me to believe that the Parrot developers were designing and implementing Parrot away from P6.

Toward the end of 2010, the P6/PCT developers said they were going to rewrite PCT to support multiple VM backends. I argued this would create a lot of churn in the language implementations actively using PCT (ironic, because the PCT developers spent a lot of time before and after this complaining bitterly that they couldn't keep up with Parrot churn) and would provide very little value for Parrot (PCT was out of tree already, and syncing in code designed explicitly to undercut Parrot seemed like a stupid idea). These discussions all took place in the public Parrot IRC planning sessions, which were logged.

I also had concerns about yet another rewrite undercutting P6, especially coming six months after the underwhelming Rakudo Star release, but it was clear which direction the winds were blowing, and that's when I stopped working on both P6 and Parrot.

Five years later, P6 had its first official release and Parrot was well buried.

I know this contradicts the official Raku hagiography, but I've gone back and read the primary sources a few times over the years as people have asked about it, and I'm confident the record backs up what I've said.

I recall things differently! The leaders of the Parrot VM and the leaders of the P6 implementation and the P6 language designers were on the phone directly every week talking through things.

Up until we weren't, but that was basically the point where the P6 language designers said they wanted to write their own VM anyway.