chromatic

The first relevant version of compiler tools were called PGE/TGE, written in PIR and based on the notion of attribute grammars and grammar engines. The first versions of NQP grew out of those.

I believe early versions of NQP were hosted in the Parrot repo, but they started to be developed out of tree and eventually were completely hosted out of the tree.

NQP was an improvement over PGE/TGE in many ways, so some of Parrot's internal tools were created in or ported to NQP.

Eventually (I believe with NQP-rx), NQP forked into an incompatible version out of tree. As you mention, when the next incompatible revision of NQP was being planned, it was no longer an attractive target for Parrot, because it was:

  * developed out of tree
  * developed out of Parrot's release cycle
  * backwards incompatible
  * "backend independent"

I still maintain that it made little sense for Parrot to depend on an external project, evolving rapidly, offering little stability, with the express intent to obviate Parrot.

Why is the Unix command `ls` not `list-directory-contents`? Sure, it's a lot more for everyone to type all the time, but you could get rid of a single line in the man page, meaning the name is much, much more intuitive!

The same feature is available in any language with a decent FFI (must support loading an arbitrary shared library, marshalling/demarshalling data between languages, and invoking functions in the shared library).

This is possible in Python, Ruby, Java, Racket, Rust, Perl, Go, and plenty of other languages I'm forgetting or haven't used. Yet who would seriously argue that "Python is compatible with Perl" because you can embed libperl in a Python program?

You might as well argue that "Rakudo is compatible with libssl", for all the relationship Rakudo source code has with Perl source code.

This may subvert your point about the effort "most programmers" put into reading code. I think it's a superficial criticism.

Certainly, but that makes the criteria in my post much more interesting. The people in the new set are more likely to understand the features of Perl and how to look them up in the documentation or use formatting/linting tools to de-obfuscate code.

Unless the argument is that Perl as a language has some features which make it impossible for anyone to decipher, the context around any piece of code seems important to understanding it.

Seems like that argument has moved the goalposts from "most people" to "most people who use the language", and it's still not clear why that's an interesting barometer.

Even acknowledging that this is a thought experiment, what does the ability of J. Random Perl Hacker to grok a piece of random code from a domain and context with which he or she may not be familiar indicate? Surely a one-bit "is this readable" test has lost so much signal from the interesting criteria that it means very little!

That's hardly obvious to me at all. Leaving outside language syntax debates, the important readability concerns of code I deal with tend to include:

* the business domain

* the ecosystem of existing code in the organization

* the experience level of other developers

* coding standards and guidelines

* deployment and maintenance concerns

* the organizing concepts, architecture, and metaphors of the code in the small and large

* the context of where the code lives -- is it a one-off, is it structural code to get from one design to another, is it long-term code that has to meet certain criteria to be maintained for years

A random piece of code waved in front of a random person tells me nothing of interest with regard to those criteria.

Are "part-time partners" employees?

If only there were a group of people with sufficient money they never had to work! We could study them and see what they did to amuse themselves.

* it's a book for novice programmers, people with perhaps six months of practical programming experience

* it's a book for novice Perl programmers, people who don't have voluminous experience with the language itself

I believe programming is an exercise in making tradeoffs based on incomplete information. You can't teach the kind of good judgment that's based on experience, but I can try, at least, to guide novices away from some of the traps that they're likely to fall into. The subtleties of separate namespaces are difficult enough to learn on your own that it seemed worthwhile to advise strongly against name cognates.

I don't expect that Larry, Tom, Damian, or Randal follow my advice. I don't even follow it in my own code many times. It's not advice for experts.

That's the story certain people have been telling for quite a while, but it never happened while I was involved in either project. If you look at the use.perl.org archives, you can see that both Allison and I (as the architect of Parrot and a lead developer, respectively) were collaborating closely with Rakudo developers on the weekly P6 design calls.

I understand that, from the outside, there's a natural tendency to take all of the perspectives and comments and assume that the truth lies somewhere in the middle, but the historical record is out there and available. I've certainly referred to it directly when posting my opinions about what happened and when.

Not only by logical extension! One of Larry's primary goals was to "let any language use the CPAN", through Parrot. Running Perl and P6 on the same VM, in process, without embedding libperl.so was the plan as far back as I can remember.

I am talking about the focus shift that made Perl 6 just one among many of "client languages"

That's been a common, though unrealistic, criticism of Parrot for the past several years. Various contributors never had (or lost) interest in P6 but wanted to work on an multi-language VM. Expecting that all volunteers to a project have the same primary goal in mind is ridiculous and ignores decades of F/OSS contributions; it's easy to look at the Linux kernel and recognize that multiple competing business and personal interests can be shepherded into a technically useful result that meets a lot of those needs despite their competing interests.

People implementing `invokedynamic` didn't somehow make Java a second-class citizen on the JVM, for example.

You can certainly argue that we handled some of those competing interests poorly (I've argued this), but the "focus shift" argument rests on some questionable assumptions and ignores other, more important, concerns.

I think this is misleading; one of the original goals for Parrot was language interoperability, especially between Perl and P6.

They stopped running reliably several years ago and I stopped caring.

http://modernperlbooks.com/books/modern_perl_2016/01-perl-ph...

Many (but not all) of the questionable decisions in Perl come from its origins in Unix philosophy and the desire to provide a comfortable migration path for system administrators away from command-line tools such as awk and shell. Where Perl's struggled in recent years to borrow features from Rakudo, it's because those features assume a different underlying philosophy.

My impression is rather that the P6 marketing has traditionally focused on presenting a long list of features instead of a user-focused business case.

Because the marginal propensity to consume is very different between "rich" and "poor", to start.

First, Perl is installed on millions of machines by default, with full access to the CPAN--still one of the largest repositories of freely available libraries, with Perl's backwards compatibility and testing offering a lot of stability. If P6 comes out and succeeds, it'll still be quite a while before it can offer anything like that.

Second, I've given away electronic versions of the book for five years. It's not about the money or the job prospects for me. I figure the book's helped more people than I can count, so why not continue?

I have no plans to update the book to cover P6; I think it does what it needs to do as it is now.

The last time I looked at Python 3, Perl still had much better Unicode support. In particular, grapheme support in regexes, built-in casefolding, and easy normalization made a 100+ country project much easier.

The stability of the language, core libraries, and CPAN modules across major releases really helps with maintenance. Python's 2/3 break was a bummer for a lot of people for a long time that I'm glad to have (mostly) avoided.

I think that's part of the problem--there are too many post-hoc justifications for why things happened the way they did that ignore what actually happened and why people made the decisions they did.

Dan's Parrot postmortem is still accurate: there just wasn't the will to turn P6 into a real, stable, shipping product, and there wasn't the honest acknowledgement that P6 wouldn't be a realistic replacement for Perl until far too late.

https://news.ycombinator.com/item?id=8982742

(I find particular amusement in rereading Moritz's post in that thread.)

I would doubt anyone who claimed to be unbiased with his history

It's certainly possible that a mysterious GitHub error revoked my commit access late one night, but the timing seems suspicious. I'll own up to my mistakes, but the rewriting of history seems unfair.