If you have a Perl-related news item you'd like to share, you may post it in the Perl Newssection.
Please try to avoid duplicating news; but pointers (with summaries) to important stories on other sites are acceptable here.
Pinto is an application for creating and managing a custom CPAN-like repository of Perl modules. I decided to play with pinto and while I am chef fan has created pinto cookbook - a chef cookbook to install and configure pinto application. I hope this cookbook will be useful both for pinto users and pinto developers.
I'm on IRC just about all the time (my handle is "thaljef"). But I thought it might be interesting to actually schedule a session and invite people to come in and ask questions about Pinto, suggest a feature, report a bug, or just say "Hi".
So there will be two one-hour jam sessions in the #pinto channel on irc.perl.org this Thursday, May 2. The first will at 14:00 and the second will be at 18:00 (all times GMT). If you haven't used IRC before, this is an excellent guide.
ack 2.0 has been released. ack is a grep-like search tool that has been optimized for searching large heterogeneous trees of source code.
ack has been around since 2005. Since then it has become very popular and is packaged by all the major Linux distributions. It is cross-platform and pure Perl, so will run on Windows easily. See the "Why ack?" page for the top ten reasons, and dozens of testimonials.
ack 2.0 has many changes from 1.x, but here are four big differences and features that long-time ack 1.x users should be aware of.
By default all text files are searched, not just files with types that ack recognizes. If you prefer the old ack 1.x behavior of only searching files that ack recognizes, you can use the -k/--known-types option.
There is a much more flexible type identification system available. You can specify a file type based on extension (.rb for Ruby), filename (Rakefile is a Ruby file), first line matching a regex (Matching /#!.+ruby/ is a Ruby file) or regex match on the filename itself.
Greater support for ackrc files. You can have a system-wide ackrc at /etc/ackrc, a user-specific ackrc in ~/.ackrc, and ackrc files local to your projects.
The -x argument tells ack to read the list of files to search from stdin, much like xargs. This lets you do things like git ls | ack -x foo and ack will search every file in the git repository, and only those files that appear in the repository.
On the horizon, we see creating a framework that will let authors create ack plugins in Perl to allow flexibility. You might create a plugin that allows searching through zip files, or reading text from an Excel spreadsheet, or a web page.
ack has always thrived on numerous contributions from the ack community, but I especially want to single out Rob Hoelz for his work over the past year or two. If it were not for Rob, ack 2.0 might never have seen the light of day, and for that I am grateful.
A final note: In the past, ack's home page was betterthangrep.com. With the release of ack 2.0, I've changed to beyondgrep.com. "Beyond" feels less adversarial than "better than", and implies moving forward as well as upward. beyondgrep.com also includes a page of other tools that go beyond the capabilities of grep when searching source code.
For long time ack users, I hope you enjoy ack 2.0 and that it makes your programming life easier and more enjoyable. If you've never used ack, give it a try.
Stratopan is a new service for hosting custom repositories of Perl modules in the cloud. Private beta trials will begin early this summer. If you'd like to participate in the trials, please stop by https://stratopan.com and leave us your email address. We'll contact you with all the details when the trials begin.
Stratopan will host both public and private repositories with any combination of proprietary and open source Perl modules. And Stratopan is built on Pinto, the open source tool for creating custom repository, so it has the same helpful tools for managing your application dependencies.
Carl Mäsak's upcoming workshop is for anyone who knows at least a little Perl (5 or 6) and wants to see, learn or discuss best practice basics regarding coding simplicity, readability, or elegance in Perl (5 or 6).
This workshop is designed to deliver benefits for all, but should be especially suitable for Perl 5 programmers wishing to spend a few hours comparing and contrasting it with Perl 6.
I'm one of a dozen or so who have signed up already. Hope to see some more monks there!
For the record, I've been programming in Perl 5 for around 15 years, so I'm a bit biased. Having said that, I really like Perl. Don't listen to the naysayers, and don't think that its age is somehow an indicator of its shelf live. The best way to look at Perl is to see it in comparison to other languages:
PHP - PHP is a pretty good web programming language; don't get me wrong. But, it's only a web programming language. Even web applications need their cronjobs to do clean up processes, and you have to do some strange stuff to make that happen. Never mind having to write a quick script for UNIX administrator or parsing a text file. Plus, PHP doesn't have CPAN.
Ruby - The language is too new and "script kiddie" for my tastes. The only thing I hear about Ruby is Ruby on Rails. Perl has Catalyst and Dancer (as MVC frameworks), which are damn fine MVCs, but it's not the cornerstone of the language. You're not going to find "Ruby" as a requirement in job offers any time soon (if ever). Plus, Ruby doesn't have CPAN.
Python - In the words of Larry Wall, Python is just snake oil. Python cares about whitespace and the last language I used that cared about whitespace was BASIC. Also, like BASIC, it's was essentially designed to be a easy-to-use beginner's language. Finally, no CPAN here.
Java - Java is a problem child language. The concept was to have this virtual machine that runs on any platform, but because of the huge popularity of the language in college courses, you see Java applications every where that they shouldn't be. For example, in-house server-based web applications shouldn't exist. It's a single server with specs they define and it gets wrapped in a separate VM with a limited memory footprint. Java is bloated, and they don't have CPAN.
C# - I've actually have been using this language quite a bit now, and I've seemed to have formed a love/hate relationship with it. Being able to overload methods with different parameters is cool and fun. But, if you want a language that will bitch at your every line of code about type casting, then C# is for you. My god, it wants you to put explicit casting EVERYWHERE! Making classes are fun, but you suddenly realize that you're spending more time making classes to make the damn language just WORK than actually writing real code.
Also, C# doesn't have...okay, it has .NET, which is really good and extensive. However, I still like CPAN better because you can still write your own modules and complain at the author about a bug or design flaw. And they are all free. Plus, Perl is working towards Perl.NET in the future, so we may be designing Windows applications before long.
Perl is a great language that has:
Regular Expressions - If it's one thing that Perl can do well, it's text manipulation. Yes, many languages have regular expressions, but Perl has damn near invented them, and there's a reason why grep has a "Perl Regular Expression" mode, or why Oracle has a section on "Perl-influenced Extensions in Oracle Regular Expressions". It's built-in and doesn't require any modules.
Flexibility - You have three basic variable types: Scalars, Arrays, and Hashes. That's it. That's all you need. You don't have a int, byte, string, or any of that crap. Perl figures it out just fine. And you can use references all you want without fear of memory leaks or cause the whole PC to crash. The language just works.
Portability - Perl works great on the web. It works great in UNIX. It even works pretty well in Windows. It's not pigeon-holed to a single function. It's a jack-of-all-trades, but also a master of (mostly) everything.
It's easy to do a lot with a little code - Give me a 1K blank file and I can write all kinds of things with that space. Even a Perl one-liner is great to add into a command line pipe.
CPAN - I cannot stress how good it is to find just about anything you need for anything. What is "anything"? Well, how about DB modules for every database or thing you could imagine, ranging from Oracle to iPod to CSV to Adabas to Yaswi? How about several fully featured web servers? How about a Excel file reader, or a SNMP module, or a module that reads comments for debug lines, or modules that help you program faster? A project that I'm doing right now is writing a dynamic Terraria map generator, augmenting from an existing module called Games::RolePlay::MapGen. .NET would never have something like that.
Plus, it's a breeze to install any module via CPAN. Get it from Debian. Install it from CPAN directly. It does as good a job as apt-get in resolving dependencies. I have no problem telling my sysadmin to install X module from CPAN, since it's just a simple one-liner command.
Yes, it has its flaws, and yes, I'm biased towards it, but you've probably already heard the negatives too many times. They don't outweigh the positives, not by a long shot.
brian d foy has been experimenting with crowd-funding for open source projects, so I approached him about running a campaign for Pinto. I made a short video and we launched the campaign on Crowdtilt (which happens to be Perl shop). I'd really appreciate if you could help spread the word!
Pinto is a robust application for creating and managing custom repositories of Perl modules. You can use any combination of CPAN modules and private modules. And the repository works seamlessly with installer clients like cpan and cpanm.
When you build up your system from a Pinto repository, you'll get exactly the modules you want and the versions you want -- every time. Pinto also has some novel tools for helping you manage upgrades to your dependencies
The funds of the Crowdtilt campaign will be used to enhance Pinto to fetch specific versions of CPAN modules (without you having to know which distribution they came from). That will make is easy to build up a repository that contains all the modules needed for your legacy environment.