chromatic

That's the second most disappointing part. The Parrot developers had a strong push between two and three years ago to redesign the internals to be a better fit for Rakudo along these lines (better runcore, easier JITting, improvements to the core object model, representation polymorphism), but the reaction from the Rakudo developers was a mixture of "No, thank you!", "Not yet.", and "If you have to, but don't change any APIs or behavior that Rakudo counts on."

It's a shame this couldn't have all been done at the same time. The available volunteer knowledge and interest might have saved two or three years of Perl 6 floundering around in the netherworld of big promises and very modest realities.

The most disappointing part is realizing that this sets back the potential delivery date of a usable Perl 6 by at least another couple of years. I guess that shouldn't be a surprise by now though.

That's irrelevant in this case, because a hypothetical Perl 5 JIT wouldn't do much until the Perl 5 parser finished parsing its code. Remember, all this proof proves is that you cannot produce a single, unambiguous parse tree from every Perl 5 source file because of the syntactic construct that lets you change how the parser works for specific symbols.

Perl's access control model uses a metaphor of polite permission. Without hardware enforcing memory protection, any memory protection at the language level is a modest barrier for the determined anyhow.

To my knowledge, Rakudo hasn't reached the point where its developers call any Star (runtime plus libraries) release a "major release" of the sort that users ought to use in the wild for a year or more.

... except for "easy to deploy", which is a merit.

"Select random number from MySQL"? I'd like to see the stochastic control for that one.

The lack of any usable Perl 6 implementation by the time of Perl 5.12 did more to promote the continuation of Perl 5 as its own project than any specific rejection of Perl 6. When the plan was for Perl 6 to replace Perl 5, the idea that Perl 5.12 would migrate to Parrot as a VM so that Perl 5 and Perl 6 code could run in the same process.

I’ve recently had the opportunity to help a wildly successful startup, in a domain that sorely needs the advantages of modern tech. Perl is the right tool for the job. If I explained the problem space you’d agree, even if Perl isn’t your favorite language. Perl is the right tool for a lot of jobs, all over the world, right now, stable and reliable, in production, with massive numbers of lines of code.

I can confirm everything she wrote about that startup.

Imagine that a tech book breaks even (for the publisher) at 5000 copies sold. Further imagine that a successful book sells about 8000 copies. At a $30 cover price, the author gets $1.50 per copy sold, so 8000 copies is $12,000.

Also remember that the publisher probably gets paid 30 days after the close of the month in which a sale occurred, and the author gets paid at least a month after that--and more, if the publisher holds back royalties in case of returns. If you're fortunate, you get paid monthly. You probably get paid quarterly.

Pugs ended up succeeding in the sense that it produced that test suite, but it didn't succeed in that it relied on Audrey's presence--it never attracted a sufficient developer base to maintain it when she wasn't available.

Rakudo isn't anywhere near complete now, almost seven years later, and I believe Pugs passes no more than 30% of Rakudo's test suite.

It might be fair to say that the goalposts have moved in the intervening time, however.

Yes, in part because it's taken so long and delivered so little and in part because Perl 5's core development picked back up again a few years ago (and the CPAN never stopped improving).

Is the Perl 6 language a dead end or are people enthusiastically working on using it for production systems?

The intent of the people working on it is to produce something which will eventually be usable for serious projects, but no one can give a good prediction as to when that will happen.

I wrote a book called Modern Perl. It's freely available in electronic formats:

http://onyxneon.com/books/modern_perl

(Rails does deserve credit for promoting "convention over configuration" as a design concept, but plenty of us were doing similar things years earlier.)

It's in great demand at one of my clients, but I can't even mention the name of the business entity for contractual reasons.

Python and Ruby have parametric roles/traits? Typed attributes with coercions?

... except for a type system based on the memory model of a machine which strongly resembles the PDP-11, a compilation strategy built for machines with less RAM than my car fob, and optimization possibilities limited by aliasing, plus everything kscaldef mentioned.

That reads like a false dilemma to me. Surely there's some wonderful excluded middle between "I write code that someone who doesn't know the language can read it" and "I write code so opaque that you need a language specification, a flashlight, and both hands to begin to comprehend it."

I, for example, try to write code, tests, and documentation that a decent developer with a working knowledge of the language and an understanding of the problem domain can figure out what's going on and why. I don't care if someone's nephew or niece who's never programmed before can make heads or tails of the code because I think that's a tremendously silly goal counterproductive to any good business sense.

(Also I've never seen a language which can enforce things like effective factoring, intelligible naming, coherent coupling and decoupling, intelligent encapsulation, and the like. Certainly Python doesn't enforce those.)

Yes, but why do you care if people who don't understand a language can or cannot read code written in that language?

This is an honest question: why would you care about that? What does it matter if someone who doesn't know a language (or isn't bothering to learn it) can read code written in that language?

Python sort of forces that on you up-front.

How? Indentation doesn't really matter and, for example, list comprehensions aren't all that obvious to someone who's never seen them before. I can understand "I think sigils might be confusing", but that's such a superficial aspect of programming I'm inclined to dismiss it as such.

Everyone's using Smalltalk now? Consistency seems to be overrated; most of the popular languages these days seem to be multi-paradigmatic.

I don't believe Python is that inflexible (it's not), and I don't see how the limited and superficial ways in which Python pushes all code to look the same are really that meaningful.

What do you mean by "readable" and how does Python seem to enforce that?