Just read this blog post. Comments are disabled, so I thought I'd add a blog post.
There are endless ways we can sneer at PHP's deficiencies, but since 5.3 PHP already supports anonymous subroutines, via the function (args) { ... } syntax. So:
On 28 February 2006, the Golden Age of Right Parsing ended.
The End of the Age was like a rewind of the Beginning.
The Golden Age of Right Parsing began when a right parser
replaced the hand-written recursive descent parser in
the C compiler.
It ended,
almost three decades later,
when the world's most visible C compiler replaced
its right parser with a
hand-written recursive descent implementation.
I know, I know, it's all free software and open source - you shouldn't expect anyone to do anything. However, we do want our projects to succeed and we do put them out there in hope that it will be useful to someone.
So, you can be a jerk and provide a simple .pm file, without any documentation (because "it simply works"), no toolchain configuration (you "don't need any") and no tests (hey, if it works, it works, right?).
However, CPAN ain't like that. CPAN is (mostly) well structured distributions that adhere to community standards that include: building toolchain files, metadata to help CPAN indexers and installation applications, tests, documentation (in a standard format - POD), sometimes examples folder with sample scripts using your code, perhaps a GPG signature file to have content verified and - *gasp* - a change log indicating what each version added (and perhaps when it was released too).
While preparing some major technical stuff not yet released, here some more philosophical items. Last time i was comparing Larry with Al Yankovic. A funny thing with some mostly well known insights. so lets go even deeper. What's a Pearl really?
Like many Perl scripts also Pearls start with a pain. A mussel gets a stone or something else painfull into his shell and has to deal with it and something shiny takes birth out of it. Perl is also more focussed to solve practical problems than demonstate paradigmes. But lets go even deeper.
Where pain comes from? From injustice, ignorance and own ego of course. And it shows real greatness to stay humble but don't render yourself as an victim and do something productive with that situation.
Ultimate darkness and what some would call evil is called in the rabbinic tradition Binah. And its associated with a Pearl (all other sephira with clear see-through-gems). Because in the end every darkness/shortcoming is turned into great gift. But only by those who stay to their greatness. And the Perl community has several of them.
The path from darkness to strength is called Gimel (in the version i prefer at least), which translates to Camel. How appropriate. I start to wonder what Larry knew when he choose that logo :).
In the previous article, I wrote about the pitfalls of benchmarking and dumbbench, a tool that is meant to make simple benchmarks more robust.
The most significant improvement over time ./cmd is that it actually comes with a moderately well motivated model of the time distribution of invoking ./cmd many times. In data analysis, it is very important to know the underlying statistical distribution of your measurement quantity. I assume that most people remember from high school that you can calculate the mean and the standard deviation ("error") of data and use those two numbers as an estimate of the true value and a statement of the uncertainty. That is a reasonable thing to do if the measurement quantity has a normal (or Gaussian) distribution. Fortunately for everybody, normal distributions are very common because if you add up enough statistics, chances are that the result will be almost Gaussian (Central Limit Theorem).
CPAN Ratings are a great idea. Unfortunately it seems that in some cases they are either unused (in places where they should be) or misused (in places where they shouldn't be used).
While some distributions (which are very recommended to use by the Perl community) do not enjoy having ratings at all, I've noticed some people putting their personal gripes as ratings.
Theoretically you should be able to do that, true, but these ratings don't act the way you might assume they would. If you have a dist and I rate your first version as one star (for lack of tests, or because I do not see it useful for me), you have a single star (out of five) marked until someone changes that. I've seen ratings that existed since the first development version of a distribution (which usually say "this sucks, how do I use it?!") - leaving me to believe that they cannot be deleted, perhaps only to the original poster who might be MIA.
This weekend I gave a presentation at OpenCert 2010 about the Perl testing ecosystem, this was an article I wrote with ambs++ and jjoao++. The article can be found on the conference site here.
I like the Perl community. We have a open, tolerant and helpful community. Looking around to other languages, I do think we’re in a much better shape then most people seem to realize.
I loathe the Python community’s snobbish and hostile attitude to newcomers and outsiders. Maybe I’m biased by having to counter FUD in people who have been exposed to the Python community, but I can’t call it anything else. I wouldn’t be the first to suggest that’s the main reason they never took over even when they were otherwise in a much better shape than we were. They threw bricks into their own windows and I am somewhat doubtful they’ll get a second chance.
If you've read my last post, there's a good chance you were relieved that there was finally a command to install all the missing plugins.
However, about 5 minutes (if not less) after posting my new thingamajig, Florian Ragwitz posted a reply saying "uh.. it's already been done, and a new Dist::Zilla is released with it today".
So, take even a more relieved breath because Dist::Zilla now already has it. Download it and use `dzil authordeps`!
On a technical note, it was interesting to see a different implementation of the same idea. What Florian did was to simply read the file, expand package names using Dist::Zilla::Util and print them all out. What I tried to do was perhaps more ambitious (but probably an overkill). I ran a dist building process and hooked up to the sections reading method and if the section was a plugin that didn't exist, I didn't run the section reading and marked it down. At the end I had all the sections that were plugins that didn't exist. I like Florian's method better, though. :)
This is a real issue - admittedly I have been trying out a number of plugin bundles recently, but having to test a new config by doing dzil build and scroll back to the top error message to find the missing plugin, install that, redo is just not a fun development method.
Maybe as a first cut we could do with a dzil tool to spit out a required plugin/plugin bundles set which we can then pass to cpanm or similar.
For me this is just an irritation. I suspect for someone who has just cloned their first project from github because they want to try changing something, this could be a real pain...
My primary goal for the 0.58 release was to understand and fix as much as I could without breaking anything. Occasionally, that meant leaving certain blocks of code in place in Makefile.PL even when I was not too sure it was necessary to do so. I did try to improve version detection, fix a couple of things and factor out code to subroutines, but I left much intact.
This is a relatively straightforward task, but seems to require some upfront thinking to accommodate various permutations such as independently installed mingw versus mingw bundled with Strawberry Perl versus mingw bundled installed with ActiveState's ppm versus MS VC along with ActiveState Perl etc as well as dynamic versus static linking of OpenSSL.
Both can be funny with words come from LA and and wear sometime a moustache and wild coloured shirts. But this is a Perl blog and not about trivia right?
Both believe life should be fun and are not afraid if people lough about them. But to go deeper than that, to actually manufacture something like "white and nerdy" you need to know a lot about rap have a feel for rythm and know enough about "neird culture" to be funny. to be funny you need a feeling what people expect and how they there emotional reaction will be.
Dist::Zilla produces a flexibility like no other with its completely insane everything-is-a-plugin approach. Anyone can write almost any type of plugin that hooks up easily to almost every part of the magic that Dist::Zilla does for you. It really is magnificent.
However, that flexibility comes with an added difficulty. There are a lot of plugins out there and when you want to simply build a dist (`dzil build`), it will load any plugin mentioned in the configuration. Since those are loaded by Moose itself, it means any failure to do that (such as with modules that aren't installed) will result in a big stracktrace. You have to scroll to the top of the trace, see what's missing from the failure-to-load message, install that and try again. Whoops, another one is missing...
We use a mix of RHEL 5.3 and CentOS 5.3 at work. We've been using Perl 5.8.8 since we moved to this OS from RHEL 4. We have talked about upgrading the version of Perl in the past but just now have the time to do so. After discussing it with the team, it was agreed that we would leave Perl 5.8.8 alone so that we did not have to muck with the OS at all. We are already putting our software into /opt so putting Perl there also makes sense (plenty of disk space to spare).
To get things started, I grabbed a list of our current 5.8.8 modules.
/usr/bin/perl -MExtUtils::Installed -e'print join("\n", new ExtUtils::Installed->modules)' > ~/module.list
I downloaded perlbrew and installed it to /opt/perl.
Event: Birmingham.pm Technical Meeting
Date: Wednesday 22nd September 2010
Times: from 7pm onwards (see below)
Venue: Birmingham Science Park Aston, Faraday Wharf, Holt Street,
Birmingham, B7 4BB.
Details: http://birmingham.pm.org/tech/next
Talks:
Migrating a PHP website to Perl/Catalyst [Steve Pitchford]
Moose - quick, easy and efficient OO in Perl5 [Richard Wallman]
Details
This month we'll be taking a look at some aspects of Modern Perl. Steve Pitchford will be taking a look at Catalyst, while Richard Wallman will be introducing us to Moose.
Once again we'll be at The Birmingham Science Park Aston for the September meeting. The venue is a very short walk from Aston University and even shorter walk from 3 pubs!
Virtually every programmer is obsessed with writing FAST code. Curiously, this extends even to those who prefer dynamic languages such as Perl over naturally faster, more low-level languages such as C. Few among us can resist the urge to micro-optimize and a cynical version of myself would claim that the best we can expect is that programmers prove effectiveness of their optimizations with benchmarks.
Wait!
Proof? What I should have written is that they attempt to demonstrate the effect of their optimization by timing it versus another variant. Arriving at a resilient conclusion from a benchmark is hard. It doesn't only take plenty of CPU time, it also takes plenty of brain cycles and experience. People will often publish the result of a simple
The Learning Perl book ("Llama book") is the best-selling intro-to-Perl book available. For most of the 90's and the early 200x's, teaching the classroom course based on the book (which was based on the previous course, which was based on the previous book...) had been my primary living.
More than once, I had thought about turning the course into a video, but lacked the time, energy, coordination, etc. This especially became important as fewer and fewer "groups of 10 or more" popped up for me to present the classic course.
O'Reilly approached me earlier this year to ask me if I'd work on the video with them. Yeay! Finally. We shot it a few months ago, and the editing is now complete. You can finally see me give the course I've given probably hundreds of times before, bad jokes and all.
See it at O'Reilly's site. Oh, it's not free, but considering that you'd be paying about 5-10 times that much to see me in person, it's a bargain.
Some of my main modules (modules with more users) bundle C libraries within them: Lingua::Jspell and Text::BibTeX. One of the main problems of doing this is how to detect the C compiler, and how to use it. For example, for windows, I can only support (for now) Strawberry Perl (although I consider that great enough).
