I don't really trust any of those numbers, although the basic conclusion is probably right.

Simply counting projects doesn't mean anything on either CPAN or SourceForge. I can register a module or a project then do nothing with it, or I can register a single project, like "brian d foy's Perl modules" that is really many separate projects. The CPAN numbers are similarly skewed by failed starts, abandoned projects, and inactive developers.

I don't think that the conclusions are wrong, though. Most metrics would show that Java is more popular (there is only one print magazine for Perl, but shelves full for Java, for instance).

At some point, I think we have to look at the quality of the project too. Should a project with lots of CERT advisories count as much as a project that hardly ever breaks? Should a project with 10 downloads a year count as much as one with a million? Should a project that only compiles on one operating system if the moons are aligned and it is tuesday count as much as a project that runs on just about anything? Should "Hello World!" count as much as apache?

At the New York Perl Mongers meeting last month, we talked a bit about collecting adjusted statistics about CPAN. It's not enough to just count things. We have to weed out PAUSE accounts who never logged in or uploaded a module, modules that never made it past their first upload, and so on. We also should look at how attention a distribution gets by analyzing frequency of uploads, number of co-maintainers, how many other distributions require it, and so on. If I only had enough time...

You can always use the number for, and against perl. I wouldn't bother with either, since you can do just that.

perl and c are two totally different languages in that one is precompiled and perl is "compiled" when "run". One needs an OS as an interpreter, the other runs on an interpreter that runs on the OS. Similar to java, but java is compiled into a byte language that finishes getting compiled on run. But perl is not backed by uber large companies like sun, though c is very old, and c++ was done by a reasearch company. Go on and on and on. Don't forget Church's thesis which one can simply say, it doesn't matter, since they are all relatively equal, and do the same thing, which would almost make the statistics valid, if everything could be linearly comparable like that. :)

The fact that perl has so much to offer, and so many people care and do with it, is all that matters. "A lot of people use it" is all we need, eh?

----
Then B.I. said, "Hov' remind yourself nobody built like you, you designed yourself"

Of course, as with all generalizations, there are exceptions.

That does not surprise me. Although the numbers are only for sourceforge.net, my guess is that it is close to the ratio in entire IT society.

Compare Perl with C and Java, I believe most of the people have those concerns:

1. Perl is, to most of the people, being considered as a language for various small or medium size projects, but not for large scale enterprise solutions. I don't consider this as a negative view, and this does not make Perl less important. Perl is important and extreamly useful in areas where it fits.
2. Resource. The fact you can find less Perl programmers, make you less likely to do a project in Perl; and on the other hand, you don't do many projects in perl, you grow less Perl programmers. Doesn't matter whether you like the fact, Java has strong marketing and financial support behind it. It is unlikely Perl can surpass it within today's structure of the IT market.
3. Perl is weaker in certain key areas. For example, Perl is much less strong in GUI comparing with java or Microsoft products, and strong GUI support is such a high criteria in many projects. It made Perl less likely to be able to penetrate this area seriously. On the other hand, the question would be whether Perl actually seriously targeting certain application areas.

It would be more meaningful, if the numbers are for different application areas.

3. Perl is weaker in certain key areas. For example, Perl is much less strong in GUI comparing with java or Microsoft products, and strong GUI support is such a high criteria in many projects. It made Perl less likely to be able to penetrate this area seriously. On the other hand, the question would be whether Perl actually seriously targeting certain application areas.

What exactly do languages like C and Java offer in the way of GUIs that perl doesn't? Considering C, I can use almost exactly the same tool kits from C as I can from perl (not suprising really..), such as wx, gtk, tk, etc. I have no real idea what java uses for GUIs these days, but what features do they offer that perl's libraries (and by extension, C's libraries) don't have?

That's not the way I look at it. GUI is much less about which libraries you have, but more about how quick and easily I can build my user interface with those libraries, and about what tools are available, and how easy it is to use those tools. Today, if someone wants to build a building brick by brick, he still can, but is that a good choice?

"like C and Java offer in the way of GUIs that perl doesn't?"

I said something different with careful consideration. What I said was "java and microsoft products".

Tradition. Since a lot of OSs and user environments are written in C, a widget set in C would make sense. I.e. XWindows and what not. For java, that was backed by Sun from the get-go. Have strong OOP, graphical stuff, networking and so on. C++, I can only think of the MFC and qt off of the top of my head. The only toolkits for C++ i can think of are people who wish to make a profit on peple who want a graphical interface written in C++ instead of just wrapped. C++, I *think* has more biz people interested, as OOP is usually good for representing biz like ideas in an organized way. Companies like "organization". Perl had it tacked on later, no?

So java is company backed. C++ is profit backed. C is done sort of as a default.

perl has tk and all of the C bindings sorta, but I think it falls more in line with python and ruby. They aren't native languages so to speak. They are open and not profit backed.. well.. didn't nasa sponsor it in some way when mr wall was witht hem? Anyway, I dont' know of many OSs written in perl. And whhomever sponsors perl doesn't seem to have that huge of an interest in graphical interfaecs. Not bad.. just true.. I think.

Am i at all accurate on any of this?

----
Then B.I. said, "Hov' remind yourself nobody built like you, you designed yourself"

3. Perl is weaker in certain key areas. For example, Perl is much less strong in GUI comparing with java or Microsoft products, and strong GUI support is such a high criteria in many projects. It made Perl less likely to be able to penetrate this area seriously. On the other hand, the question would be whether Perl actually seriously targeting certain application areas.

I dont tend to agree with this statement. It is just as easy to create a GUI (on windows anyway) using Win32::API as it is in C, where you must use native API calls also to get a GUI. While this requires a fair bit of work (and probably a bit of research) it is not all that hard, if a little repetitive.

---

monoxide
I am undecided...

I can think of a few reasons.

First, Perl has its own community and distribution methods: we use CPAN, we publish code on PM and on Perl-specific sites. Perl developers seem less likely to want or use the SourceForge network.

Second, there are things Perl just isn't well-suited to: writing drivers, for example. A great number of SF projects are Linux drivers for things.

Third, while Tk is pretty slick, it isn't the kind of toolkit that many developers and end-users would want for a polished, comprehensive GUI product. I personally like how clean it is, but many developers want to use Qt and GTK and wx* toolkits.

Fourth, C/C++ have been around longer than Perl; they also have more developers.

Fifth, one of the beautiful things about Perl is how it makes small tasks easy to automate and enhance. A lot of how Perl is used results in programs of a few hundred lines that do one particular thing really well. I can't imagine a lot of those "mini-scripts" would get published as SF projects.

First of all while very few people use the right to freely modify software, that does not mean that it has small value. It has tremendous value. First of all you know that you will benefit from improvements from other motivated people. Secondly you don't have to worry that the project will be abandoned with a sizeable user base left hanging (as often happens with proprietary software when companies die). Thirdly, even if you don't use the option, knowing that you have the option is valuable.

Also I don't know what orifice he pulled his comment about the core Perl development team out of. Certainly his comment does not match my experience. Of course any contribution will have to address concerns about the quality of Perl as a software project (backwards compatibility, how well changes integrate with the philosophy of the language, etc). However I haven't seen that people who have the time and energy to make quality contributions are likely to get rejected out of hand.

Of course he's writing from the perspective of someone who is fond of Java. So he's going to interpret the open source movement from a point of view that minimizes the difference between Sun's almost open source strategy and an actual open source strategy...

To dodge the actual question and comment on part of the original article...

I'm not sure that (a) "Free beer" is a key component of open source, and (b) the right to redistribute can be characterised as "free beer".

The way I see it, the right to redistribute is part of the "libre" aspect, and the fact that OSS can be Free As In Beer is simply a result of the more fundamental aspects.

Apologies for going off at a tangent and opening up one of those old cans of worms...

Actually, you make a very good point. The "free beer" result of open source licenses is simply a side-effect of the "free speech" aspect. Redistribution is allowed with open source, though there is no restriction on what sort of fees one might ask to distribute it. The fact that those to whom you distribute it have the right to modify and/or redistribute as they see fit ensures that somewhere down the road someone is going to distribute it for free, if it is worth redistributing. As a result, "free as in speech" becomes "free as in beer".

- apotheon
CopyWrite Chad Perrin

JAVA is very well supported by Sun and IBM but the latest version, I think that requires a lot of RAM and is a way of discriminating every user that has not updated their machines recently. That is not a very encouraging perspective for freeware developers.

Compare software downloads in perl with those in JAVA or other commercial language. Compare the results. I use a speaking machine written in C a decade ago, it only weights 100 Kb in Windows. Compare the new software of the kind.

And I'd point out that Perl itself is a C project. ;-)

There have been a number of very good comments on this subject here about the futility of comparing apples and oranges, the variations that exist in how different languages' popularity levels manifest, and the misconceptions that surround the importance, mechanics, and incidentals of open source development. A couple of points that have been hinted at, but not explicitly stated, follow:

• In the case of a language that has been around substantially longer than Perl (for instance, C), the sheer hoary age of it ensures a collected mass of extant code that is not representative of its relative popularity. If something is around for twenty years and developers create ten programs per year using that language, you'll have 200 extant software projects in that language. If something is around for two weeks, as a newer language, but is so immediately popular that new projects are being cranked out at a rate of ten per week, you've still only got ten percent of the apparent popularity of the other language, if you're measuring by the number of extant projects.
• Perl doesn't tend to lend itself nearly as much to software projects as it does to snippets of code. If you wanted to compare based on number of projects in existence, C would win. If you wanted to compare based on number of code snippets circulating that are reused constantly in creation of new scripts, I rather suspect that Perl would take the prize.

Of course, the question that really begs to be asked is this: If Perl is popular "enough" (as in: it's got longevity and motivation for advancement, at least), why do we care how it stacks up to Java or C in terms of popularity? I find that Perl is wonderful for the tasks for which I use it. C is great for producing executables. I have yet to need Java, or any software that is best written in Java. For me — for what I do — Perl and C are "better". What do I care if Java is getting more hype, has a stronger popular following, and gets more development of integrated software development projects than Perl?