101–110 of 125 posts
Also goodbye illguts then. Illustrated guts is the description of the perl5 internals, in html and images. Metacpan still does not allow displaying it and I won't pay for hosting services. Static GitHub pages maybe, but how stable will that be, and it's another link away from the primary content. They knew of this problem for years.
Now this is you how EOL a beloved product. By working with an OSS replacement such that the transition is transparent. Super thanks to the team for the CPAN search (it was a lifesaver many times for me in the past!) as well as for their awesome transition plan.
Also, experienced something similar with codehaus.org in the java world a few years ago.
- Perl6 is quite a different language from Perl5
- I am aware that there is an enormous amount of code written in Perl 5
Has anyone of you started transitioning to Perl6 ? If so, what's your experience/opinion ?
I was wondering: given that - Perl6 is quite a different language from Perl5 - I am aware that there is an enormous amount of code written in Perl 5 Has anyone of you started transitioning to Perl6 ? If so, what's your experience/opinion ?
The modules implemented so far: http://modules.perl6.org/t/CPAN5
I'll also be giving a keynote on this subject at The Perl Conference 2018: https://perlconference.us/tpc-2018-slc/session/the-state-of-...
If you want to keep up to date on happenings in the Perl 6 world, please checkout the Perl 6 Weekly: https://p6weekly.wordpress.com
This is truly a down moment, to be sure, but it's pretty telling that the site became too hard to maintain because it's written in old Perl. I'm not a Perl hater. I like Perl! I got my start in Perl and spoke at a YAPC::NA a few years ago. It's telling, is all I'm saying. It tells us something.
It tells us that a solo maintainer of a large project - with no assistance from the community possible, because closed source - trying to do it in his spare time, will eventually result in a massive accretion of technical debt. It's a testament to Graham's productivity that he was able to keep maintaining it for so long in spite of those disadvantages, and says very little about perl.
A project maintainable by a single dev from any real perspective has little technical debt.
Also goodbye illguts then. Illustrated guts is the description of the perl5 internals, in html and images. Metacpan still does not allow displaying it and I won't pay for hosting services. Static GitHub pages maybe, but how stable will that be, and it's another link away from the primary content. They knew of this problem for years.
From the article: > In recent years maintenance has become a burden. Most of the site is running 2005 era Perl code. Luckily, there is now a viable alternative: MetaCPAN.org. The MetaCPAN team has been getting ready for the transition and is nearly ready to take over. Shortly, a link will be added to all pages on search.cpan.org to inform users of the upcoming change. After about a month, all traffic will be redirect…
This is one of the main things Perl is about. The language and the community takes, in the broadest sense, operational stability very seriously. More serious than any other language community I'm aware of.
Note that knowing perl well is quite a commitment and counter to current fashion in the industry.
Earlier quoted context omitted.
It tells us that a solo maintainer of a large project - with no assistance from the community possible, because closed source - trying to do it in his spare time, will eventually result in a massive accretion of technical debt. It's a testament to Graham's productivity that he was able to keep maintaining it for so long in spite of those disadvantages, and says very little about perl.
Does it necessarily follow that a solo dev, working on a project in their spare time, will accrue massive technical debt? I'm honestly asking, as a solo dev that works on projects in my spare time. If it is the natural progression, how can it be avoided?
Earlier quoted context omitted.
You can also get a real quick exposure from the Modern::Perl module[1], which is by the author of the book mentioned in a sibling reply. The basic idea is simple though. Use strict. Use warnings. Use new features and best practices modules (Task::Kensho[2] an help here) when them make sense (e.g. Moose/Moo). Be aware at least what PBP[3] is, and if you feel so inclined, use Perl::Tidy and/or Perl::Critic (even if you…
> 2: https://metacpan.org/pod/Task::Kensho Uhm, I can't see Catalyst listed in the web development section... Has it fallen out of grace ?
The thing I like about catalyst is the same as the thing I like about git. It works well for the smallest use case and it scales well to the largest reasonable case.