Tag Archives: ruby

Top languages on Github: JavaScript reigns, Ruby and Python next

I cloned a github repository today, and while browsing the site noticed the language stats:


Git was originally developed for the Linux kernel and is mainly for the open source community. I was interested to see JavaScript, the language of HTML 5, riding so high. PHP, C and C++ are lower than I would have guessed, Ruby and Python higher.

Here are some figures for the venerable Sourceforge:

Java (7,163) 19%
C++ (6,449) 17%
C (4,752) 13%
PHP (3,521) 10%
Python (2,694) 7%
C# (2,481) 7%
JavaScript (2,011) 5%
Perl (1,138) 3%
Shell (757) 2%
Visual Basic NET (688) 2%
Delphi/Kylix (581) 2%

This comes with a health warning. I have taken the figures from the what you get if you browse the directory and drop down Programming Languages; but the total is only about 37,000, whereas Sourceforge hosts around 324,000 projects. I am not sure what accounts for the discrepancy; it could be that language is not specified for the other projects, or they are dormant, or some other reason. But I hope the proportions indicate something of value.

Github is madly trendy, and Sourceforge ancient, so this tells us something about how open source activity has shifted towards JavaScript, Ruby and Python, and away from Java, C/C++ and C#.

Of course the overall picture of programming language usage is quite different. For example, you can get some kind of clue about commercial activity from a job board like indeed.com, which currently has 77,457 US vacancies for Java, 22,413 for JavaScript, and only 5030 for Ruby.

Nevertheless, interesting to see what languages developers on Github are choosing to work with, and perhaps an indicator of what may be most in demand on the job boards a few years from now.

Finally, looking at these figures I cannot help thinking how short-sighted Microsoft was in abandoning IronPython and IronRuby back in 2010.

Book Review: The Book of Ruby by Huw Collingbourne

“The plain fact of the matter is that Ruby has a number of pitfalls just waiting for unwary programmers to fall into,” says author Huw Collingbourne in his introduction to this guide to the Ruby language. He should know; he is co-founder and Technology Directory of SapphireSteel Software, which makes Ruby in Steel, an add-in for Visual Studio that enables Ruby development. He is also a technology journalist and writer of long standing, and specialist in explaining software development to a wide readership, and as you would expect this is a book with a clear and easy going style.

The Book of Ruby is a language guide. It takes you blow by blow through Ruby, starting at the beginning with strings, numbers, classes and objects. Despite Collingbourne’s background, there is little or nothing on tools, user interfaces, databases, or other development essentials; the focus is firmly on the language. There are plenty of short code examples but these are snippets to illustrate a point. There is a single chapter on Rails, the popular Ruby web development framework, but you have the sense that it is included because the author felt it had to be covered; it is the briefest of introductions and you will need another book if you want to know about Rails development.

A sharp focus on the language is a good thing, but it does make this a dry read, or possibly something you are more likely to dip into than to read end to end. You may find yourself thinking, “Remind me how Ruby does threading,” and read through chapter 17 on Threads to get a quick guide to threads, mutexes and fibers.

There are 20 chapters in all, with subjects including Arrays and Hashes, Loops and Iterators, Exception Handling, Blocks Procs and Lambdas, Modules and Mixins, YAML, Debugging and Testing, and Dynamic Programming.

Collingbourne knows his subject and if you are a software developer wanting to learn more about Ruby there is plenty of valuable material here.

That said, I have a couple of reservations.

First, I would have liked the author to tell us more about the why rather than the how of Ruby. Describing how a language works is all very well, but what are the things Ruby is particularly good for, and within Ruby, what are the techniques and features that make it a fantastic choice for certain kinds of development? What is the philosophy behind Ruby? I was expecting the author’s enthusiasm for Ruby to shine through, but it does not.

Second, the book is not long enough to be a comprehensive programming guide in the manner of David Flanagan and Yukihiro Matsumoto’s book The Ruby Programming Language (Matsumoto, or Matz, is the creator of Ruby). Nor is it suitable for a programming beginner, who is going to need more help with basic concepts than can be found here. In other words, it is not an advanced book, and it is only an introductory book in the context of someone who is already a seasoned developer, but not with Ruby. That is a narrow target.

On the other hand, I enjoyed the author’s pragmatism and direct, readable style. If you do fit the target readership, take a look; the Amazon links below include a complete list of contents and some sample pages.


No more Ruby support in NetBeans – the feature was little used, says Oracle

Oracle has announced the discontinuation of Ruby support in the NetBeans IDE. The reason? First, to free resources for JDK 7 support; but second (and more significant) – hardly anyone was using it.

There is hardly a shortage of Ruby IDEs. Ones that come to mind are the Eclipse-based Aptana, JetBrains RubyMine, the Visual Studio based Ruby in Steel, and Embarcardero’s 3rd Rail. Further, some Ruby developers prefer to work without an IDE.

I also suspect that Ruby has not quite hit the mainstream in the way it seemed that it might a few years back. Its influence has been huge, but in practice many developers still fall back to PHP, Java and C#.

The Salesforce.com platform play

I’ve been mulling over the various Salesforce.com announcements here at Dreamforce, which taken together attempt to transition Salesforce.com from being a cloud CRM provider to becoming a cloud platform for generic applications. Of course this transition is not new – it began years ago with Force.com and the creation of the Apex language – and it might not be successful; but that is the aim, and this event is a pivotal moment with the announcement of database.com and the Heroku acquisition.

One thing I’ve found interesting is that Salesforce.com sees Microsoft Azure as its main competition in the cloud platform space – even though alternatives such as Google and Amazon are better known in this context. The reason is that Azure is perceived as an enterprise platform whereas Google and Amazon are seen more as commodity platforms. I’m not convinced that there is any technical justification for this view, but I can see that Salesforce.com is reassuringly corporate in its approach, and that customers seem generally satisfied with the support they receive, whereas this is often an issue with other cloud platforms. Salesforce.com is also more expensive of course.

The interesting twist here is that Heroku, which hosts Ruby applications, is more aligned with the Google/Amazon/open source community than with the Salesforce.com corporate culture, and this divide has been a topic of much debate here. Salesforce.com says it wants Heroku to continue running just as it has done, and that it will not interfere with its approach to pricing or the fact that it hosts on Amazon’s servers – though it may add other options. While I am sure this is the intention, the Heroku team is tiny compared to that of its acquirer, and some degree of change is inevitable.

The key thing from the point of view of Salesforce.com is that Heroku remains equally attractive to developers, small or large. While Force.com has not failed exactly, it has not succeeded in attracting the diversity of developers that the company must have hoped for. Note that the revenue of Salesforce.com remains 75%-80% from the CRM application, according to a briefing I had yesterday.

What is the benefit to Salesforce.com of hosting thousands of Ruby developers? If they remain on Heroku as it is at the moment, probably not that much – other than the kudos of supporting a cool development platform. But I’m guessing the company anticipates that a proportion of those developers will want to move to the next level, using database.com and taking advantage of its built-in security features which require user accounts on Force.com. Note that features such as row-level security only work if you use the Force.com user directory. Once customers take that step, they have a significant commitment to the platform and integrating with other Salesforce.com services such as Chatter for collaboration becomes easy.

The other angle on this is that the arrival of Heroku and VMForce gives existing Salesforce.com customers the ability to write applications in full Java or Ruby rather than being restricted to tools like Visualforce and the Apex language. Of course they could do this before by using the web services API and hosting applications elsewhere, but now they will be able to do this entirely on the Salesforce.com cloud platform.

That’s how the strategy looks to me; and it will fascinating to look back a year from now and see how it has played out. While it makes some sense, I am not sure how readily typical Heroku customers will transition to database.com or the Force.com identity platform.

There is another way in which Salesforce.com could win. Heroku knows how to appeal to developers, and in theory has a lot to teach the company about evangelising its platform to a new community.

Salesforce.com acquires Heroku, wants your Enterprise apps

The big news today is that Salesforce.com has agreed to acquire Heroku, a company which hosts Ruby applications using an architecture that enables seamless scalability. Heroku apps run on “dynos”, each of which is a single process running Ruby code on the Heroku “grid” – an abstraction which runs on instances of Amazon EC2 virtual machines. To scale your app, you simply add more dynos.


Why is Salesforce.com acquiring Heroku? Well, for some years an interesting question about Salesforce.com has been how it can escape its cloud CRM niche. The obvious approach is to add further applications, which it has done to some extent with FinancialForce, but it seems the strategy now is to become a platform for custom business applications. We already knew about VMForce, a partnership with VMWare currently in beta that lets you host Java applications that are integrated with Force.com, but it is with the announcements here at Dreamforce that the pieces are falling into place. Database.com for data access and storage; now Heroku for Ruby applications.

These services join several others which Salesforce.com is branding at Force.com 2:

Appforce – in effect the old Force.com, build departmental apps with visual tools and declarative code.

Siteforce – again an existing capability, build web sites on Force.com.

ISVForce – build your own multi-tenant application and sign up customers.

Salesforce.com is thoroughly corporate in its approach and its obvious competition is not so much Google AppEngine or Amazon EC2, but Microsoft Azure: too expensive for casual developers, but with strong Enterprise features.

Identity management is key to this battle. Microsoft’s identity system is Active Directory, with federation between local and cloud directories enabling single sign-on. Salesforce.com has its own user directory and developing on its platform will push you towards using it.

Today’s announcement makes sense of something that puzzled me: why we got a session on node.js at Monday’s Cloudstock event. It was a great session and I wrote it up here. Heroku has been experimenting with node.js support, with considerable success, and says it will introduce a new version next year.

Finally, the Heroku acquisition is great news for Enterprise use of Ruby. Today many potential new developers will be looking at it with interest.

Microsoft lets go of IronPython and IronRuby

Visual Studio corporate VP Jason Zander has announced that IronPython and IronRuby, .NET implementations of popular dynamic languages, are to be handed over to the open source community. This includes add-ons that enable development in Visual Studio, IronPython Tools and IronRuby Tools. Of the two, IronPython is a more mature and usable project.

Why? Here’s a few reflections. For what it must cost Microsoft to maintain these projects, versus the goodwill it earns in the open source world, I would have thought they represent good value and I am surprised to see them abandoned.

On the other hand, it is easy to see that they are not commercial propositions. I’d guess that they were more valuable a few years back, before C# acquired dynamic features, and when dynamic languages were strongly in vogue and Microsoft was keen not to allow .NET to fall behind. To some extent dynamic languages are still in vogue, but we are now well past what is “the peak of inflated expectations” in the Gartner Hype Cycle, and few are likely to abandon .NET because it does not have an official Python or Ruby.

The other reason they are not commercial propositions is that Microsoft has under-invested in them. I recall Martin Fowler at ThoughtWorks telling me that JRuby, an implementation of Ruby for the Java Virtual Machine, is important to their work; it lets them work in a highly productive language, while giving clients the reassurance of running on a trusted and mature platform. JRuby performs very well, but IronRuby is a long way behind. Perhaps if Microsoft had really got behind them, one or both of these language could be equally significant in the .NET world.

The fact that F# rather than IronRuby or IronPython turned up as a fully supported language in Visual Studio 2010 is also significant. After talking to F# leader Don Syme – see the interview here – I understood how F# was important to some of Microsoft’s key customers in the financial world; and I’m guessing that neither Python nor Ruby had that kind of case made for them within the company.

Although it is a shame that Microsoft is withdrawing official support, the clarity of Zander’s statement is better than leaving the projects in limbo. The folk appointed as project leaders are also very capable – Mono guru Miguel de Icaza is on both teams and a great motivator, though it seems unlikely he will have much time to devote to them given his other commitments – and this may actually be good rather than bad news for the projects themselves.

Jim Hugunin, creator of both Jython (Python for Java) and IronPython, is leaving Microsoft for Google, and his farewell is worth a read. He says C# has evolved into a nicer language than Java, but notes:

I like to have a healthy relationship with Open Source code and communities, and I believe that the future lies in the cloud and the web. These things are all possible to do at Microsoft and IronPython is a testament to that. However, making that happen at Microsoft always felt like trying to fit a square peg into a round hole – which can be done but only at major cost to both the peg and the hole.

PyCharm: JetBRAINS IDE for Python and Django

JetBRAINS has released PyCharm, an IDE for Python and the Django web development framework.

The company is best known for the IntelliJ IDEA Java IDE, and indeed PyCharm is mostly written in Java, but now has other tools for languages including PHP and Ruby and Rails. It also does add-ins for .NET developrs working in Visual Studio.


PyCharm has a small number of refactorings, lots of code search and assistance features,  integrated support for CVS, Git, Mercurial and Subversion version control, unit testing with a graphical test runner, graphical debugger, built-in deployment to Google App Engine as well as error highlighting for GQL queries, and editing support for HTML, CSS and JavaScript as well as Python.

Latest job stats on technology adoption – Flash, Silverlight, iPhone, Android, C#, Java

It is all very well expressing opinions on which technologies are hot and which are struggling, but what is happening in the real world? It is hard to get an accurate picture – surveys tend to have sampling biases of one kind or another, and vendors rarely release sales figures. I’ve never been happy with the TIOBE approach, counting mentions on the Internet; it is a measure of what is discussed, not what is used.

Another approach is to look at job vacancies. This is not ideal either; the number of vacancies might not be proportionate to the numbers in work, keyword searches are arbitrary and can include false positives and omit relevant ads that happen not to mention the keywords. Still, it is a real-world metric and worth inspecting along with the others. The following table shows figures as of today at indeed.com (for the US) and itjobswatch (for the UK), both of which make it easy to get stats.

Update – for the UK I’ve added both permanent and contract jobs from itjobswatch. I’ve also added C, C++, Python and F#, (which hardly registers). For C I searched Indeed.com for “C programming”.

  Indeed.com (US) itjobswatch (UK permanent) itjobswatch (UK contract)
Java 97,890 17,844 6,919
Flash 52,616 2,288 723
C++ 48,816 8,440 2470
C# 46,708 18,345 5.674
Visual Basic 35,412 3,332 1,061
C 27,195 7,225 3,137
ASP.NET 25,613 10,353 2,628
Python 17,256 1,970 520
Ruby 9,757 968 157
iPhone 7,067 783 335
Silverlight 5,026 2,162 524
Android 4,755 585 164
WPF 4,441 3,088 857
Adobe Flex 2,920 1,143 579
Azure 892 76 5
F# 36 66 1

A few quick comments. First, don’t take the figures too seriously – it’s a quick snapshot of a couple of job sites and there could be all sorts of reasons why the figures are skewed.

Second, there are some surprising differences between the two sites in some cases, particularly for Flash – this may be because indeed.com covers design jobs but itjobswatch not really. The difference for Ruby surprises me, but it is a common word and may be over-stated at Indeed.com.

Third, I noticed that of 892 Azure jobs at Indeed.com, 442 of the vacancies are in Redmond.

Fourth, I struggled to search for Flex at Indeed.com. A search for Flex on its own pulls in plenty of jobs that have nothing to do with Adobe, while narrowing with a second word understates the figure.

The language stats probably mean more than the technology stats. There are plenty of ads that mention C# but don’t regard it as necessary to state “ASP.NET” or “WPF” – but that C# code must be running somewhere.

Conclusions? Well, Java is not dead. Silverlight is not unseating Flash, though it is on the map. iPhone and Android have come from nowhere to become significant platforms, especially in the USA. Beyond that I’m not sure, though I’ll aim to repeat the exercise in six months and see how it changes.

If you have better stats, let me know or comment below.

Dynamic language slowdown at Microsoft?

Jimmy Schementi, until recently a Program Manager at Microsoft working on IronRuby, has posted about why he is leaving the company; and in doing so answers a question I posed a few months back, Why F# rather than IronPython in Visual Studio 2010?

When my manager asked me, “what else would you want to work on other than Ruby,” I started looking for a new job outside Microsoft …. a year ago the team shrunk by half and our agility was severely limited. I’m omitting the internal reasons for this, as they are the typical big-company middle-management issues every software developer has. In short, the team is now very limited to do anything new, which is why the Visual Studio support for IronPython took so long. IronRuby’s IDE support in Visual Studio hasn’t been released yet for the same reasons. While this is just one example, many other roadblocks have cropped up that made my job not enjoyable anymore. Overall, I see a serious lack of commitment to IronRuby, and dynamic language on .NET in general … I invite the Ruby and .NET communities to come help us figure out how to continue the IronRuby project, assuming that Microsoft will eventually stop funding it.

The dynamic language work at Microsoft is very interesting and has done a lot to persuade the world that .NET is not just a C# and Visual Basic story. Personally I’d add my voice to those encouraging the company to re-invigorate its investment in IronRuby and IronPython.

A couple of other observations though. Schementi is talking about efforts to continue work on IronRuby irrespective of Microsoft’s funding, and if that succeeds it could bring the project to a better place rather than a worse one.

Second, one thing I learned in talking to Don Syme, the F# man at Microsoft, is that functional programming is in high demand in financial institutions, one of Microsoft’s most important markets. IronRuby and IronPython win Microsoft plenty of kudos, but the benefits in terms of revenue are presumably harder to identify.

Whatever happens to these languages, the impact of dynamic languages on the .NET platform has been significant, and C# now also has dynamic capability.