* posts encoded in any character encoding, built-in to modern languages.
* supporting different rich text formats, equally available in modern languages.
* computing the MD5 sum of the post for the HTTP ETag header, built-in to modern languages.
* handing filesystem paths in a cross-platform manner, built-in to modern languages.
* parsing the configuration file, built-in to modern languages (for JSON, XML, YAML, KVP's or eval).
* reading PGP signatures, equally available in modern languages --- not that I'm sure why I'd want that in my blog.
Except for Textile or Markdown, I'm not sure there's anything here that would make me reach out of the box in Ruby or Python.
This all seems pedantic, I'm sure, but here's my point: CPAN is constantly cited as the killer feature for Perl, but:
(1) here's an article that makes that argument and doesn't show anything CPAN provides that you wouldn't get in a more modern language, and
(2) if you're wading through 200+ modules just to get a blog up, I'm seriously not sure that's an argument for how CPAN makes a developer's life easier. TMTOWTDI, yeah, but there's also value in making it clear and obvious what the right way is.
if we're going to do that, we get to rule out, say, lisp. Which I'd rather write over most "modern" languages any day.
And so far as I can tell, you're basically saying "I think the perl standard library should have more stuff in it and because it doesn't have the stuff -I- want in it, CPAN is pointless".
Well, sure. Except that not having all this stuff in core means I can update, say, my rich text processing stuff or a configuration parser on its own, and only re-QA that component rather than having to wait for an entire language point release.
And "wading" is a nicely loaded description as well. Here's what I did when I installed angerwhale:
tar xzf <tarball>
cd <unpacked dir>
perl Makefile.PL
make installdeps
and lo, from CPAN did the 50 or so modules that I didn't already have installed for something else that was -also- reusing that same code snap straight onto my system while I went for a coffee break.
perl is just syntax. CPAN is the language.
And by that standard all this -is- built in. It's just optional :)
"Modern language" --- you're right. I'm looking for a word that means "Python, Ruby, Scala, etc" but not Tcl and Perl. I'm fumbling trying to find it. Sorry.
The rest of your reply kind of misses my point. If the 50-or-so modules you get from CPAN have built-in analogues in Python, why do I care about CPAN? Can I get a raytracer straight out of CPAN? Sure. So? What's a profoundly useful library in CPAN that isn't easily matched in Python?
I bet you have an answer, and I'd like to hear it.
"Modern language" --- you're right. I'm looking for a word that means "Python, Ruby, Scala, etc" but not Tcl and Perl. I'm fumbling trying to find it. Sorry.
What modern features is Perl missing? I hate to break it to you, but Python and Ruby have basically the same featureset as Perl.
What's a profoundly useful library in CPAN that isn't easily matched in Python?
A single profoundly useful library is not the point of CPAN. It's finding that random library that you need in some corner of an obscure internal application where CPAN really shines. Every language has their super-great web framework. The depth and breadth of module available on the CPAN is Perl's strength.
If I had to pick a single CPAN module I couldn't be without, though, it would be Moose; followed closely by Catalyst and DBIx::Class.
"Modern language" --- I just agreed with you. And apologized.
Moose --- doesn't Moose just make Perl's metaclass programming as simple as Python and Ruby's already is?
Catalyst is an web MVC framework. DBIx::Class is an ORM. Clearly we can get those libraries elsewhere. Is there something really amazing in CPAN that I can't get in a gem in Ruby? I get that a lot of gems are crappy (Ruby's a younger community), so I'm not going to come back at you with some random -0.1alpha svn trunk thing.
The last time a django core dev looked at DBIx::Class in front of me the response was "shit, we need to steal that".
Sadly I didn't get to catch up with them properly at OSCON to find out if they'd manage to steal much of the awesome stuff yet.
SQLAlchemy probably already has similar features though, so maybe they don't need to.
Ruby can't handle MI. Ruby's metaprogramming seems limited. But I'm not informed. I've had several perl ->ruby guys come back to perl going "hey! it's like ruby but with a flexible object system" to me. But I don't know enough about it to have an opinion myself.
I think you'd have a hard time coming up with something that Ruby's metaprogramming can't handle where Perl's answer would be better than "eval". I could be wrong; I'm equally shady in Perl (I haven't written in it since 1996).
Ruby doesn't do multiple inheritance, though you really do get 90% of what reasonable people do with MI with mixins, which work beautifully.
To be honest, the best thing about CPAN isn't any specific module, it's the sheer breadth of them - and the ability to install everything in a uniform way and have it usually work. Plus things like the cpantesters and cpandeps system that make it fairly trivial to tell if something -will- work on all the platforms you're targeting before you commit yourself to it.
Of course, if you describe yourself as "an old PERL programmer" you may have missed a lot of the recent cool stuff on CPAN - the binary is called 'perl', the language 'Perl', and the mistake of calling it 'PERL' kinda went out with the 2001-era CGI.pm crowd (this isn't meant as an ad hominem - I've simply found that anybody who says 'PERL' as anything except a joke is -hugely- likely not to have taken advantage of most of CPAN and have no way of telling if you're an exception to that :)
I swear to god I'm not challenging you, I really want to know: what makes Moose more interesting than the metaclass programming you get ``for free'' with Python and Ruby?
The attribute metaprotocol and method modifiers are AFAIK rather more like the equivalents in CLOS or a smalltalk than they are like those in python/ruby, and the roles system is -way- nicer than mixins.
I actually considered once implementing mixins for perl the way ruby does them with an anon class to keep single inheritance, then abandoned the concept as being a colossal hack. python's MI OTOH is sane with a C3 MRO, so we stole that for perl - in the cases where a mixin or role isn't sufficient it works very nicely.
I'd suggest having a read of the Devel::REPL articles on http://chainsawblues.vox.com/ - that might show off the capabilities of roles+method modifiers better than I can explain.
Not sure if this helps you or relieves you of some concern but:
1) I doubt Angerwhale itself includes 200+ modules. The core Makefile lists about 62 modules. It's likely the number quoted was counting both the modules used by Angerwhale and the dependencies of those modules and so forth.
2) Current best practices for developing a Perl application say that you should build the application itself as a CPAN module, even if you don't plan to release on CPAN, since that way you can take advantage of all the work that's gone into CPAN testing and deployment tools. However, if you follow that best practice correctly, it will mean you will take great care to list all your dependencies and their minimum workable versions. You will do this even with a dependency that is part of a core Perl installation. For example, one of the dependencies listed in Angerwhale is 'File::Find', actually comes with a base install of Perl. You don't have to do anything for the application to work. However, for strong audit and good programming practice, you really should list what you application needs. That just makes it easier to install and to troubleshoot installation issues. Also, in the future it is likely that Perl core will be smaller, so that we can have the flexibility to target Perl more carefully to different needs (like say to people using Perl for system administration, versus those in a very constrained embedded market). So this is just a good practice to future proof your application.
3) The number of required modules is nothing to be afraid of. When you install a CPAN module, like by using the commandline 'cpan' application, it will automatically follow, download, run tests, and install, any required dependencies. All you really need to do is something like:
cpan Angerwhale
And the build tool do the rest for you. This is also a good way to develop your application, so that you can use Makefile as a build and a deployment tool. This is just part of the standard, best practices for Perl development.
All programming languages come with extended and standard libraries. To be efficient in any language requires that you learn to 'wade through' as you say, those libraries, their documentation and test examples. There is no doubt the CPAN model has some challenges. CPAN is widely distributed, varying in quality, and lives in the complex negotiation of needs and desires which is a hallmark of the Internet. Like the rest of the Internet it can be wildly anarchic and is often brutally merit based. There have definitely been times when I have cursed it. However I do believe it is a wonderful testament to the viability of open source, distributed development.
I don't get Markdown. Why make end-users learn a yet another markup language to make bold text or a table (unless all your users are news.yc readers, rather than the general public)?
Why not give them an actual bold text button? It's not hard.
* posts encoded in any character encoding, built-in to modern languages.
* supporting different rich text formats, equally available in modern languages.
* computing the MD5 sum of the post for the HTTP ETag header, built-in to modern languages.
* handing filesystem paths in a cross-platform manner, built-in to modern languages.
* parsing the configuration file, built-in to modern languages (for JSON, XML, YAML, KVP's or eval).
* reading PGP signatures, equally available in modern languages --- not that I'm sure why I'd want that in my blog.
Except for Textile or Markdown, I'm not sure there's anything here that would make me reach out of the box in Ruby or Python.
This all seems pedantic, I'm sure, but here's my point: CPAN is constantly cited as the killer feature for Perl, but:
(1) here's an article that makes that argument and doesn't show anything CPAN provides that you wouldn't get in a more modern language, and
(2) if you're wading through 200+ modules just to get a blog up, I'm seriously not sure that's an argument for how CPAN makes a developer's life easier. TMTOWTDI, yeah, but there's also value in making it clear and obvious what the right way is.