Hmm, I didn't give the top stats for that. I'll have to fix that later!
]]>So whilst you may prefer to use your own private git repo, or another git service (http://repo.or.cz/ for example) - you can easily push releases to Github. Perhaps you could automate it with Dist::Zilla or one of its friends so you dont even have to think about it.
The advantage is that Github really has "critical mass" which maximizes your chances that someone will send you a patch or bug fix as a pull request.
The aforementioned multi-upstream features, allows you to quickly pull those changes - vet them as you see fit, then push them to your preferred repo location.
So it becomes not a discussion about if you as an author love/hate/dontcare about Github - its merely that by having your code on Github you make it convenient for more people to work for free on your software :)
]]>Why?
> Strict, warnings, utf8 and newest Perl features on by default
Modern::Perl or a similar pragma.
> Sub signatures and postfix dereferencing should be on and without experimental warnings
Easily achievable with a pragma.
> Most of the greatest CPAN modules should come preinstalled, and I am really talking about modules that helps beginners! i.e. Devel::REPL, Devel::DidYouMean, Moo, and many many other like Mojolicious, Dancer, Catalyst, whatever…
Task::Kensho, dwimperl, or a custom Task::.
> Forbid/remove special cases like split emulating awk.. or indirect object notation and many other silly leftovers
indirect.pm for indirect object notation.
In any case, they do no harm — nobody forces the teachers to teach these features.
This ePerl should just be a pragma and a Task::, probably in a single distro. Which would be easy to write. No need to break backwards compatibility or to use a sandbox.
]]>Due to different requirements. Perl for production needs to support what was done 10 years ago. Perl for education should enforce current best practices, hence can be more aggressive.
> Strict, warnings, utf8 and newest Perl features on by default
>> Modern::Perl or a similar pragma.
I agree.
> Sub signatures and postfix dereferencing should be on and without experimental warnings
>> Easily achievable with a pragma.
True, as some of the other things, but not all.
> Most of the greatest CPAN modules should come preinstalled, and I am really talking about modules that helps beginners! i.e. Devel::REPL, Devel::DidYouMean, Moo, and many many other like Mojolicious, Dancer, Catalyst, whatever…
>> Task::Kensho, dwimperl, or a custom Task::.
While both Task::Kensho and dwimperl are awesome, they do not achieve what I would like to see in Perl for education. Furthermore, they are NOT backed-up by Perl foundation..
> Forbid/remove special cases like split emulating awk.. or indirect object notation and many other silly leftovers
>> indirect.pm for indirect object notation.
Sure, again, via pragma you can disable indirect object notation and many others, but you can't forbid things like one/two argument open and etc. etc.
>> In any case, they do no harm — nobody forces the teachers to teach these features.
In my opinion it does harm. Pupils may solve an exercise in a way that an experienced Perl developer ( with 10 years of experience ) would struggle to understand without a compiler, and now we are talking about teachers who had no more then a month or two years of playing. Furthermore, I feel they are wasting their time by explaining "what modern perl is" with all the boilerplate..
>> This ePerl should just be a pragma and a Task::, probably in a single distro. Which would be easy to write. No need to break backwards compatibility or to use a sandbox.
Yes and No. Perl lost it's fight in education sector. It's a fact. Thanks to Gabor Szabo and many others, there are things like dwimperl, but as we see - it's not enough. First of all, such initiative to get back into education market should be backed up by Perl foundation, who therefore might find sponsor and do a proper research of why Perl is not there and what we can do to be there. I can only guess, that it is:
- backwards compatibility
- no proper interactive shell
- too much boilerplate
- undermarketing PDL and friends
- need of PBP v2
- sponsors
- visibility(?)
btw, pdl.perl.org is down at the moment.
]]>The major thing that's missing in Perl6 is ready-to-use frameworks like Dancer etc (but I assume some proto-versions of such frameworks are hiding on github somewhere..)
]]>Still, breaking backwards compatibility shouldn't be a goal.
> While both Task::Kensho and dwimperl are awesome, they do not achieve what I would like to see in Perl for education. Furthermore, they are NOT backed-up by Perl foundation..
It is easy to create a custom Task:: with exactly the modules you would like to see in Perl for education. Why do they need to be backed up by Perl foundation?
> Sure, again, via pragma you can disable indirect object notation and many others, but you can't forbid things like one/two argument open and etc. etc.
For one/two argument open, can't a pragma override open via CORE::GLOBAL? Most things are achievable via pragmas.
> In my opinion it does harm. Pupils may solve an exercise in a way that an experienced Perl developer ( with 10 years of experience ) would struggle to understand without a compiler, and now we are talking about teachers who had no more then a month or two years of playing.
Students will most probably only use what the teacher showed them to solve the exercises. At worst, ePerl could include a perlcritic policy — the teacher can reject solutions that fail it, or the eperl pragma could pull in criticism.pm, refusing to run code that does not follow the policy. Of course, all this is very much against the spirit of Perl, but if the teachers want this feature let them have it.
> Furthermore, I feel they are wasting their time by explaining "what modern perl is" with all the boilerplate..
If ePerl is a pragma, the only boilerplate is 'use ePerl;'. Even this can be avoided -- just ship an executable named eperl which runs perl -MePerl "$@".
> First of all, such initiative to get back into education market should be backed up by Perl foundation, who therefore might find sponsor and do a proper research of why Perl is not there and what we can do to be there.
Right, researching what the teacher want is the first step — we're just guessing here, and probably guessing incorrectly.
> - backwards compatibility
Not bad in itself.
> - no proper interactive shell
I've never found these useful, but ePerl can ship a REPL as a dependency.
> - too much boilerplate
Easy to fix (see above).
> - undermarketing PDL and friends
True.
> - need of PBP v2
> - sponsors
> - visibility(?)
No idea about these.
A simple Perl distribution with the features discussed above (a do-it-all pragma, useful modules as dependencies, maybe an eperl executable) would be easy to build and would solve most of the problems you've identified.
]]>Some other ideas I came across:
* pyconuk 2014 had 2 days education track
* Applications like Pyland would be great
* It might be great to adjust Perl for different levels, something like staging Perl, i.e. allow only if statements for 5th grade pupils, allow feature x for 6th grade pupils etc. etc. obviously that fits syllabus and government requirements.