I've just put a post up on my shadowcat blog talking about where the 'perl 7' meme came from, why it's a terrible idea, and suggesting what we should do instead.
tl;dr - Pumpkin Perl!
This post exists to provide somewhere for people to comment that isn't Hacker News or reddit; I've cross linked it from the end of the blog post itself so hopefully people who want to discuss the idea will find their way here.
I just wanted to drop a quick note to announce #galileo on irc.perl.org as a place to talk about Galileo my CPAN installable CMS and its new companion project GalileoSend which isn’t quite to CPAN yet, but it will be soon.
GalileoSend will make sending files via websocket easy! So far the package includes a command-line sender (client) and receiver (listener/server), a Mojolicious plugin and a javascript client. Futher GalileoSend is a protocol spec, which means if you want to write a client or server in your other favorite language, or a plugin for your favorite framework, its very possible.
PhantomJS is a 'headless' WebKit browser, mainly intended for use as a web testing framework, and is controlled by a JavaScript API. The 'headless' aspect of that also makes the framework extremely useful for scraping JavaScript heavy websites.
The problem with PhantomJS (up until the v1.8 release on 23 December 2012), was that if you were unfamiliar with JavaScript, CoffeeScript or Node.js (if you were using the Casper.js fork), was that it wasn't very easy understand or control. Since the v1.8 release in December, PhantomJS now supports WebDriver, which basically means you can control it from pretty any language you like (although Perl isn't explicitly mentioned).
Since I like Perl, I decided to give it a go after trying WWW::Mechanize::Firefox + MozRepl, which is great, but doesn't work if you're going double-headless and are running it on a GUI-less server.
Even though Git sometimes gives me heartburn, I'm a huge fan of GitHub. The fork & pull workflow makes it sooo easy (and fun) to contribute to other projects. And as a project owner, it is very easy for me to manage incoming contributions. My absolute favorite feature is the discussions that are inline with the code. To me, that is much more natural than talking about code in a separate mailing list.
So I started thinking...what if Perl5 was developed on GitHub[1]?
Moving a large and mature project like Perl5 to a new set of tools and workflows will certainly not be easy and I expect a lot of resistance. I don't expect perfect feature parity either -- some capabilities will be gained and others will be lost. But GitHub has worked really, really well for a lot of projects (including Perl6). So I think it is definitely worth investigating.
One of the fun / cool things about Perl is that it can easily inhabit that space between "too complex for bash" and "too insignificant to invest in a C implementation." In my opinion a lot of the command line tools for EC2 are pretty terrible - they have a large learning curve, a high amount of dependencies and they just aren't that easy to get up and going.
So I started by thinking what was the "minimum viable product" for an EC2 client? Something that slaps a valid v2 AWS signature on any arbitrary API request and translates the XML returned into a Perl data structure. And that's exactly what Net::EC2::Tiny is.
In the spirit of *::Tiny modules, I tried to restrict the number of dependencies, but when I decided firmly to require HTTPS support, that locked me into IO::Socket::SSL and Net::SSLeay, so I opted to give myself a little bit of sugar and used Moo. So there's 5 non-core dependencies.
Anyway, when you're in the mood for a quick (and possibly dirty) EC2 client, whip up a simple(ish) script using Net::EC2::Tiny. It's the low learning curve glue between the raw EC2 API and Perl - perfect for those jobs which interact with EC2 in a relatively minor way.
There are a lot of contributions on CPAN that fill one niche or another with respect to pseudo-randomness generation. What is hard to find is a solution that provides cryptographically secure pseudo random number generation, reliable and strong seeding, a light-weight dependency chain, and cross platform compatibility through a wide range of operating systems and Perl versions.
Bytes::Random::Secure is one of those modules that gets written to fill a personal need, and then begins to take on a broader life of its own. As is often the case, the contributions of others in the community have served to improve the module beyond its original specifications. Dana Jacobsen provided a lot of suggestions, and even went so far as to create a new seeding module (Crypt::Random::Seed) which helped Bytes::Random::Secure to reduce its dependency footprint greatly.
Yesterday I was reading Joel's
post,
where he lists great Perl things he's seen done lately. Indeed these are great
stuff. I was particulary interested by his try at playing with Lvalue accessors.
I thought that it would be a great exercise to try to implement it in Moo, as
an additional feature, trying to get rid of the AUTOLOAD. Also, I was willing
to avoid doing a tie every time an instance attribute accessor was called.
Surely, I needed to tie only once per instance and per attribute, not each
time the attribute is accessed.
So I started hacking on the code of Moo. Getting rid of the AUTOLOAD was easy,
as I could change the way the accessor generator was, well, generating the,
err, accessors.
This is my first post on b.p.o. I know you guys are arguing about the version issue of Perl recently. How about take a short escape and try quickcd at https://github.com/jchain/quickcd? If you are a Linux && Bash guy, you might find it useful.
Most DBI tutorials will show you how to use prepare()/execute(). Something like this:
my $sth = $dbh->prepare( 'INSERT INTO table (foo, bar) VALUES (?, ?)' ) or die ...;
$sth->execute( 1, 2 ) or die ...;
$sth->finish;
Most of us write DBI this way when we don't use DBIx::Class or some other abstraction layer (or we use $dbh->do(), but it won't end up changing my point). For most databases, the above is fine.
On SQLite, you can lose data that otherwise would have gone in fine.
Today I’m happy to make public the work I’ve been doing to make some kind of “standard” for sending files over websockets. I call it GalileoSend because it was created for the Galileo CMS.
The protocol itself is language independent for both the client and server side, assuming that both can open a websocket connection and send JSON (as text) and binary data over it. Since communication by websocket is cheap, 2-way communication is highly encouraged throughout the transfer and positive confirmation of receipt is required.
Further, I have written a javascript client-side implementation (which could be used for any server) and a non-blocking Mojolicious server-side implemenation (which could be used for any client).
Perl is very flexible in may ways including whitespaces. Perl does not force you to use tab or spaces. The script works fine no matter if it has DOS or UNIX line breaks.
But there are some good practices. I preffer these rules:
every line ends with "\n" (including the last line)
UNIX way for new lines (only "\n", not "\r\n")
no tabs, but 4 spaces instead
no trailing spaces
no empty lines in the end of the file
I want to make sure that all that rules are followed in my source code. So I've written Test::Whitespaces. There are several good things in this module.
As some of you probably noticed, from my
post in TPF blog
, there were no grant proposals in the last six months. I am not sure how to interpret this lack of interest in grants. But there are some ideas that come to my head:
People do not need money :-)
People prefer to do things by themselves, without any schedule or pressure;
Nobody uses Perl anymore
Everything Perl needs is already on CPAN
The maximum amount of a grant ($3000) it not paying anything
I am not sure if there are other reasons. But I would love to hear comments (constructive comments, please) about this issue.
I must say that the less grants proposals we receive, the less I need to work. But I volunteered, and it would make me happy to have interesting projects running.
First, I want to apologize. My follow-up to the Perl 7 post was not very polite. When I predicted that "nothing" would happen, even if people wanted it, I could have said that in a much kinder way. In particular, my apologies to Ricardo for that.
As for "Perl 7", let me be clear: I don't support it. I originally asked the question because I wanted to know what people thought and instead of kicking over a rock to see what was underneath, I kicked over a hornets nest. More importantly (to me), I got my answer in spades.
Notes from a Newbie document the creation and deployment of yardbirdfanclub.org with Perl Catalyst on shared hosting. They are intended for a Perl Catalyst Newbie who would like to study the creation and deployment of a Perl Catalyst application.
In these notes I continue to explore what it might take to create a blog application, focusing on how to use CSS to layout a page.
The number of people registered on the conference site went over 100 recently. So, since this week, we will deliver our weekly newsletters to your mailboxes. There's also a permanent place where you can catch up with the latest news about the conference. At act.yapc.eu/ye2013/news/ we are collecting all the previous newsletters.
Just a reminder that everything has been open: user registration, online payment gate and talk submission form. Just explore the site and act: yapc.eu/2013.
Today we would spend some time talking about Perl 7. Probably there's no one here who did not see at least a small portion of the discussion that burst a week ago on blogs.perl.org and nntp.perl.org. There were a number of posts about, well, yes, Perl 7. The title of this year's conference is Future Perl, so we as the organisers are very excited about the chance to move Perl forward exploiting the conference.
You may have noticed my commentary on the Perl version number debate. I think that that debate is a possible way of raising the profile of the language we love, but that’s not why I called.
chromaticpetdance and I’m sure others have suggested that rather than infight (which I don’t believe I’m doing, btw) is to make something great and show it off. While I don’t think this is enough to raise Perl’s profile ourside of our community, I have seen and IMHO done some very cool things this week:
Signal that you'd like to pass on your modules by giving the virtual PAUSE user ADOPTME permissions. I've always been amazed at one of the least appreciated features of CPAN: people will step up to maintain or shepherd modules that aren't scratching their itch. It's a different sort of activity than the long-term or drive-by participation that most open source projects rely on. There are a group of people who maintain CPAN projects that they don't even use. There are a few that I handle that I've never used in a program.
I think we can improve on this wonderful but underrated social feature. I created the ADOPTME user awhile ago to house the distributions from PAUSE authors who had passed away. I would modify the build file to give a warning, bump the version, and upload as ADOPTME. That's too much work, though.
Notes from a Newbie document the creation and deployment of yardbirdfanclub.org with Perl Catalyst on shared hosting. They are intended for a Perl Catalyst Newbie who would like to study the creation and deployment of a Perl Catalyst application.
In these notes I continue to explore what it might take to create a blog application, focusing on how to use a database.
