Slashdot Mirror
Survey Says C Dominated New '08 Open-Source Projects
svonkie writes "C overwhelmingly proved to be the most popular programming language for thousands of new open-source projects in 2008, reports The Register (UK). According to license tracker Black Duck Software, which monitors 180,000 projects on nearly 4,000 sites, almost half — 47 per cent — of new projects last year used C. 17,000 new open-source projects were created in total. Next in popularity after C came Java, with 28 per cent.
In scripting, JavaScript came out on top with 20 per cent, followed by Perl with 18 per cent.
PHP attracted just 11 per cent, and Ruby six per cent. The numbers are a surprise, as open-source PHP has proved popular as a web-site development language, while Ruby's been a hot topic for many."
Seriously, who ever heard of that company? Anyway, here is their actual press release, including a bogus list with 10 random apps I never heard of.
And by the way, Python got 10%.
I read TFA but don't have it open, ISTR that there only a small number of mobile projects, and a smaller number of those for the iPhone, on the order of 40, out of the thousands of new projects, so I don't think that Objective-C for the iPhone tipped the balance for the C family, even if they did count the C family as one unit.
I'm surprised C++ didn't make the list.
It didn't make the list because apparently the authors think that C, C++, and C# are all the same language.
c# is windows specific
Wrong.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
Actually, I think these guys know what they're talking about. It's just the Slashdotted, watered down version which makes them look as if they don't.
Why throw JavaScript in there? The rest are server-side languages, while JavaScript is client-side.
Two reasons I can think of:
1) An increasing amount of number of applications are being delivered via the web browser
2) JavaScript increasingly lives a number of other places besides the browser. See Rhino, JScript.NET, Seed, and probably a few other places I'm not thinking of right now.
Tweet, tweet.
'As for me, I don't discount any solution just because of who comes up with it, so I'm fine with .NET. To each his own.'
*shrugs* We must agree to differ then. I prefer to learn from history. Historically speaking, there haven't been any useful Microsoft technologies that were or are completely interoperable, stable, relatively bugfree, and secure. Seeing as how they have released lots of technologies and solutions over the years they have had plenty of opportunities and have on numerous occasions even lied about the aforementioned things.
Maybe .Net is/was/will be the exception. If so I'm not concerned, there are other solutions that DO meet the above criteria and work well. All in all, my track record of avoiding Microsoft solutions when something else will do will then have been the right choice about 99 out of hundred times and saved me thousands of dollars in license, support, and training costs. ;)
I think there is something to take from the Perl Best Practices when considering the viability of different languages. In this book they stress over and over the need to have maintainable code. Over the years I have had to go back and manage a large number of my applications and have found that the technical cost to any of these has more to do with the documentation and quality of the code above everything else. I have been (trying) to use Ruby and Javascript in addition to my long familiar Perl languages for some projects and have come to some conclusions based on these three.
Perl has a long history. Which translates to a lot of smart people using it and a fantastic amount of both well documented modules and well established modules that work well and readily. So there are four advantages here: documentation that is complete, documentation is accurate, modules are completely functional, testing/execution is easy.
Javascript is a bit of a fluster-cluck in comparison to this. Documentation is mixed. But there are a lot of really great quality modules with some really great sets of documentation out there. And some gross exeptions. But everyone has their black sheep. What javascript doesn't have is the ability to easy execute/test the code from a command line environment. It's got too much dependency on that ugly browser which can make execution and debugging rather difficult. IMHO javascript needs a rewrite to address it's shortcomings but it's still impressive in accomplishments.
Which turns my attention to Ruby. Lovely language, pretty, elegant, nice to work with. If you know what you are doing. There is effectively little to zero documentation on just about everything. Core modules, when you call up the 'ri' or 'rdoc' returns an emply documentation file. Nice job making it impossible to understand what's going on. There is peepcode, but with $9 a whack at documentation it's pretty easy for a project to get very expensive just trying to see what might be the best module. This is nice for one level of capitalism, but bad for the rest. Ruby has done an extremely bad job on documentation. Fortunately, they have done a very good job with test and execution so it's easier than javascript to work with in that regard. You just don't know what you are doing when you start.
If you don't believe me about Ruby try 'ri Rspec'. It returns an empty file letting you know there is nothing done to document the use of this module. I can find hundreds but this is just an example.
If Ruby was able to provide a level of documentation and functional modules that Perl can demonstrate there would not be much to slight Ruby for. This is a major barrier to adopting languages: documentation, testability, execution/debugging