Re: Backwards compatibility and release 1.0

2015-10-15 Thread Smylers
Moritz Lenz writes:

> On 10/13/2015 10:52 AM, Richard Hainsworth wrote:
> 
> > Following on the :D not :D thread, something odd stuck out.
> > 
> > On 10/13/2015 03:17 PM, Moritz Lenz wrote:
> > >
> > > We have 390+ modules, and hand-waving away all trouble of
> > > maintaining them seems a bit lofty.
> > 
> > Surely, the idea of keeping the release number below 1.0 is to warn
> > early adopter developers that code is subject to change and thus in
> > need of maintenance?
> 
> ... a large percentage of the module updates are done by group of
> maybe five to a dozen volunteers. ... 5 people updating 70% of 390
> modules. Modules they are usually not all that familiar with, and
> usually don't have direct access. So they need to go through the pull
> request dance, waiting for reaction from the maintainer. In short, it
> sucks.

Thanks for the explanation, Moritz. That does make sense.

I'm still a _little_ uneasy because that sounds a bit like the
explanation of why Makefiles have to use tab characters:

  I just did something simple with the pattern newline-tab. It worked,
  it stayed. And then a few weeks later I had a user population of about
  a dozen, most of them friends, and I didn't want to screw up my
  embedded base. The rest, sadly, is history.
  
— Stuart Feldman http://stackoverflow.com/a/1765566/1366011

Though the important difference is that invisible whitespace characters
that some editors don't even let you type are particularly
beginner-hostile, whereas allowing undef arguments where they don't make
sense (and hence where callers don't generally try supplying undef) is
something that many Perl 5 programs have been doing for years with no
widespread harm.

Cheers

Smylers
-- 
http://twitter.com/Smylers2


Re: Backwards compatibility and release 1.0

2015-10-15 Thread Tobias Leich


Am 15.10.2015 um 10:47 schrieb Smylers:
> Moritz Lenz writes:
>
>> On 10/13/2015 10:52 AM, Richard Hainsworth wrote:
>>
>>> Following on the :D not :D thread, something odd stuck out.
>>>
>>> On 10/13/2015 03:17 PM, Moritz Lenz wrote:
 We have 390+ modules, and hand-waving away all trouble of
 maintaining them seems a bit lofty.
>>> Surely, the idea of keeping the release number below 1.0 is to warn
>>> early adopter developers that code is subject to change and thus in
>>> need of maintenance?
>> ... a large percentage of the module updates are done by group of
>> maybe five to a dozen volunteers. ... 5 people updating 70% of 390
>> modules. Modules they are usually not all that familiar with, and
>> usually don't have direct access. So they need to go through the pull
>> request dance, waiting for reaction from the maintainer. In short, it
>> sucks.
> Thanks for the explanation, Moritz. That does make sense.
>
> I'm still a _little_ uneasy because that sounds a bit like the
> explanation of why Makefiles have to use tab characters:
>
>   I just did something simple with the pattern newline-tab. It worked,
>   it stayed. And then a few weeks later I had a user population of about
>   a dozen, most of them friends, and I didn't want to screw up my
>   embedded base. The rest, sadly, is history.
>   
> — Stuart Feldman http://stackoverflow.com/a/1765566/1366011
>
> Though the important difference is that invisible whitespace characters
> that some editors don't even let you type are particularly
> beginner-hostile, whereas allowing undef arguments where they don't make
> sense (and hence where callers don't generally try supplying undef) is
> something that many Perl 5 programs have been doing for years with no
> widespread harm.
>
> Cheers
>
> Smylers
Btw, In my opinion the current model about :D etc is very correct. I
don't see any need to change the
defaults as how type objects or their definedness is implementet.
Changing for example the params
to mean Int:D by default when one writes Int is something you have to
explain a lot. And in fact it is a lie.
There are some basic rules about Perl 6 like TIMTOWTDI and DRY, but
there is also a rule about "All is
fair if you predeclare". But if I don't predeclare that I mean Int:D by
writing Int, then the compiler is
not allowed to change the meaning of what I wrote.

That said, if there was a change that justifies breaking a lot of stuff,
I'm for it. But here it is certainly
not the case.

--
Tobias


Re: Backwards compatibility and release 1.0

2015-10-15 Thread Elizabeth Mattijsen

> On 15 Oct 2015, at 11:06, Tobias Leich  wrote:
> Am 15.10.2015 um 10:47 schrieb Smylers:
>> Moritz Lenz writes:
>> 
>>> On 10/13/2015 10:52 AM, Richard Hainsworth wrote:
>>> 
 Following on the :D not :D thread, something odd stuck out.
 
 On 10/13/2015 03:17 PM, Moritz Lenz wrote:
> We have 390+ modules, and hand-waving away all trouble of
> maintaining them seems a bit lofty.
 Surely, the idea of keeping the release number below 1.0 is to warn
 early adopter developers that code is subject to change and thus in
 need of maintenance?
>>> ... a large percentage of the module updates are done by group of
>>> maybe five to a dozen volunteers. ... 5 people updating 70% of 390
>>> modules. Modules they are usually not all that familiar with, and
>>> usually don't have direct access. So they need to go through the pull
>>> request dance, waiting for reaction from the maintainer. In short, it
>>> sucks.
>> Thanks for the explanation, Moritz. That does make sense.
>> 
>> I'm still a _little_ uneasy because that sounds a bit like the
>> explanation of why Makefiles have to use tab characters:
>> 
>>  I just did something simple with the pattern newline-tab. It worked,
>>  it stayed. And then a few weeks later I had a user population of about
>>  a dozen, most of them friends, and I didn't want to screw up my
>>  embedded base. The rest, sadly, is history.
>> 
>>— Stuart Feldman http://stackoverflow.com/a/1765566/1366011
>> 
>> Though the important difference is that invisible whitespace characters
>> that some editors don't even let you type are particularly
>> beginner-hostile, whereas allowing undef arguments where they don't make
>> sense (and hence where callers don't generally try supplying undef) is
>> something that many Perl 5 programs have been doing for years with no
>> widespread harm.
>> 
>> Cheers
>> 
>> Smylers
> Btw, In my opinion the current model about :D etc is very correct. I
> don't see any need to change the
> defaults as how type objects or their definedness is implementet.
> Changing for example the params
> to mean Int:D by default when one writes Int is something you have to
> explain a lot. And in fact it is a lie.
> There are some basic rules about Perl 6 like TIMTOWTDI and DRY, but
> there is also a rule about "All is
> fair if you predeclare". But if I don't predeclare that I mean Int:D by
> writing Int, then the compiler is
> not allowed to change the meaning of what I wrote.

FWIW, I’m with FROGGS on this.

Because Perl 6 has gradual typing.  Going automatically from Int to Int:D, 
doesn’t feel gradual for me.  If you want this behaviour in your code, it is as 
easy as adding a:

  use variables :D;

at the top of the scope of your code, and then you’re set.  I admit it feels a 
*little* like the “use strict” boilerplate of Perl 5.  On the other hand, I 
think by just specifying a type *without* smiley, is already so much better 
than the situation in Perl 5 that the lacking strictness of :D will not be 
needed much to catch programming / garbage in type of errors anyway.


Liz

Re: Backwards compatibility and release 1.0

2015-10-15 Thread Mark Overmeer
* Elizabeth Mattijsen (l...@dijkmat.nl) [151015 10:43]:
> FWIW, I’m with FROGGS on this.
>   use variables :D;

In the first response to this message, Moritz spoke about
 use invocant :D;
 and use parameters :D;

Three different things?

> at the top of the scope of your code, and then you’re set.  I admit
> it feels a *little* like the “use strict” boilerplate of Perl 5.

It is.

> On the other hand, I think by just specifying a type *without* smiley,
> is already so much better than the situation in Perl 5 that the lacking
> strictness of :D will not be needed much to catch programming / garbage
> in type of errors anyway.

Much better, of course.  Programming languages are used by people
of different taste.  Some may find "much better" enough, other people
want more.
-- 
Regards,

   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net



Re: Backwards compatibility and release 1.0

2015-10-15 Thread Elizabeth Mattijsen
> On 15 Oct 2015, at 12:57, Mark Overmeer  wrote:
> 
> * Elizabeth Mattijsen (l...@dijkmat.nl) [151015 10:43]:
>> FWIW, I’m with FROGGS on this.
>>  use variables :D;
> 
> In the first response to this message, Moritz spoke about
> use invocant :D;
> and use parameters :D;
> 
> Three different things?

There are actually 4 different default setters:

use variables :D;# works, e.g. ‘my Int $a = 42’
use attributes :D;   # works, e.g. ‘has Int $.a = 42’
use invocant :D; # parses, does not work yet, e.g. method a(Int:) {} # 
Int:D:
use parameters :D;   # parses, does not work yet, e.g. sub a(Int $a) {}  # Int:D


>> at the top of the scope of your code, and then you’re set.  I admit
>> it feels a *little* like the “use strict” boilerplate of Perl 5.
> 
> It is.
> 
>> On the other hand, I think by just specifying a type *without* smiley,
>> is already so much better than the situation in Perl 5 that the lacking
>> strictness of :D will not be needed much to catch programming / garbage
>> in type of errors anyway.
> 
> Much better, of course.  Programming languages are used by people
> of different taste.  Some may find "much better" enough, other people
> want more.

And sometimes less is more  :-)



Liz



Re: Backwards compatibility and release 1.0

2015-10-15 Thread Moritz Lenz



On 10/15/2015 10:47 AM, Smylers wrote:

Moritz Lenz writes:


On 10/13/2015 10:52 AM, Richard Hainsworth wrote:


Following on the :D not :D thread, something odd stuck out.

On 10/13/2015 03:17 PM, Moritz Lenz wrote:


We have 390+ modules, and hand-waving away all trouble of
maintaining them seems a bit lofty.


Surely, the idea of keeping the release number below 1.0 is to warn
early adopter developers that code is subject to change and thus in
need of maintenance?


... a large percentage of the module updates are done by group of
maybe five to a dozen volunteers. ... 5 people updating 70% of 390
modules. Modules they are usually not all that familiar with, and
usually don't have direct access. So they need to go through the pull
request dance, waiting for reaction from the maintainer. In short, it
sucks.


Thanks for the explanation, Moritz. That does make sense.

I'm still a _little_ uneasy because that sounds a bit like the
explanation of why Makefiles have to use tab characters:

   I just did something simple with the pattern newline-tab. It worked,
   it stayed. And then a few weeks later I had a user population of about
   a dozen, most of them friends, and I didn't want to screw up my
   embedded base. The rest, sadly, is history.

 — Stuart Feldman http://stackoverflow.com/a/1765566/1366011


The problem is, that with this kind of argument one can defer the 
declaration of a "stable" version indefinitely.


May I remind everybody that we want a stable release this Christmas?

Cheers,
Moritz



Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

2015-10-15 Thread yary
Short answer: everything must declare which semantics it expects-
everything in Panda/CPAN at least. And we already knew it, just need
to do it.

Full post: This thread points to a bigger problem, which has a
solution that is both cultural and technical.

Perl5 has a colossal code corpus, humbling in its pervasiveness. Perl
culture understands the value of backward compatibility to keep that
code working as the language evolves and the interpreter improves;
Perl-porters master the compatibility dance and pay for it with
cognitive complexity.

Perl5 has a tension between moving forward and keeping all existing
code running as it was first written. The backward-compatibility
contract is beneficial to the community, and yet it is also friction,
drag on the perl interpreter's progress.

In Perl6 culture, it's time to also adopt the ethic of forward
compatibility where each module states exactly what Perl6 semantics
its coded for. This is not a new idea, S11 says it: "modules are also
required to specify exactly which version (or versions) of Perl they
are expecting to run under, so that future versions of Perl can
emulate older versions of Perl"

That's the cultural part of the solution: we need to start putting
"use 6.0.0" at the start of our code now. The technical part of the
solution is for post-Christmas Perl 6.0.1 to respect that declaration
and "do the right thing."

And more immediately, the community fix is to get the word out; the
technical fix is to s/use v6;/use v6.0.0;/ for everything in Panda
that doesn't get the message by the release date. The old way "use
v6;" means "use any Perl6" and is what got us here: "6.*" is against
the spirit of "exactly which version (or versions) of Perl they are
expecting to run under."

... As for the specific issue of to grin widely or flatly, to :D or :_
defaultly, I'll defer discussing until 6.0.1.  (Earlier I posted a
more specific answer to Darren only; this post is more robust.)


[perl6/specs] 9742c3: fossil eval replaced with EVAL

2015-10-15 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 9742c3981abe688164cf9d4a4c8c88d053b99368
  
https://github.com/perl6/specs/commit/9742c3981abe688164cf9d4a4c8c88d053b99368
  Author: Stéphane Payrard 
  Date:   2015-10-15 (Thu, 15 Oct 2015)

  Changed paths:
M S32-setting-library/Basics.pod

  Log Message:
  ---
  fossil eval replaced with EVAL




Re: Backwards compatibility and release 1.0

2015-10-15 Thread Richard Hainsworth
Moritz rant away! Actually, I think this it is a very significant 
milestone in the development of a language and its ecosystem when 
backwards compatibility becomes an issue.


There will always be modules that have bit rot, insufficient 
documentation, inadequate testing, no reviews, etc. The problem is not 
their existence, but how they are perceived. Newcomers to Perl6 will not 
know much about which modules are useful, which are buggy, which are OK, 
etc. If a newcomer comes across some module that promises a lot and 
fails to work, it may not (unfortunately) be the module that gets the 
blame, but the Perl6 language/community/culture.


Some suggestions:

1) On the perl 6 modules page (modules.perl6.org) , sort the modules by 
number of Badges, with a label for each category like Good (all of the 
badges and 'build|passing'), Less Good (some badges and 
'build|passing'), Experimental (the rest). Perhaps also a warning about 
the modules in the category.
This way, the better quality modules are listed first by default. If 
someone wants to use a Less Good or Experimental module, they have been 
warned.


2) Add another badge for 'reviewed'. I found the CPAN reviews to be 
existentially useful, even if some of the content may be less useful. 
The fact that a module has been reviewed by someone other than the 
author increases my confidence that the module can be made to work. If 
there are negative comments, I am more cautious.


3) Would it be possible to develop a sort of Citation Index? That is the 
number of times a module uses another module? Citation Indices are 
widely used in academia to highlight key articles and papers. It's not 
an infallible tool as the system can be gamed, but it is much better 
than nothing.


4) How about developing the 'bundle' idea more? Perhaps, putting Bundles 
on the Perl6 Modules top page, starting with Task::Star? Bundles could 
be moderated more strictly. Perhaps Bundle authors would need to supply 
a mandate, eg. "Bundle for GUI  development", or "Essential beginners 
bundle". Also bundle authors would need to have vetted the modules in 
the bundle, especially those without all badges.


Regards,
Richard


On 10/14/2015 05:54 PM, Moritz Lenz wrote:

On 10/13/2015 10:52 AM, Richard Hainsworth wrote:

Following on the :D not :D thread, something odd stuck out.

On 10/13/2015 03:17 PM, Moritz Lenz wrote:



But hopefully none of them breaking backwards compatibility on such a
large scale. The last few backwards incompatible changes still cause
pain in the ecosystem. We have 390+ modules, and hand-waving away all
trouble of maintaining them seems a bit lofty.



Surely, the idea of keeping the release number below 1.0 is to warn
early adopter developers that code is subject to change and thus in need
of maintenance?


It is. But we still should try to limit the module author's burden.

In Practice, there's a small number of people who try to update 
modules to match when the compiler changed. Most module authors don't 
hang out in #perl6, eager to update their modules to the lastest 
rakudo change.


So a large percentage of the module updates are done by group of maybe 
five to a dozen volunteers. So, do the math: 5 people updating 70% of 
390 modules. Modules they are usually not all that familiar with, and 
usually don't have direct access. So they need to go through the pull 
request dance, waiting for reaction from the maintainer. In short, it 
sucks.


The ecosystem hasn't yet fully recovered from the s/done/done-testing/ 
change, nor from the GLR, nor from the need to prefix 'unit' to some 
declarations.


And this is why I'm getting increasingly frustrated and angry when 
people propose major breaking changes, brushing off the implications 
for the ecosystem and its maintainers with "but it's not 6.0", 
"shouldn't be a problem", "we aren't stable yet".


We want to release Perl 6 by Christmas, and it'll reflect *very* badly 
on us and the language if many modules in the ecosystem are broken. 
And any change that requires us to touch all .pm files will result in 
that.


Richard, I'm sorry that I'm writing the response in an email of yours; 
Mark or any number of p6l participants in the last few years triggered 
the same mental response from me. I only just now articulated it.




Cheers,
Moritz




Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

2015-10-15 Thread Darren Duncan

On 2015-10-15 5:27 AM, yary wrote:

Short answer: everything must declare which semantics it expects-
everything in Panda/CPAN at least. And we already knew it, just need
to do it.


I believe this is something Perl 6 should require in general, if it doesn't. 
That is, it should be MANDATORY for Perl 6 code to declare what version of Perl 
it expects.  (The sole exception is one-liners.)  If we don't do this, people 
are going to be lazy and not say anything, and then there will be a large base 
of code that officially is just saying "any version of Perl 6 will do" but they 
silently actually expect Perl 6.0.0.0 semantics.  We're always going to be 
stuck with this problem if we don't make declarations mandatory now.  That's a 
much more important change to ingrain into those several hundred existing 
modules, if they aren't already, nevermind the :D thing. -- Darren Duncan




Re: Backwards compatibility and release 1.0

2015-10-15 Thread yary
On 10/13/2015 03:17 PM, Moritz Lenz wrote:
>... We have 390+ modules, and hand-waving away all
> trouble of maintaining them seems a bit lofty.
> ... a large percentage of the module updates are done by group of
> maybe five to a dozen volunteers. ... 5 people updating 70% of 390
> modules. Modules they are usually not all that familiar with, and
> usually don't have direct access. So they need to go through the pull
> request dance, waiting for reaction from the maintainer. In short, it
> sucks.

The idea is to make the maintenance one-time and as minimal as
possible. In the "Exploit the versioning" thread Darren D & I advocate
changing the version declaration at the top of existing modules to
"use v6.0.0.0" and punting on the default-defined-parameter question
until after Christmas. Changing "v6" to "v6.0.0.0" is a one-line
change to ease forward compatibility, and it eases the burden on
module authors. It's practical: Rakudo Star already accepts "use
v6.0.0.0;" without error. (In fact it even accepts "use v88;" which I
do not recommend in production :)


On Thu, Oct 15, 2015 at 12:48 AM, Richard Hainsworth
 wrote:
> Some suggestions:

Reading these brings MetaCPAN to mind:

>
> 1) On the perl 6 modules page (modules.perl6.org) , sort the modules by
> number of Badges, ...
> 2) Add another badge for 'reviewed'. ...
>
> 3) Would it be possible to develop a sort of Citation Index? That is the
> number of times a module uses another module? ...

MetaCPAN's "search" shows most of that info: how many people have
"favorited" it, how many reviews it has and the average "stars". Click
on a result, and it has "citations" linked to as "reverse
dependencies". Search page is not flexibly sortable in its default web
interface, but that is fixable. So... "all we need" are the tuits to
modify MetaCPAN to S22 and get it up on the web... sounds like fun,
not trivial though!

Or in other words, all good ideas that seem to have arose organically
in the P5 ecosystem. Let's adopt them back into P6 when we are
implementing the analogous tools/sites.

> 4) How about developing the 'bundle' idea more? Perhaps, putting Bundles on
> the Perl6 Modules top page, starting with Task::Star? Bundles could be
> moderated more strictly. Perhaps Bundle authors would need to supply a
> mandate, eg. "Bundle for GUI  development", or "Essential beginners bundle".
> Also bundle authors would need to have vetted the modules in the bundle,
> especially those without all badges.

Matches a comment about Perl 6 being like Linux, in how distributions
choose what to bundle with it. Rakudo Star has its choice of useful
modules bundled with it; other people's curatorial choices would be
interesting too...