Re^5: perl6 or not perl6 ...

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.

Comment on Re^5: perl6 or not perl6 ...

Replies are listed 'Best First'.
Re^6: perl6 or not perl6 ... by adrianh (Chancellor) on Mar 12, 2006 at 10:20 UTC
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]

Replies are listed 'Best First'.

Re^6: perl6 or not perl6 ...
by adrianh (Chancellor) on Mar 12, 2006 at 10:20 UTC

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]