Re: Backwards compatibility and release 1.0
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
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
> 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
* 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
> 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
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)
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
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
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)
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
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...