SoylentNews is people
SoylentNews
from the begin-rehash-port-in-3-2-1..... dept.
It's been 15 years in the making. Unveiled in October, Perl 6 has been officially released:
On behalf of the Rakudo[1] development team, I'm proud to announce the Christmas release (December 2015) of Rakudo Perl 6 #94 "коледа"[2]. Rakudo is an implementation of Perl 6 on the Moar Virtual Machine.
[...] Together, we've built a language that:
- Retains the core values of Perl: expressiveness, getting the job done, taking influences from natural language, and pushing the boundaries of language design
- Has clean, modern syntax, rooted in familiar constructs but revisiting and revising the things that needed it
[...] While we are extremely happy to ship an official Perl 6 release, this is not the end of Rakudo's development. We will continue to ship monthly releases, which will continue to improve performance and our users experience. We'll also continue our work on the specification, with feedback from the community.
Related: Perl 6 Gets Beta Compiler, Modules and an Advent Calendar
[1] According to Wikipedia:
The name "Rakudo" for the Perl 6 compiler was first suggested by Damian Conway.[7] "Rakudo" is short for "Rakuda-dō" (with a long 'o'; 駱駝道), which is Japanese for "Way of the Camel". "Rakudo" (with a short 'o'; 楽土) also means "paradise" in Japanese.
[2] According to Wikipedia:
Koliada or koleda (Cyrillic: коляда, коледа, колада, коледе) is an ancient pre-Christian winter ritual/festival. It was later incorporated into Christmas.
(Score: 5, Informative) by number6 on Sunday December 27 2015, @08:02PM
___________________________________________________________________________
//https://en.wikipedia.org/wiki/Mod_perl
mod_perl
mod_perl is an optional module for the Apache HTTP server. It embeds a Perl interpreter into the Apache server. In addition to allowing Apache modules to be written in the Perl programming language, it allows the Apache web server to be dynamically configured by Perl programs. However, its most common use is so that dynamic content produced by Perl scripts can be served in response to incoming requests, without the significant overhead of re-launching the Perl interpreter for each request.
Compare to Common Gateway Interface (CGI) ...........
mod_perl can emulate a Common Gateway Interface (CGI) environment, so that existing Perl CGI scripts can benefit from the performance boost without having to be re-written. Unlike CGI (and most other web application environments), mod_perl provides complete access to the Apache API, allowing programmers to write handlers for all phases in the Apache request cycle, manipulate Apache's internal tables and state mechanisms, share data between Apache processes or threads, alter or extend the Apache configuration file parser, and add Perl code to the configuration file itself, among other things.
___________________________________________________________________________
//https://metacpan.org/pod/CGI#CGI.pm-HAS-BEEN-REMOVED-FROM-THE-PERL-CORE
CGI.pm HAS BEEN REMOVED FROM THE PERL CORE
If you upgrade to a new version of perl or if you rely on a system or vendor perl and get an updated version of perl through a system update, then you will have to install CGI.pm yourself with cpan/cpanm/a vendor package/manually. To make this a little easier the CGI::Fast [metacpan.org] module has been split into its own distribution, meaning you do not need access to a compiler to install CGI.pm
The rationale for this decision is that CGI.pm is no longer considered good practice for developing web applications, including quick prototyping and small web scripts. There are far better, cleaner, quicker, easier, safer, more scalable, more extensible, more modern alternatives available at this point in time. These will be documented with CGI::Alternatives [metacpan.org]
For more discussion on the removal of CGI.pm from core please see:
http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/msg202130.html [perl.org]
Note that the v4 releases of CGI.pm will retain back compatibility as much as possible, however you may need to make some minor changes to your code if you are using deprecated methods or some of the more obscure features of the module. If you plan to upgrade to v4.00 and beyond you should read the Changes file for more information and test your code against CGI.pm before deploying it.
___________________________________________________________________________
//https://metacpan.org/pod/CGI::Alternatives
CGI::Alternatives
Documentation for alternative solutions to CGI.pm
This module doesn't do anything, it exists solely to document alternatives to the CGI.pm module.
BUT WHY? .................
CGI.pm hasn't been considered good practice for many years, and there have been alternatives available for web development in perl for a long time. Despite this there are still some perl developers that will recommend the use of CGI.pm for web development and prototyping. The two main arguments for the use of CGI.pm, often given by those developers, are no longer true:
(1) "CGI.pm is a core module so you don't have install anything extra."
This is now incorrect as perl 5.22 has been released and no longer ships with it:
http://perl5.git.perl.org/perl.git/commitdiff/e9fa5a80 [perl.org]
If you are doing any serious web development you are going to have to use external dependencies, DBI is not in the core for example.
(2) "CGI.pm scripts are shorter and simpler than alternative implementations."
Again, not true and the following examples will show that:
[...]
___________________________________________________________________________
//https://learnxinyminutes.com/docs/perl6/
LEARN PERL 6 IN Y MINUTES - a quick one-page introduction and cheat-sheet