I don't think this is a very valid comparison. Sourceforge is not popular as a repository for a number of the more "modern" languages, and seems to focus more on "end user ready" projects than modules, plug-ins, etc, which is perhaps the primary delivery format for projects in the script-y languages.
Even if you included more repositories, though, still - what's the point? It's good to see trends, yes, but at least try and keep them in the same general domain. No-one is going to be making a choice between developing in C or in Ruby; they are different worlds in so many ways. And even counting projects is a bad metric in itself; someone starting a C project might be expected to have some reason for doing so, and thus he might be likely to at least half-finish it; Ruby "projects" are so easy to start that many developers don't seem to feel the day has really begun until they've tossed off half a dozen crappy new gems.
Nice talking point I guess but I wouldn't read much into these. And personally I am happy to see the fast rate of change and evolution. I would like to see it accelerate even faster. In particular I am hoping to see a mass migration towards a more distributed, federated project hosting paradigm; hopefully the next step after everyone is comfortable with git and the other DSCM systems, which will render this kind of "trends" article even harder to write :D
As for why Tcl won't just up and die, see the SQLite testing thread. Tcl's built like that too, and built well: native threads, Unicode, a very extensive C API. Definitely some pieces missing (OO), but they are being actively worked on. In other words, Tcl is not the most popular thing out there by a long shot, but it's not "dying" either.
Tcl is still great when you need to whip up a testing wrapper for a C/C++ library but I think these days Lua is doing a better job at the original goal Tcl set out to accomplish.
I have to admit, I really like Tcl's syntax. Some issues, but it was something you could programmatically manipulate without huge pains. And the C interface was quite pleasant, particularly if you had ever dealt with contemporary Perl modules. I was looking into it many years ago as an extension language that was simultaneously not extraordinarily lame but not permitting you raw hardware access, either, and liked what I saw.
But the core design didn't age well, I don't think; dynamic variables, little consideration for modular programming, primitive data structuring tools, etc. I like looking at Tcl-without-the-warts type languages, but it's really just masturbation. Lua is almost as flexible and certainly better put together.
Yeah, I remember when I needed Tcl. I bought a book with good reviews, cleared a long Saturday afternoon and sat down to read. Shockingly few minutes later I'd learned the syntax and understood the idea... cool.
(I assume it is the same time frame as your experience, since yours were before the Inline::C module.)
Hey, do the math. :-) Where else are projects announced? Do they have comparable numbers? I guess there's hosting at sourceforge, google code and github - but are they easy to browse? (I've never browsed them... I just had a go at github, it's mindbogglingly slow to serve every page, also few java projects). I'm asking these three (3) questions out of curiosity.
Google Trends isn't a great measurement tool, but the 3 languages have similar search volumes (with Perl declining, Python stable and Ruby ascending), yet CPAN is has a much higher volume than either RubyForge and PyPI. I think the relevance of each repository to its language community isn't comparable.
I think new lines of code being written is a pretty appropriate metric. The assertion is that Perl is dead or dying rapidly (the COBOL of web development), but the sheer number of new lines of code being written in Perl (the accelerating number of contributions to CPAN means that more new lines of code are being written today in Perl than 6 years ago) makes that a nonsensical assertion. Python and Ruby don't have to be unpopular for Perl to remain popular. They don't have to be killing Perl to be doing well...they are doing well, growing rapidly, etc. But so is Perl.
That's my only point. Dynamic languages are growing in popularity, and Perl is among them. And, if Perl doesn't grow as fast as Ruby and Python, that's fine, too. It'll still be a few years before Python and Ruby catch up to Perl in usage and lines of code and number of projects. (And none of them will ever catch up to PHP. JavaScript might, though.)
In fact all languages have declined. Which isn't surprising because Google Trends is just showing you the frequency of these search terms used over time.
There is a lot more things to search for now on the web compared to 2004!
If Ruby is ascending, then Python is declining. It seems more like both of them are stable. I can't see a significant difference, especially compared to Perl's noticeable fall. However, there may also be other noise (snakes and gems) polluting the search statistics.
While the language is still growing, the direct point ESR is making is that there is a lot of legacy Perl code in use, and this is not likely to change soon.
I took it to mean that Perl was like COBOL: Nobody is writing new software with it, but there's so much code out there that people will be maintaining it for years to come. While the latter is true, the former is not...so Perl is distinctly unlike COBOL in every possible way except that there is a large installed base of legacy code in the language (which applies to every popular language ever, including Python at this point).
Even if you included more repositories, though, still - what's the point? It's good to see trends, yes, but at least try and keep them in the same general domain. No-one is going to be making a choice between developing in C or in Ruby; they are different worlds in so many ways. And even counting projects is a bad metric in itself; someone starting a C project might be expected to have some reason for doing so, and thus he might be likely to at least half-finish it; Ruby "projects" are so easy to start that many developers don't seem to feel the day has really begun until they've tossed off half a dozen crappy new gems.
Nice talking point I guess but I wouldn't read much into these. And personally I am happy to see the fast rate of change and evolution. I would like to see it accelerate even faster. In particular I am hoping to see a mass migration towards a more distributed, federated project hosting paradigm; hopefully the next step after everyone is comfortable with git and the other DSCM systems, which will render this kind of "trends" article even harder to write :D