Sorry for answering with a certain lag, contrary to popular belief, I'm not just busy babbling around, but actually do something. ;-)

Machine generated source code is crap

For a certain definition of "crap" - yes. If your sole definition of "being crappy" is readability/maintainability, then you are right. In this limited context. If you extend this view by e.g. "performance", "development time", you get different - if not contrary results.

Normally, maintainability of computer generated code is waived, because it's ... COMPUTER GENERATED ... and should be easily generated again if required. E.g. after your input data have changed, or you improved/fixed your generator/converter.

What we could talk about would be if the effort writing a Perl5 to Perl6 converter would outweigh the effort writing the 100 to 500 useful CPAN modules from the start. Plus of course the unknown number of bits and pieces of Perl5 code out there people would like to be able to migrate with low cost (think ROI).

So I'll restate my opinion in more specific terms: machine generated source code intended for human consumption, understanding and maintenance ... is not yet within the capabilities of programming to make a descent fist of.

I never stated that maintainability, readability would be an a priori requirement or concern of such a code. My point was (besides making clear that this converter is feasible), that this converter would give Perl6 adopters in spe with the generated code at least a quick, low/no cost migration path. I mean hey, what if it would convert that legacy Perl5 library no one ever wanted to touch and it would work? Albeit being still unreadable/unmaintainable? I see no loss there only gain.

It isn't going to happen any time soon. It would (will?) be just another side project that will go nowhere and ultimately be a waste of resources that would be better served by assisting the Perl6 team getting a Perl6 compiler & VM working. Sorry, but that is my conclusion. (Note: What you and others do with your time is none of my business.)

Well, I'm not surprised. Because you start from the wrong assumptions, then make right deductions, you still end up with the wrong conclusions. Without thinking more on the transition cost and being fixated on the "base technology", you are basically the prototype of the "pack of the hopeless" who actually do have hope to pull (or push?) Perl6 one fine day to a state where it will be happily adopted. I hate to crush motivations (you can easily escape that by positioning my opinion as invalid), but under these circumstances and with this mindset, the Perl6 project will fail.

What's even worse, you see a resource clash where there is none. People writing such a converter (actually the only thing I'm not sure about is if it should be written in Perl6 or Perl5) are not necessarily the people working on the VM and the compiler.

Sorry, but yes. It *IS* technicians that drive the adoption of programming languages.

:-D Sorry but no, this is what technicians tend to think. Technicians are responsible for the first 1% of the bootstrap process of a new technology. Building up the bare foundations. Almost everything else is actually not driven(!) by these people. Only modified.

But, if GO is so good, why do they need Dart? And if Dart is so much better; how long will GO persist?

Ehm... Go is being used at Google in production systems, Go and Dart target different application areas. While Go tries to be Googles C, Dart tries to replace JavaScript for good. I am not that interested in Go, because that is a real self-purpose language for Google, but I suspect Google has the power to push JavaScript with Dart out of the way. And THAT is an undertaking one should learn from. Also, because this process will take some time, it leaves opportunities for others. (hint hint)

Actually there is not much to comment for the rest of your post, because you virtually paraphrase my statements. (Evolution vs. "Revolution"?) But somehow indicate you do not see reason for Perl6 development to act accordingly. That puzzles me, but let's leave it as is.

Regarding Perl6 development, I have great respect for the people doing it. Very bright minds, doing bleeding edge technology. However, from the viewpoint of "regular" software development, the Perl6 project shows all signs of a failing software project. One of the most important signs is the self-delusion acompanying the development. You hear clearly wrong statements regarding as WHY it was started at all, you see clearly wrong priorities and adoption assumptions/hopes.

I can admit, I didn't contribute more to Perl6 than just installing it and trying it out here and there. Giving it my time and evaluating it. Attending - more often than not - disturbing talks when it was presented in the past 8 or 9 years. I do have the audio of the original "State of the Onion" speech from Larry Wall when he announced it - including drums.

For me, 42years old, 16years Perl, managing a company of ~70, mainly Perldevs, loving Perl, thinking it deserves better than it has now, being INTJ, pedantic, paranoid and what not ... it simply hurts, because it has now been 12 long years. It may take another 12 years until someone (with definite authority on that matter) says: "project failed". All that time and effort spent in it could be wasted. Maybe not all, threaded Parrot could happily live as a Perl5.80 or Python7 foundation, but I do not want to elaborate on that until we don't have a threaded Parrot.

You know what I heard in a talk about Perl6 - held by a Perl6 protagonist - at the GPW2013? "The biggest killer feature of Perl6 ... (grammar) ... may be the unique sales point for that language - which eventually may not even be Perl6 by then."

So

Good luck.

Thank you, the same to you! Actually I think the Perl6 troppers will need more of it than me, so fingers crossed, four-leaf clover, pigs and what not.