“Let’s free ourselves from the shackles and do something bold!”
I always cringe when I hear this battle cry. Isn’t that sentiment exactly what set the trajectory for the Perl 6 effort? Maybe it’s just been so long that people have forgotten.
But that is precisely how Perl 6 became such an amazingly long trek: once you remove the constraint of staying compatible, everything is suddenly, potentially, up for reconsideration. Then when you start changing things, you discover that changes in one part of the language also affect several other, remote parts of the language. So it starts with the simple desire to fix a handful of obvious problems in obvious ways… and spirals out as you make changes, and further still as you make changes in response to your changes, ever further and further.
So when I started the p5-mop-redux project I purposefully avoided getting too deep into the meta-layer swamp. One of the things that became really difficult with the previous attempt was the level of complexity in the meta-layer bootstrapping. For this new version I decided I was going to favor a simpler and more manual bootstrapping process, and so proceeded to punt on it until I got the regular class layer working.
Well today I decided it was time to dive into that meta-layer swamp, and I am happy to say, ... it works!! (after a bunch of tweaking and fiddling that is).
Here is one of the tests from the previous prototype converted to work with the specifics of this MOP. It implements a simple metaclass which will auto-generate public accessors for all your attributes.
Additionally here is another converted test which does the same thing, but takes an optional validator to do validation on values being set (similar to Moose). This also demonstrates has variables being able to take in extra metadata.
Flux is the framework I've been meaning to release for a very long time [1].
What's it good for? Message queues; organizing your data processing scripts in a scalable way; de-coupling your processing pipeline elements, making them reusable and testable; seeing your system as a collection of lego-like blocks which can be combined and replaced as you like. With Flux, your code is a series of tubes.
Flux is a rewrite of Stream framework which we wrote and used in Yandex for many years. Stream:: namespace on CPAN is taken, though, which gave me the reason to do a cleanup before uploading it, as well as a chance to rewrite everything with Moo/Moose.
I'm planning to release Flux in small chunks, explaining them along the way in separate blog posts, as time will allow. Today, I'll explain the main ideas behind it, some core classes, and how all its parts are working together.
I'll be giving a presentation about Pinto to the Los Angeles Perl Mongers on July 17th. Pinto is the ultimate tool for creating a private repository of Perl modules, so you can build your application with the right modules, every time.
While I'm in town, I'd like to visit some of the local Perl shops. I'd love to meet your team and learn about how you manage your Perl modules, and give you a personal hands-on tour of Pinto.
So let me know if you've got a conference room available on July 18th or 19th. I'll bring the catering! You can reach me as jeff@stratopan.com.
So far this year, I've given talks at both OPW and YAPC::NA about where I see Perl headed as a language and as a community. While both talks made heavy use of hyperbole to drive my points home, the overall concern I was trying to convey was my belief -- my fear -- that our beloved Perl 5 had stopped evolving as a language. In my opinion, this is largely due to the problem of backwards compatibility and our community-wide commitment to maintain it. I also wanted to express my desire to see Perl continue to grow and move forward, and my intent to shake things up a bit to help make that happen.
Continuous Integration (CI) is the autotesting of unit tests.
Why autotest?
There are many good answers. First and most importantly, developers get fast notification of when and where defects were committed to the source code repo. Testing on multiple platforms and environments also becomes possible and automatic. Invoking a unit test build manually is silly when we have computers. Let's be smart and lazy.
I haven't followed all of it, but the discussions about whether or not the "Modern Perl" tools like Moose are a good thing reminds me of Steve Yegge's essay about the "software political axis." If you haven't read it, I'll give you the super short summary: he says that a major source of tension between developers is their differences in risk tolerance, as seen in attitudes toward such things as type checking, adding new syntax to a language on the fly, well-defined schemas vs NoSQL, QA cycles before code rollout, etc.
With this framing, embracing Modern Perl is indicative of a lower risk-tolerance and a desire for more safety in software development, while objecting to it shows a willingness to accept more risk in exchange for lower overhead.
What do you think? Do you agree with this analysis? Have you seen any other interesting writing on this subject beyond Yegge's essay?
This new Perl hackathon is named patch -p0 (yes, there'll be more), and will be held (as usual) in the Carrefour Numérique de la Cité des Sciences et de l'Industrie (niveau -1), in Paris, from Friday, July 27 2013, to Sunday July 29, 2013.
Since trying to hide from the cloud, I've solved my problem of synchronizing address books and calendars with my home machine through (paid) Android CalDav adaptors and Davical. What I'm now looking for is a nice RSS reader to supply me with well-prepared information during my daily subway ride.
This is an update to the post where I introduced Progress::Any a few months ago. Progress::Any is a framework that separates progress updating and outputting.
I have recently revised the API (sadly not backward compatible with old one). It now resembles Log::Any a bit further. In module code, we just need to use Progress::Any to get progress indicator, set position and target, and update the indicator while doing work:
In this entry, I'd like to tell about several Perl-related bugs I have run
into, and how they were fixed. I know I have not been blogging a lot lately,
but, on the bright side, I was busy coding.
This started as a reply comment on another post about “people” being rude, that being the case please forgive how it starts.
I'm not sure I agree that the community has always been inclusive, I'll point (again) to chromatic's post back in 2k11 http://modernperlbooks.com/mt/2011/04/civility-starts-with-me.html about issues within the community relating to hostile behavior. We all have the ability to be rude, biting, short, etc. I'm just as guilty as anyone throughout my life both personally and professionally.
I’m a hard-core Image::Magick user. I use it to automate graphics production for my board games and video games, and also use it to manipulate all of the graphics uploaded by our customers at The Game Crafter. One of my developers has been nagging me for years to switch to Imager, but Image::Magick has always worked for me, so I had no reason to switch.
I’m working on a new board game, and I just bought a new laptop, so I figured now was a good time to try out Imager, since I didn’t already have Image::Magick installed. Here’s what I’ve learned as of day one.
Unixish is a simple framework for creating data transformation routines that can be applied to arrays or streams. The data transformation routines can also be accessed via command-line, much like your usual Unix utilities. In fact, the Data::Unixish distribution comes with several clones of Unix utilities like cat, shuf, head, tail, wc, sort, yes, rev.
Creating a data transformation routine, called a dux function (where dux is short for Data::Unixish) is easy enough. Let's say you're creating a function called revline to reverse the characters of each line of text. You write a function called revline and place it in Data::Unixish::revline package.
The context is that recruiters are pressuring older programmers to learn JQuery (read Community College class) and I'm also wondering whether to rewrite a few apps that I maintain.
ExtUtils::ParseXS is the module that translates XS to C. There have been development releases (newest: 3.18_04) for some time now. No CPAN testers failures. But for something as low-level as this, tests can only cover so much. I've been wanting to build a full CPAN against it, but the infrastructure for that has been in maintenance for months.
Because the release contains a few important fixes, please test your XS against the new development release soon. Otherwise, I will take a bit of a risk and cut a production release.
Lately we’ve seen a couple of blogposts about “pre-modern Perl.” The core idea seems to be that older Perls (say, 5.6, or perhaps even 5.005) are perfectly good for many jobs. Which, of course, they are. I’m not sure anyone ever said they weren’t.
Although the authors tend to downplay it in the comments, the articles are also leavened with a bit of ... shall we say, dislike? ... of modern Perl (or post-modern Perl, or however you want to style it). Sure, they also contain a fair amount of “hey, if that’s your thing, that’s fine for you—just leave me out of it.” But it’s hard to gloss over statements such as:
You see I don’t love “modern Perl”, in fact I kind of hate it.
This text is adapted from a lightning talk delivered at YAPC::NA in Austin, TX on June 4, 2013.
Alas poor CGI.pm. I knew him, Horatio.
OK, I admit it: I’ve bashed CGI.pm plenty of times. It’s slower than alternatives (who remembers CGI::Lite?), the HTML generation looks like a terrible idea in retrospect, and the liberal use of globals in the code is pretty ugly. I wouldn’t tell anyone to use it now, and I’m not here to argue against removing it from the Perl core.
But... most of the people in this room are probably here in one way or another because of Lincoln Stein and CGI.pm.
