This may just mean that the analogy doesn't fit the situation though.
]]>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?
]]>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.
I first encountered CGI.pm back in 1996 when I was working at CitySearch.com. There was a guy in the office (Eric Hammond, now known for his work with EC2) who knew Perl and was doing amazing things with it, like writing a WYSIWYG HTML editor with exact positioning using generated tables. He got me going on CGI.pm and DBI and it was amazing! Lincoln had replaced the older Perl 4 cgi-lib.pl with a full-featured Perl 5 module that had lots of bells and whistles.
It’s hard to appreciate now what a big deal that was for Perl. Everyone suddenly wanted to put things on the web, and Perl had a fast and easy way to do it. Perl got a whole new user base out of that, and became closely linked with web development. You want to do something on the web? Better learn Perl.
And to help you learn, CGI.pm had fantastic documentation. The documentation was actually so comprehensive that it was published as a book, Official Guide to Programming with CGI.pm by Lincoln Stein, subtitle "The Standard for Building Web Scripts." And it’s true, this was actually the best guide to CGI programming in any language that existed at the time.
But beyond the historical significance, take a look at some of the things that CGI.pm introduced us to:
Later, when Doug MacEachern came along with mod_perl, CGI.pm was adapted to allow running under mod_perl with no modifications. (Or, with a ton of modifications if you were naughty and didn’t use proper scoping.) With a few additional lines, you could run the same code under FastCGI too. CGI.pm was the first web environment abstraction layer in Perl.
The other thing about CGI.pm was the code. Oh, I know, it has some ugly. It has an OO interface but it keeps state in globals instead of in the passed object. If someone wrote code like this on a project I was responsible for, I would be sad. But when I was a Perl newbie, looking at the CGI.pm code really opened my eyes to the incredible things you can do with Perl. It generates both a procedural and an OO interface using AUTOLOAD, eval, and a pile of strings. It detects the environment and adapts. It really takes advantage of the metaprogramming capabilities of perl.
So, now it may be time for CGI.pm to leave this Perl core. There are other ways to do this work now, and they're better. Let’s pause for a moment to give thanks, for all that it’s done for us. Like Bilbo and Frodo, it will set sail for the elven lands. Rest well, old friend.
BerkeleyDB and SQLite are totally different animals. SQLite is good if you want to use SQL and don't need high concurrency or extreme speed. BerkeleyDB is good if your data looks like a hash and you need high concurrency or speed. BerkeleyDB is faster than just about anything for sharing data between processes on one machine in Perl. It beats the pants off memcached.
- Perrin
]]>It was fun going through my old slides. I started giving presentations at ApacheCon in 2000, where I gave a talk with Bill Hilf about our work building eToys with Perl and open source tools. The article version of that is online, and the slides add very little, so I skipped that one.
I also skipped my Perl ORM talk from 2005, because the tools I covered are not really relevant anymore. I would advise people to look at Rose::DB::Object and DBIx::Class now, not Class::DBI, SPOPS, and Tangram.
Unfortunately, I can't see a way to sort the presentations so that the newest ones are first. If anyone knows how to do that, I'd like to hear it.
One amusing thing I've discovered: putting the word "scalable" in your title seems to draw in a lot of viewers!
]]>