What counts is that idiomatic Perl 5 is very different from idiomatic Perl 4 in architecture, whereas idiomatic Perl 6 won’t be nearly as different from idiomatic Perl 5

Really? Many of the (already frowned upon) idioms are abstracted into functions or operators. This takes away a lot of the (in)famous line noise.

Perl 6 does not really reform the way systems written in Perl are to be architectured

Really? Of course, you can still use the same architectures you used in Perl 5 (as you can still use the architectures you used in Perl 4), but there's a wealth of new paradigms entering the language, with roles hopefully shifting around the idiomatic OO landscape forever. That's just one example, but there are many more architectural possibilities new in Perl 6. Many of which go further than the addition of references, namespaces and lexical variables. (It's not entirely accidental that I name three features that PHP does not have. People manage to use PHP and Perl in much the same way, while PHP lacks these things. Try, to use roles, hyperoperators, or environmental variables, in Perl 5 or PHP...)

but in spirit, Perl 6 is much closer to Perl 5 than Perl 5 is to Perl 4.

Agreed, but then, so is Ruby, which is fortunately not called Perl.

The OO stuff is what I precisely was referring to when I said Perl 6 will just make things a whole lot easier to build by providing default mechanisms that would have to be built manually Perl 5. Class::C3, Class::Trait, NEXT: all built in or easy to achieve, and more powerful and flexible. But you do have all of those in Perl 5 in some form – it just takes way more effort, which most people are unwilling to expend (hardly surprising).

Really, if you think the Perl 6 we have now should have been called something other than Perl 6, then what kind of language should have been called Perl 6?

Makeshifts last the longest.

Really, if you think the Perl 6 we have now should have been called something other than Perl 6, then what kind of language should have been called Perl 6?

That's a very interesting one, but only answer I can honestly give is that Perl's time is up. It has been for a few years. Perl 6 could be a rewrite of Perl 5 with some extra features, for those fanatics who keep using the language.

Update: Wrote that when I was in a bad mood. I probably shouldn't have written it, even though it does reflect how I often feel about Perl.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

What counts is that idiomatic Perl 5 is very different from idiomatic Perl 4 in architecture, whereas idiomatic Perl 6 won’t be nearly as different from idiomatic Perl 5, at least in everyday code that does not strain against the limitations of Perl 5 too hard.

Do we know enough about Perl 6 code to say what's going to be idiomatic or not?

Perl 6 does not really reform the way systems written in Perl are to be architectured, it just makes these architectures easier to implement by putting various and sundry premanufactured, well-designed nuts and bolts into the language, so you don’t have to spend so much time building them all yourself.

I wonder if we'll see an equivalent of the the "people writing C in C++" problem in Perl 6. While there isn't a huge amount in Perl 6 that's impossible in Perl 5, there are certainly a lot of things that are much easier - including things that are fairly marginal in the Perl 5 world like roles, design by contract, etc.

Combine this with things like macros that don't have any Perl 5 equivalent then I suspect (hope indeed) that Perl 6 solutions are going to be as different from Perl 5 ones as the Perl 5 ones were from Perl 4.

Do we know enough about Perl 6 code to say what's going to be idiomatic or not?

I think the 42_000+ lines of existing Perl 6 code are a nice show case, showing that even without working roles support, idiomatic Perl is already different. This is an old count of Pugs' tests and examples, and doesn't include the brand new lrep engine yet.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Note that I was talking about architecture, not individual constructs. Those will indubitably change dramatically. But Perl 6 does not introduce new data structures. In accordance with the famous Show me your tables and conceal your flowcharts qoutation, I believe P6 code won’t be architected in fundamentally different ways from P5 code. If, say, Perl 6 was to introduce a tree data type alongside scalars, hashes, arrays and functions, then I could see how things could drastically shift around. Compare to how Perl 4 has no references, which means that the architecture (architecture, not syntactical expression) of an ideal Perl 4 solution is very, very different from an ideal Perl 5 one.

Makeshifts last the longest.

But Perl 6 does not introduce new data structures

Well, apart from P6opaque, properties, classes (as first class objects), rules, continuations, Complex, Bit, arbitrary precision float/integer types, Rat, Inf, NaN, Signatures, packages (as first class objects), modules, grammars, lazy lists, control exception, tokens, Bool, polymorphic types, structs, Junctions, Enums, ...

Not following Perl 6 development in detail some of these might be wrong, but I've probably missed some too :-)

At to be honest - with my Lispish code-is-data hat on you can look at traits, macros, types/roles as data instead of code too.

In accordance with the famous Show me your tables and conceal your flowcharts qoutation, I believe P6 code won’t be architected in fundamentally different ways from P5 code. If, say, Perl 6 was to introduce a tree data type alongside scalars, hashes, arrays and functions, then I could see how things could drastically shift around.

Let me pick two examples.

I know that if I start developing in Perl 6 that I'm likely to take advantage of the new OO frameworks ability to do multiple dispatch when I think that it would make things simpler. In Perl 5 I'd probably do double (triple, whatever) dispatch instead. To me that's a fairly large architectural difference.

Now that I have grammars/rules and can extend the Perl language itself I'm much more likely to build Domain Specific Languages on top of Perl (so that they're really just Perl with extra syntax) rather than with Perl (where Perl just parses and interprets a completely separate language.) To me that's a very large architectural change.

As ever YMMV :-)