in reply to Re^3: perl6 or not perl6 ...
in thread perl6 or not perl6 ...

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.

Replies are listed 'Best First'.
Re^5: perl6 or not perl6 ...
by Juerd (Abbot) on Mar 11, 2006 at 15:38 UTC

    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' }

[reply]
Re^5: perl6 or not perl6 ...
by Aristotle (Chancellor) on Mar 12, 2006 at 03:34 UTC

    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.

[reply]
      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 :-)

[reply]

In Section Meditations