Joel Berger [blogs.perl.org]

PPI highlighted Mojolicious "quine"

By Joel Berger on February 19, 2013 11:35 PM under CPAN Love, Mojolicious

On February 28th I will be presenting an “Introduction to Mojolicious” to the Chicago.pm meeting. If you are in the area I hope you will stop by; it won’t just be an introduction despite the name. If you are interested, here is the Meetup link.

I haven’t decided, but I might try to “self-host” the talk, writing it as a Mojolcious app! To do that I had to resurrect one of my earliest CPAN releases Mojolicious::Plugin::PPI. This module does just what the name should imply, providing syntax highlighting via PPI and PPI::HTML in a handy Mojolicious plugin.

Whether or not I decide to use this for my talk, it still is handy to have around. Here is a cute example, a simple “quine” which you can run:

#!/usr/bin/env perl

use Mojolicious::Lite;

plugin 'PPI' => { toggle_button => 1 };
get '/' => sub {
  my $self = shift;
  $self->stash( file => __FILE__ );
  $self->render('quine');
};

app->start;

__DATA__

@@ quine.html.ep
% title 'A Mojolicious "Quine"';
<!DOCTYPE html>
<html>
  <head>
    <title><%= title %></title>
    %= javascript 'ppi.js'
    %= stylesheet 'ppi.css'
  </head>
  <body>
    <h2><%= title %></h2>
    %= ppi $file
  </body>
</html>

A quine is a program that prints its source code as its output. In truth, this “quine” is really a cheater, a true quine doesn’t read itself. Still, the above example renders the source code nicely highlighted by PPI (and with some added goodies like toggleable line numbers).

Just for fun, some other Perl (cheater) quines are:

@ARGV = $0; print for <>

and

seek DATA,0,0; print for <DATA>
__DATA__

But those outputs aren’t syntax highlighted. For a real one see the comments.

4 comments

#galileo on irc.perl.org

By Joel Berger on February 14, 2013 8:21 AM under Galileo

Hi all,

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.

Interested? Drop on by and chat about it!

0 comments

A new protocol for sending files over websockets

By Joel Berger on February 11, 2013 4:58 PM under Galileo, Mojolicious, Perl Love

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).

Read on (examples!) …

0 comments

In the name of "Create great things (in Perl)"

By Joel Berger on February 10, 2013 10:22 PM

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.

chromatic petdance 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:

Things I’ve Seen

play-perl - A social coding game
TryPerl - An online IDE for writing and running Perl scripts (per the author, it might still need a little help). This is a “try before you install” solution.
Farabi - A CPAN installable browser-based Perl IDE.
PerlTuts - An interactive “learn as you go” introduction to Perl

Things I’ve Done

Demonstate non-blocking websocket file uploads (for eventual use in Galileo)
Played with Lvalue accessors. Should it be a MooseX module?

It may not be enough, but its always nice to share what you and others are doing. Go Perl!

6 comments

Does Perl (5) have a future?

By Joel Berger on February 8, 2013 5:42 PM under Perl Love

TL;DR: Not if it can never have a major release. Please read on.

Note: I’m now not talking about soon, or what it would be named/numbered. I’m talking about ever.

Let me tell you my story, some of you may know it. I’m a Ph.D. candidate in Physics. Programming is woefully ignored in science education now. All my professors learned FORTRAN in courses during their Ph.D. (or B.S. in some cases) but now, given the ease of Mathematica, we seem to be expected to pick it up as we go on.

One day I had a nutty idea, I wanted to parse one of the temporary files created during LaTeX compilation. A friend, who knew next to nothing about Perl, suggested I needed Perl and Regexes. I can here you out there, saying “now I had two problems”. Not so. I learned, I improved and finally my first Perl script was out in the world. It doesn’t bear much resemblance to its current form but it worked.

This project had nothing to do with science, but I was awed by the power I now possessed. I went to start using Perl in my work. Perl finally solved a near-intractable programming problem in Mathematica with relative (hmmmm) ease. Physics::UEMColumn now forms the basis of my Ph.D. thesis which I am defending this spring.

To get that simulation working I needed more tools, so I wrote them, and those tools needed tools so I wrote them and suddenly I discovered that I had something I could give back, so I’m writing it too. Further I often need PDL, and amazing numerical package for Perl. It really needs some internal TLC, which David Mertens, project pumpking Chris Marshall and others are planning.

Why am I telling you this? Because in 2009 I became a Perl programmer, and I fell for language hard. I love Perl. I came for regexes, but I stayed because it works well with the way I think. I use it for lots of things now. Unfortunately few others have come with me.

Chromatic implores us to write good software and show it off. For these years I have tried, and it doesn’t work. I have given talks at my university, I have told friends, I have used it to help coworkers, I share with the community. I have recruited one person. I have converted none. Most people who know Python or ROOT (C++) laugh at me. Its not enough.

Until yesterday, I had a steely resolve. Even in the face of Stevan’s recent pronouncement and embarking on replacing the Perl internals with Scala, which would probably kill or at least maim most of my work. Moe wasn’t the future of Perl, just an offshoot, right?

Yesterday, for the first time, I saw a flaw. There are people out there who really think that Perl will never see another major point release. I don’t mean soon, I don’t mean for cheap marketing, I mean ever. I mean for at some point breaking some small amount of backward compatibility. For some the reason is that compatibility is too important (the future is our past), for some its that Perl 6 is the future of Perl 5 (whether spoken/believed or not) and some its just because there is no number available. All that got me to thinking …

Is the work on Perl 5 really just a shim to support CPAN? Is it really going to be an ever-growing feature pragma? Will there always need to be a magic incantation to activate some of the best Unicode support in the programming world? Will new Perlers need to be told to use good practices like strict and warnings forever? Is the herculean work of Nick Clark and Dave Mitchell just going to go for naught after a few years of a usable Perl 6 and Moe?

If Perl can never have a major point release. I think all of the above is fated to be true. I’m not asking about soon; I’m asking about ever.

In my mind I’m planning future work on the Perl we now call 5. I want to help improve the giant XS extension called PDL, possibly using another one called Prima. I intend to keep working on Alien::Base. But is it all just going to vaporize in a few years do to lack of external interest, or after being replaced by something? Why should I?

In the upcoming months, I will be looking for my first real job. It might be a post-doc appointment with Pacific Northwest National Lab (PNNL) doing the hardware/software integration for a brand new ultrafast electron microscope. Should I do it in Perl? I will only be there a year or two, is it fair to saddle them with that? Will they find someone else who can maintain it?

If I don’t do that, I might form a company, one that aids research groups in writing the software that they often cobble together, for analysis, data warehousing and search, for hardware integration. Would I do that in Perl?

If the powers that be don’t see a major point release at some point in Perl’s future, then it has none. The userbase will keep sliding away. Not purely for a number, or marketing, or perception, but because you will need too much knowledge to start using it. You will need to know the incantations to do things right, ones that we already know, but new users can’t find. How many people find a CPAN module that does just what they want, and so set out to write their Perl first script, only to fail and walk away? We can’t ever know.

I ask you p5p (whom I admire greatly) and I ask you Larry, creator, benevolent dictator, does the language we call Perl 5 have a future? At some time, will we see a major release? If not, then I don’t know what I’m working towards. Should I tie my future to this language?

23 comments

On the version number succeeding Perl 5

By Joel Berger on February 6, 2013 10:07 PM under Perl Love

Recently Ovid broached the topic of allowing a future release of Perl 5 with a version number greater than 6; this is not a new argument. He further explicated the problems:

I just got back from FOSDEM and heard, again, for the umpteenth time, that since Perl had 4 “major” releases (1,2,3,4) in its first few years and hasn’t had a major release since Perl 5 about 20 years ago, it’s clearly “dead”. I hear this every time I go to a conference that’s not dedicated to Perl.

…

Meanwhile, in the minds of, of, virtually every developer on the planet who’s not in our echo chamber, Perl 6 is, logically, the successor to Perl 5. Since even Duke Nukem Forever managed to get released prior to Perl 6, Perl 6 just isn’t being taken too seriously be many devs. In other words, they think Perl 5 is dying and its successor is DOA.

I agree with him. As I commented:

I think Perl 5 has had to live in the shadow of Perl 6 for too long. Now that its decided that they will be two different languages, I think its only fair to allow Perl to get the cache’ one gets from a major version increment.

This can end the “Perl is dead” chatter (outside the community anyway). After all why would you want to use Perl 5 when Perl 6 is going to replace it (says Joe Pythonista or Jane Rubyist).

Perl 7 is here! Its Plack and Catalyst/Dancer/Mojolicious(+Mango (what’s Mango?)), its Moo(se)? and DBIx::Class. Its CPANtesters and MetaCPAN and cpanm. There is so much the outside world has missed because they are waiting for Perl 6, which may come at some point but it still wont replace Perl 5. Lets show them its safe to come back and that there are LOTS of goodies to find when they do!

That said I want to take it even a little further. Perl has been proud of its backward compatibility, and well it should be! Code from many years ago runs well on very recent Perls. But what can be a blessing can also be a curse.

Perl 5 still supports many conventions and oddities from Perl 4 and before. There are some silly things like ' as a package separator, which most people neither use nor trip over. Then again there are some real things, like indirect objects notation, default script/handle encoding, new keywords.

Olof Stockhaus made a compelling case that Perl 5 might want to use the jump to Perl 7 to make some breaking changes. For example, among other things he suggests waiting for the p5mop project. However, I think I agree with Damien Krotkine in saying that that sounds like a great target for Perl 8 which could come soon afterwards. There are many things we wish for a future Perl, but until they are ready, there still could be some changes. I think Perl 7 could be a great oportunity to do minor, but important, breaking changes. Then let Perl 8 come in later with a MOP or a proper language spec. Either way, without a major version increase its hard to make breaking changes. Without a major version to increase, we have been stuck.

Now, some have suggested that we should drop the 5 from the version number and add it to the name. Therefore we would have Perl5 version 20.0 and Perl6 version 0.1. The problem is that this still doesn’t make the case that Perl6 won’t supplant Perl5. Those people like to make the case that Java dropped the 1 so that Java 1.6 became Java 6. However this comes back to my first point. They realized that 1.5 and 1.6 (or whatever was the actual change) was going to have major changes and should be a major release. Why they didn’t simply call it Java 2 I’m not sure. What I do know is that they weren’t trying to convince people to use Java1 version 6 when something called Java2 existed.

To comment on using the year as the version number I think there are two problems with that. First, it doesn’t really signify that Perl6 is not the successor. Secondly, what it does seem to signify is that the Perl community is going to abandon the stability that is one of its strongest suits. Yes I’m advocating some breaking changes above, but rather small ones, things that will help more than they hurt to fix. I don’t think we want to imply that there will be breaking changes once per year, we can still use feature to scope changes to Perl 7 through sub-major version releases. That said, breaking changes once a decade is probably ok.

Perhaps this is the root problem. The semantics of versioning are an important tool to inform the outside world what the state of Perl is!

Anyway here’s what I propose. Say we do implement the above, so now we have two languages Perl5 and Perl6. However, since Perl5 version 20 is mostly compatible with Perl version 5 perhaps it could be allowed to keep the name. Then it seems odd that Perl should jump versions from 5 to 20, so why not just move to the next available number 7. So now we have Perl 7 successor to Perl 5 and Perl6 a new language.

This does not signify the death of Perl 6 but the life of Perl. It just so happened that Perl 6 became its own language and started its own branch in the Perl family tree. Now that we know that the success of Perl 5 and Perl 6 no longer depend on each other, why should their version numbers?

After the break, my initial list of realistic goals for Perl 7

26 comments

Joel Berger

February 2013 Archives

PPI highlighted Mojolicious "quine"

#galileo on irc.perl.org

A new protocol for sending files over websockets

In the name of "Create great things (in Perl)"

Does Perl (5) have a future?

On the version number succeeding Perl 5

About Joel Berger

Search this blog