chromatic

Does it count as a trick question if I implemented it?

I believe it is:

https://pragprog.com/cart/add/skus?sku_id=821_820

I'm not confident about the correct "buy" link to use to properly support the book.

It's more valuable to me if you share and enjoy. I give away electronic versions so that it's useful, not to make money from the time I spent writing it.

I found a code-typo on the CPAN website

Is this the page you were reading?

https://cpan.metacpan.org/modules/INSTALL.html

It's not explained on that page, but the distribution App::cpanminus installs a program called cpanm, not cpanminus (as one would expect).

I don't see how it can be designed well enough. The fundamental problem is that Perl operators are monomorphic and variables are polymorphic. This was the same problem for things like keys and each on references, for example.

Not even if their marginal propensity to consume is high?

I think that's a mistake; it's important to call out bad actions and bad actors.

Another person made an important point elsewhere. If someone had posted a similar manifesto for the Apache Software Foundation -- without doing any community work or collaboration -- then the ASF would respond quickly and definitively.

I'm just certain sure his slaves felt the same way. Especially Ona Judge.

CPAN doesn't do that, because CPAN is a series of mirrors that neither collect nor report aggregate download numbers.

They're both extremely knowledgeable, but neither of them can work with other people, so their forks seem motivated by the desire to do what they want without question, rather than any purely technical concerns.

How odd then that ~90% of the discussions about ditching Parrot were primarily complaining about the deprecation policy and first-class Rakudo support, not speed.

I suppose you would know better though, being objectively smarter than everyone else who ever made a decision about the project. How unfortunate that we can't take your word for it; we can only read all of the public discussion about it.

It's the laziest explanation.

Did you ever ask yourself why, for example, all of the calling convention code paths were consolidated into a single code path? It wasn't to make a single, inefficient code path as you claim.

It was to provide a gradual transition for clients to a better designed calling convention system which could then be optimized for actual client uses.

The goal was never to create the fastest possible VM at every single point in time. That's where I think you never understood the goal of the project, and that's where I think you've never understood the goal of p5p.

The goal was to make something that works, continues to work, and can be improved while continuing to work. That's why you're no longer welcome in p5p -- because your goals and your actions are incompatible with that.

I wish you understood this. You're very smart and very talented and you have a lot to offer, if you can get out of your own way and accept that people who don't share your exact goals in the exact same way aren't irredeemably stupid.

Reini, it seems like you think everyone who disagrees with you is stupid. This isn't an explanation for anything.

We were boxed in for two really good not-primarily-technical reasons:

* we had users we didn't want to abandon or cause churn * we had architectural decisions we had to improve

Now I know I'm not as smart or as experienced or as knowledgeable as you are, but that doesn't mean I'm a drooling buffoon, and it certainly doesn't mean I don't have good reasons. Sometimes it means I make mistakes. Sometimes they're not even mistakes; sometimes they're just differences of opinion.

This was, initially, for two reasons:

* allow Perl 5 code to run in process with Perl 6 code (without linking in libperl) * provide a unified VM on which Perl 5.12 could become Perl 6

That's every license. You might be thinking of a contract, which is a binding agreement between two parties.

Think of a license as a grant of certain rights to the licensee. There's no binding agreement upon the licenser.

(Not an HN lawyer.)

I endorse this point of view, from hard-won experience.

(Also: memory model. Always memory model.)

The issue is whether P6 advocates are honest in their advocacy. Pretending that the goal was always to create a sister language or that the intent from the start was always to take 15+ years to release a stable version or that the intent was always to define P6 as a specification and test suite or that a cross-platform VM wasn't a goal from the start is dishonest.

If you're going to quote Larry Wall from 2000, be honest and also quote him as saying he wanted to release a beta by TPC 2001 and get the final version out by 2002. Don't mislead people by cherry-picking quotes out of context to gaslight them.

That is, assuming you want to be an honest, good faith advocate.

You should. It's a perfectly valid exception handling mechanism. It's unfortunate that the name "eval" is overloaded for two separate behaviors:

  * catch exceptions thrown as strings or objects

  * compile and execute code from a string

Good news! Every version is freely available online. Here's the most recent:

http://modernperlbooks.com/books/modern_perl_2016/index.html

Yes, that was an original project goal. You can see this as far back as Larry's State of the Onion 2003:

https://www.perl.com/pub/2003/07/16/soto2003.html/

... the "Parrot: Some Assembly Required" article written by Simon Cozens in September 2001:

https://www.perl.com/pub/2001/09/18/parrot.html/

... or, if you trust Git commits rather than articles which could have been edited in the meantime, the same article revised as introductory docs in the Parrot repository in December 2001:

https://github.com/parrot/parrot/blob/9bc8687beb5180e4cc8971...

I think that's overstating things. He reported a "vulnerability" in Bugzilla which wasn't a security problem in Bugzilla because Bugzilla uses taint, which didn't do any database injection like he claimed, and which is unrelated to CGI.pm becaues Bugzilla doesn't use CGI.pm:

https://bugzilla.mozilla.org/show_bug.cgi?id=1230932

Furthermore, the examples in his presentation don't actually work, he relies on ignorance of lists and Perl data structures, and the one potentially interesting point he makes about calling functions in list context in hash initializers has been documented well understood as a potential mishap in web applications since 2000:

https://events.ccc.de/congress/2014/Fahrplan/system/attachme...

His presentation may have some value to someone spending their first week with Perl in a web context, but that person would have to wade through a lot of nonsense to get at that value.

Are they? Or are you defining "productive" circularly here?

If I'm wealthy and I invest in derivatives or complicated tranches, is that "productive" because it's enabling further circulation of money, or is it "productive" because I can gain more capital on it?

Given that there's an infinite supply of ever more derived tranches, I suspect that my definition of "productive" different from yours here.

As a shareholder, because that money could be put to productive use today, rather than waiting for a future which may not come. To my mind, that's why the pressure for Apple to pay a dividend finally built up to the point that Apple now pays dividends.

(Still an honest question. I've never understood this about the Austrian school.)

Honest question -- how does the Austrian school reconcile the slow growth of the US economy during and immediately after QE with enormous corporate warchests such as Apple's cash stockpile?

I'll accept that some of this is tax shenanigans to defer US repatriation... but only some of it.

The economic principle you're looking for is "velocity of money". If you think of a GDP in terms of a multiplier in how often/fast money circulates, then you can analyze whether investment or spending is more important.

The second economic principle to look into after that is "marginal propensity to consume".