Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-release, 2016-01-15

| Channels | #perl6-release index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:48 ilbot3 joined #perl6-release
02:48 Topic for #perl6-release is now »r̈« - Discussions about Perl 6 and Rakudo release strategies - http://irclog.perlgeek.de/perl6-release/today
09:03 FROGGS joined #perl6-release
09:50 _Gustaf_ joined #perl6-release
11:29 ZoffixWin joined #perl6-release
11:32 ZoffixWin Just dropping a link to this Issue https://github.com/perl6/user-experience/issues/4  I think once we finalize all the versioning decisions and such, we could even create a nice diagram explaining the relationship between all the bits and pieces
12:09 FROGGS joined #perl6-release
12:38 nine On the issue of NativeCall (and Test) versions: we could ship and install _all_ versions of those bundled modules. Maybe we can even do the NativeCall:ver<6.d> is NativeCall:ver<6.c> trick, if we're gonna do that for the setting.
14:14 ZoffixW joined #perl6-release
14:18 ZoffixW Was reading the logs a bit and wanted to add two cents on the whole "use v6.whatever" requirement. It needs to be possible for a developer to specify a Perl 6 version "globally". For example, with use v6.whatever in their main script and NOT having to do so in any of the modules included by that script. In Perl 5, it's absolute nightmare that you have to specify things like use strict; use warnings; use 5.20; use experimental 'postderef'; in
14:18 ZoffixW EVERY damned class when you're developing an app.
14:19 ZoffixW My most hated thing about Perl 5 is having to include a `use` just to have "say" function available. I really hope Perl 6 doesn't go down the same path.
14:23 nine I could imagine using the "perl" field from the META6.json and apply it to all comp units loaded from that dist. Same as I plan on doing with the "version" field.
14:24 ZoffixW I'd really like to see the backwards compatibility issue to be addressable more with something like making it easy to "bundle" Perl 6 itself with a program, rather than to bend over backwards to have brand new and shiny Perl 6 be held back just so a program from 10 years ago can still run on it. It could even be done with the `use v6.whatever` mechanism: if it's absent, it means my program was written for the latest, greatest, and shiniest Pe
14:24 ZoffixW rl 6 with all its bells and whistles. If someone wants an older version of Perl 6, they have to put a `use v6.whatever` in their program to get that version.
14:25 nine You will probably want to develop against the current version anyway, so not having this in a -Ilib situation shouldn't be that much of an issue.
14:26 nine ZoffixW: how does a bundled Perl 6 program help me with our quarter million LOC application that just happens to need a 10 year old library written for Perl 6.e?
14:28 ZoffixW Is Perl 6.e supposed to be brand new in that scenario?
14:28 nine no, 10 years old
14:28 nine Our application is written in Perl 6.n at that point
14:32 PerlJam nine: that's where "use Inline::Perl6:ver<6.e>" comes in handy  ;)
14:33 ZoffixW nine, ok, I see the problem with the bundling thing
14:34 nine It's exactly the scenario we live at work btw :) Luckily Perl 5 is backwards compatible enough that we can really use CPAN modules from 2003. But even there with every new Perl 5 version, there's some deprecation or breakage in some of our 100s of dependencies
19:26 TimToady joined #perl6-release
19:27 TimToady joined #perl6-release

| Channels | #perl6-release index | Today | | Search | Google Search | Plain-Text | summary