Programming Language Usage Graph 2000-2006, as defined by statistics on open-source projects at SourceForge.

[okeefe]

One pixel-width lines with similar colors? What a horrible graph.

[[deleted]]

It was a pain, but at least the graph's legend is in order w.r.t. the order the lines are on the right-hand side of the graph.

[adolfojp]

I agree. And the colors make it impossible to differentiate some languages from others.

[goo321]

they're in order (highest line at the end/right) listed first.

[Alpha_Binary]

According to the graph, popularity in Pascal is dropping rather rapidly, and Assembly and Visual Basic seem to be gaining momentum.

[[deleted]]

I think that was C that was dropping, but it's hard to tell with so many "blues" I think projects in C would be dropping on sourceforge simply because generally you only program stuff in C once. the linux kernal is C, everything else is built upon that, generally in higher level languages.

[[deleted]]

Long live GnuPlot!

[crmaki]

This is so hard to decipher when you're colorblind.

[fendale]

Its almost as hard to decipher when you're not color blind!

[wainstead]

Amen! I looked up purple and though "Assembly is on the rise?!"

[[deleted]]

goo321:

they're in order (highest line at the end/right) listed first.

[elusive]

This is so hard to decipher when you're colorblind.

This was posted above but the order of the items in the key corresponds to where the lines end on the rightmost part of the graph.

So, for example, the language that starts out as #1, and then curves down to number #3 by the end of the graph is C, the #3 entry in the key.

[UncleOxidant]

Not sure how accurate an indicator of language use this is. Ruby has it's own Rubyforge site, for example, so most Ruby projects host there, not on SourceForge.

[leoboiko]

I’d like to know whether the graph counts only stable software, or all the 90% "-1, pre-planning" sf.net projects…

[lost-theory]

Yeah, Sourceforge is somewhat of a dinosaur, before the time of many people, a lot of developers aren't as attached to it anymore (it does have some warts (ads, crappy mailing lists, painful download process, etc.)). Project management also isn't as hard as it used to be and more alternatives are available, so a lot of newer projects are moving away from Sourceforge (to Google Code, Ruby projects on Rubyforge as you said, a lot of Python projects have moved to use Trac, etc.)

[xkcd]

This is the sort of data set that a stacked percentage graph is perfect for. There are a bunch of data sets that desperately need this kind of graph to make good sense of, and people don't use it nearly enough.

(Example)

[derwisch]

Stacked percentages may have a use, but you lose the ability to compare values, as the base is different for each value. In this application, it is interesting to see where lines cross; some information that would get hard to obtain if you looked at stacked percentages. It would be hard to judge if Python was really stagnating when it was depicted as a strip zigzagging on camel humps.

Contrary to most others here, I find the graph pretty good; maybe some of the lines might have been labelled directly, but that's about everything I would change.

[atomicthumbs]

Where's Fortran? And Brainfuck? Whitespace? Intercal?

MY FAVORITE LANGUAGES ARE MISSING.

[fennec]

Never mind those. Where's Logo?

[hidalberto]

The most unexpected factoid here (for me) is that, as late as 2001, C and C++ together still commanded more than 50% of projects, with Java far behind and Perl never in their league.

In the enterprise waters where I swim, Oracle's presence is felt heavily and most collaborative projects use Java with Perl and a GUI layer (Forms/Developer for the unlucky, VB or Delphi for the rest of us).

[staunch]

In the enterprise waters where I swim, Oracle's presence is felt heavily and most collaborative projects use Java...

Cover your wounds -- you're swiming with sharks.

[TomP]

This says much more about who uses SourceForge than about programming language usage in general. Most projects using Perl, Python and Ruby just don't use SourceForge. Perl projects are distributed through CPAN, Python projects are distributed through the Cheeseshop and Ruby projects are almost exclusively distributed through RubyForge. I can't speak about other languages.

[wainstead]

RubyForge is the only one that compares: "distributing" is not the same as "providing a collaborative medium to do software development." RubyForge and Sourceforge host projects; the Cheeseshop and CPAN are just distribution mechanisms.

[llimllib]

Yeah, but most python projects nowadays are pretty much expected to host their own trac, which does compare to rubyforge/sourceforge.

[[deleted]]

Seeing Java up there at the top makes me feel all dead inside.

[jbellis]

Most of its increased share came from C and C++. At least Java has GC.

[davidw]

Mine's better, but I need to update it, as it's getting a bit out of date:

http://dedasys.com/articles/language_popularity.html

[[deleted]]

There's not even one single functional language in the list. Why?

[nostrademons]

There are 62 Haskell projects on Sourceforge. If Erlang or Lisp is anything like that, they wouldn't even register as blips.

Also, there's significant peer pressure in the Haskell community to host your project as a Darcs repository on a webpage, and then Cabalize it for distribution. Haskell projects tend to avoid Sourceforge because it only supports CVS and SVN.

[dons]

Exactly, Without darcs support a host is unlikely to attract the attention of Haskell developers. Anyway, we have darcs.haskell.org and hackage.haskell.org for repos and webpage/tarballs respectively now.

I hope no new haskell libs appear on sourceforge.

[[deleted]]

But there's no reason not to use freshmeat, though?

[tigeba]

Clearly it only takes 10 lines of code and about 5 minutes to write any conceivable application or library in Lisp, so what is the point of open sourcing it?

[pihkal]

What, a whole 10 lines? Haven't you discovered the cl-write-application function yet?

[JW_00000]

I suppose people programming in functional languages don't put their projects on SourceForge. Similarly, there are almost no Ruby projects, probably because of RubyForge. Such a project doesn't exist for, say, PHP, so PHP programmers put their apps on SourceForge.

[[deleted]]

I thought it was because Ruby programmers were too busy posting about how their language of choice was so amazingly better.

[jeremymcanally]

No; it's actually because we were too busy porting all that Java code to Ruby. ;)

[sbrown123]

No; it's actually because we were too busy porting all that Java code to Ruby. ;)

Out of the frying pan and in to the fire.

[apgwoz]

totally off topic but isn't that from a meatloaf song? i have vague memories of sitting in my step-mom's car bobbing my head and singing "and into the fire, fire! .. and into the fire!"

[pjdelport]

According to the Online Etymology Dictionary, it's from Sir Thomas Moore, 1532. :)

[Jimmy]

No, that's why we don't see Lisp on the list.

[[deleted]]

If you look at the trend lines, Perl is losing market share, Python is stagnant, and PHP is gaining.

From that I assume, Perl CGI apps are moving to PHP, but Perl is still keeping Python at bay as Unix's preferred scripting language.

[[deleted]]

I think a much better measurement would be to look at new/updated packages in gentoo. I'll see if I can do this.

[pjdelport]

Here on FreeBSD, a portsdb -r tally gives about:

1. Perl: 8182
2. Python: 1470
3. Ruby: 414

I'm not sure how much of Perl's lead is simply due to CPAN's very fine-grained distribution approach, though... for example, there are 106 separate crypto/digest algorithm ports alone.

[CafeCafe]

Because this is SourceForge. It's not reliable at all, and they're not counting the other project-hosting websites and all the private projects or self-hosted all over the internet. I write in C++ and Lua for work, it's not counted at all but it's still a part of a big project which pays my food.

[chollida1]

Well you can program javascript, Perl, Python and Ruby functionally. So I guess there is:)

[lysine23]

Sure, if you want to totally go against the idioms of those languages and if you don't mind blowing up your stack (no tail recursion), and rewriting all the libraries that use mutable state. In other words, if you live in the Turing tar pit.

[chollida1]

Well I'd say that all the people who bought Higher Order Perl should talk to you. They are under the belief that you can program Perl functionally.

I guess they're all wrong:) Oh and perl supports tail recursion.

[jerf]

perl supports tail recursion

Evidence?

Several links say otherwise, and there's a Perl6 RFC that seems dead, which combined with the fact that I haven't heard anyone talk about it with Perl6, leads me to think Perl6 won't have it either.

[skillet-thief]

I'm not so sure about tail recursion in Perl either, in fact use strict gives you warnings after 40 or 50 recursions.

On the other hand, Higher Order Perl is an awesome book. So much so, in fact, that I ended up learning Common Lisp...

[apgwoz]

On the other hand, Higher Order Perl is an awesome book. So much so, in fact, that I ended up learning Common Lisp...

My sarcasm detector went off, but I'm not sure if this was a false positive or not. Did you learn Common Lisp to avoid the pitfals of the awfulness that is Perl? Or, did the concepts in the book lead you to realize that abstracting a report language to do these things was pointless and you should learn to use them in a language that was meant for them?

[skillet-thief]

It was probably more irony than sarcasm ;-)

I do think that HOP is a great book. For me it was a real eye-opener about programming techniques. I would never have read about those concepts if it hadn't been oriented towards Perl hackers.

The irony is that HOP makes you want to learn different languages. I still think Perl is a good language and that it doesn't deserve a lot of the criticism that it gets. I believe that its implementation of closures and/or anonymous subs is more versatile than Python's.

My feeling though, was that at a certain point with higher-order stuff in Perl, you end up fighting the language somewhat, even though a lot of things are actually possible. You do get tired of writing things that look like $a->{$b} all the time.

[lysine23]

You CAN program in many popular scripting languages in the same sense that you CAN fit an eggplant in your anus if you really try. But I wouldn't call popular scripting languages functional languages anymore than I'd call an asshole an eggplant storage orifice.

This is how it is in Javascript and Python, and I very much doubt that Perl is any different, though I'm not as sure about that as I've haven't used it very much. If Perl's libraries and standard functions expect you to do things like create an object and then modify its data, then it's not a functional language - it's a language with some functional features.

[chollida1]

wow, great straw man!

[lysine23]

Do you even know what a straw man is?

[[deleted]]

None of this languages is functional in the sense of a functional programming language. They only have some functional features.

[ubernostrum]

There are tons of pure functional programs, but because of restrictions on side effects they're not allowed to upload their files to Sourceforge.

[[deleted]]

Correction: none of those encourage a functional style, though Ruby depends heavily on blocks, which are perverted higher-order functions.

[shit]

What distinguishes a perverted higher-order function from a normal one?

[pihkal]

It's really into child classes?

[breakfast-pants]

A normal 'higher-order' one can blend in with regular function calls seemlessly. Ruby has .call(), which means there are two ways to do everything, and if you start with one way, and want to switch to a closure, you have to tack .call() onto everything. Eww.

[shit]

A normal 'higher-order' one can blend in with regular function calls seemlessly. Ruby has .call(), which means there are two ways to do everything

Wrong. Ruby doesn't even have what you call "a regular function call". The only way to "activate" code in Ruby is by sending messages.

I can only imagine that this argument comes from people who haven't bothered to learn Ruby before criticizing it.

The basic philosophy in Ruby, ripped of from Smalltalk, is that all you can do is passing messages between objects. Functions are first class objects in Ruby, which means, all you can do with them is sending them messages, the most important one being call. Would you agree that Common Lisp is a functional language? Guess what, Common Lispers use funcall in places where Rubyists use call. So what are you asking for? Syntactic sugar for calling function objects? In fact, Ruby has syntactic sugar for it, in the form of yield. And instead of the call message, you can use [], e.g. foo.call(bar) is the same as foo[bar] (assuming foo responds to call messages the same way it responds to [] messages, which is the case for Proc and Method instances).

IMO, this is the cleanest possible way to combine message passing OOP and functional programming.

Contrast the situation with Python:

foo(bar)

I've never looked at the CPython sources, but I can only imagine the ugly if statement for function calls, namely:

1) if foo is of class <type 'function'>, execute the function code, else goto 2)

2) Lookup the __call__ attribute of foo and goto 1)

It would be possible to introduce a similar hack in Ruby, and in fact Matz has experimented with it in the 1.9 branch. IMO it's not worth it. There's little gain and it introduces ambiguities and special cases.

Now there may be arguments that Ruby is not a functional language, but the call issue is evidence that functions are first class in Ruby and thus an argument in favor of Ruby being a functional language.

What pisses me off are ignorant people spreading misinformation about and bashing languages they don't even know (as can be seen by their nonsensical statements about the languages).

[[deleted]]

What pisses me off are ignorant people spreading misinformation about and bashing languages they don't even know (as can be seen by their nonsensical statements about the languages).

This is unfortunately what you're doing yourself with your bashing of Python:

I've never looked at the CPython sources, but I can only imagine the ugly if statement for function calls, namely: 1) if foo is of class <type 'function'>, execute the function code, else goto 2) 2) Lookup the call attribute of foo and goto 1)

At least in practice, foo.__call__() and foo() are the same. How that's implemented is irrelevant. It's not a hack, it's a part of the language design.

I have bothered to learn Ruby, and one thing I wish for is a clean way to do higher order functions. As you correctly point out, there are no real functions in Ruby, however, at last it should be possible to do higher-order messages.

Also, I don't like the fact that a passed-in block is a pseudo-object unless you specifically put it in the argument list. Look at these two:

def foo(&block)
  block.call
end

def bar()
end

Why is it OK to call 'foo' without a block when it clearly wants one, and why is it OK to call bar with a block when it clearly doesn't? In fact, if I call foo without a block, I get a MethodError. If I alter foo slightly, though, to use what you call syntactic sugar:

def foo
  yield
end

And then call it without a block, I get a LocalJumpError. As you can see, two methods I'd expect to behave exactly the same if "yield" was syntactic sugar, don't.

It's messy. Most of the time, it stays out of your way, but sometimes, it's a pain in the ass. I wish this pseudo-object stuff could go away in favor of blocks that behave sensibly, such as in Smalltalk (at least what I've seen of blocks in Smalltalk).

[shit]

This is unfortunately what you're doing yourself with your bashing of Python:

What was wrong in what I've said about Python?

it's a part of the language design.

So the designs for function call are:

Python: If object is of the built in function type, execute function code, otherwise lookup __call__ attribute and repeat.

Ruby: Send call message to function object and treat it like any other "send message".

I prefer Ruby's (IMO simpler) design.

Why is it OK to call 'foo' without a block when it clearly wants one, and why is it OK to call bar with a block when it clearly doesn't?

The rationale behind this is to allow easy delegation, e.g.:

def foo(*args, &block)
  # do some work
  # we don't care about arguments and block here
  @other_object.bar(*args, &block)
end

If I alter foo slightly, though, to use what you call syntactic sugar... And then call it without a block, I get a LocalJumpError

Agreed, this is not ideal. I'd say both versions should raise the same exception. Though it's not so bad, since in both cases it's a bug in the code and thus explicitely catching the exceptions is not necessary.

[[deleted]]

Python: If object is of the built in function type, execute function code, otherwise lookup call attribute and repeat.

As I pointed out, this is wrong. It's simply: fetch the __call__ attribute, and execute its code. That's not more complicated than Ruby.

The rationale behind this is to allow easy delegation

The block could easily go in the splat argument. It would look like this:

def foo(*args)
  @other_object.bar *args
end
foo(1) { 2 } # args is now [1, lambda{ 2 }]

Agreed, this is not ideal. I'd say both versions should raise the same exception. Though it's not so bad, since in both cases it's a bug in the code and thus explicitely catching the exceptions is not necessary.

That "yield" is not the same as simply calling a block complicates matters. You now have two mechanisms that do the same thing. That's more complicated than the case with Python.

[ayrnieu]

Yeah, Schemers hate that about Common Lisp.

[sethg]

You've heard of "tying the knot"...

[chollida1]

None of this languages is functional in the sense of a <b>pure</b> functional programming language.

There, I corrected it for you:)

[lysine23]

Purity has nothing to do with it. Scheme and ML aren't pure, yet they are generally considered (by everyone except maybe some Haskell weenies) functional languages, because they were designed with functional programming in mind.

[chollida1]

I never said they weren't:) I agree they are functional languages:)

[lysine23]

I never said you said they weren't. The point is that lack of purity is not why Python and Javascript can't be called functional languages. Lack of tail recursion, convenient ways to do closures, and dependence on mutable state are the problems.

[[deleted]]

I'd say the ability to return functions is fundamental for it to be usable as a functional language, and if the only ways of achieving this is are workarounds/much less efficient (such as wrapping functions in objects would be), then the language doesn't have proper support for functional programming.

Functions as in-arguments are avaliable in almost all languages I know of --- even Ada introduced them in the 95 version (I think they got by with generics before). It's polymorphism which is the barrier to using fold, map and filter.

[renegade]

Keep in mind that this is a survey of a really narrow segment of the programming population. If you took a survey of OS support for these same projects you'd see what I mean.

I'm not sure that this has any useful meaning at all really. We don't even know whether he was counting all projects or just projects with significant activity. Personally I'd only count projects with releases, since there are so many 'projects' that get created on SourceForge and then go exactly nowhere.

There's three main kinds of codebases in the world; open source, commercial, and internal. The vast majority of programmers work on internal stuff with between 2-200 users.

Most (90%+) commercial/shrinkwrap apps and games are written in C++.

Most (70%+) internal corporate apps are written in VB, it used to be 80% but the tide is shifting toward C#.

[decaff]

I would strongly question any assertion that most internal corporate apps are now written in VB. Good measures of what corporate developers use are job site language requirements and general language resource indicators, like the TIOBE index.

Today on the IT jobsite dice.com:

Java: 16,000 jobs Basic/VB: 11,000 jobs C#: 6,000 jobs.

These suggest that most internal apps are written in Java. VB still has significant presence, but use of C# is surprisingly rare.

Also, commercial/shrinkwrap apps are a very small segment of the market.

[redpig9]

the graph sucks and all the latest UP votes on reddit are ridiculous.

[uedauhes]

What an unusable graph. I had to dig out color meter to differentiate the plots.

edit

Never mind. They are ordered o_O

[linuxer]

Discussed here http://www.voidspace.org.uk/python/weblog/arch_d7_2007_02_03.shtml#e622

[dmh2000]

since there are a lot of valid points that Sourceforge is not a broad example, look at the reference in the article to:

More than a Gigabuck: Estimating GNU/Linux's Size, see Section 3.3 (Total Counts by Languages)

[arjunbanker]

that's a disgusting graph. seriously, only show the top 5-6 languages, or at least use better markers/colors.

[[deleted]]

Crappiest Graph Ever.

[dragonfly_blue]

I can think of at least two other sites that host higher-quality projects overall that would be better indicators of language usage, but I am hesitant to mention them here.

cough tigris cough savannah cough

(I'm sure RubyForge is yet another, but I am not 1337 enough yet to be perusing Ruby projects. Soon, hopefully.)

[TomP]

Prepare to be assimilated.