
ESR: Computer Language Trends in 2009 - rglovejoy
http://esr.ibiblio.org/?p=1016
======
davidw
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.

~~~
bayareaguy
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.

~~~
gchpaco
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.

~~~
berntb
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.)

------
noss
Looks like we Erlang people can remain as a cool underground movement.

Thank you ESR.

~~~
10ren
Erlang has 40 projects on freshmeat: <http://freshmeat.net/tags/erlang>

    
    
        Java   5316
        C++    4824
        Perl   3730
        Python 3161
        ...
        Erlang   40
    

It may be that Erlang people don't add their projects to freshmeat.

~~~
benkant
People still go to Freshmeat?

~~~
10ren
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.

~~~
pjhyett
Where are you located? GitHub's average page response is 400ms according to
our NewRelic data.

~~~
10ren
Thanks for asking. I'm in Melbourne, Australia

ping github.com = 192ms

loading <http://github.com/bmizerany/sinatra/tree/work> = 11000ms (11 secs)

wget of the same took between 1000-5000ms (1-5secs)

If there's a lot of javascript, that might be slowing it down.

------
rjurney
Perl projects and modules exist in CPAN, so the data has very little
relevance. Perl developers tend to push FOSS modules, not complete systems.

------
adamc
Favorite quote: "Perl has become the COBOL of web design"

~~~
SwellJoe
Awesome...except it isn't true. CPAN grew more in raw number of distributions
than both RubyForge and PyPI in the time span under discussion.

~~~
brand
CPAN vs RubyForge vs PyPI isn't exactly an appropriate comparison.

Take a look at:

[http://www.google.com/trends?q=python%2C+perl%2C+ruby&ct...](http://www.google.com/trends?q=python%2C+perl%2C+ruby&ctab=0&geo=all&date=all&sort=0)

vs

[http://www.google.com/trends?q=cpan%2C+pypi%2C+rubyforge&...](http://www.google.com/trends?q=cpan%2C+pypi%2C+rubyforge&ctab=0&geo=all&date=all&sort=0)

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.

~~~
SwellJoe
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.)

------
wheels
davidw runs a site that does much more comprehensive stats:

<http://langpop.com/>

------
sho
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

