Skip to Content
I have been an avid fan of programming languages like C#, Python and Java as they take away most of the clunkiness of C/C++ code. Java, .NET/Mono, Python, Ruby and all other similar languages make claims that they are cross platform compliant. But the truth is, the library developer is bound to a specific technology.  For instance, the bzr version control system is written entirely in python. It has quite some promising features but it can never measure up to Subversion. Just imagine integrating bzr with Eclipse or using it with Visual Studio 2005. I am sure that I am not the first person to raise this as a concern. It is a part of the FAQ here. But my concern is not about the performance but the portability. It might, at the outset, seem as a funny argument as Python is supposed to be an extremely portable language so why should anyone have such a concern? The problem is not with the platform portability but with the technology portability. You would have to jump through several hoops before you can get bzr working with Java or .NET/Mono. Another argument might be that people could simply port bzr to Jython or IronPython. This might be possible with open source software but might not be the case with the closed source counterparts. There are a lot of good number of libraries written in Java, which unfortunately have to be rewritten in .NET. A testimony to this is the J* open source projects being ported to .NET and called as N*, like xUnit, xAnt, xVelocity, etc.  I understand that Java, C#, Python or Ruby make developers insanely productive. But library developers have to resist the urge to develop libraries in these languages and try to write their libraries in C/C++. By libraries, I also mean the tools and toolkits that are associated with them. Cross platform portability is definitely a concern. But it can be addressed but portable libraries like Boost or APR. You can later provide bindings to higher languages in the .NET stack, Java, Python or Ruby using interface generators like SWIG. There are numerous projects that have followed this approach and are hugely succesful. For instance, Subversion, wxWidgets, GTK , SQLite, MySQL are all glorious examples of toolkits and libraries that have core C/C++ components and have language bindings to higher level languages.  I am not saying that programming in Python or Ruby is bad. I absolutely love the way they make you productive. But high level languages are not the panacea for all programming problems. There are certain categories of software that ought to be written in C/C++ and not with higher languages. You can then write wrapper/helper libraries to make the access even simpler. But if the library developer ensures compliance across technologies, higher the chances of the library being usable and consequently popular.  Just my 2 cents on library development.
To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. James Taylor
    What about getting out of writing legacy code and writing business rules instead? Many business rules engines support cross-platform deployment as well as business user maintenance of the rules to ensure they stay current. This not only supports cross-platform problems it also externalizes the business logic so it can be managed and reused.
    JT
    http://www.edmblog.com
    (0) 
    1. Anonymous
      I agree completely with you when it comes to higher level logic like business rules. But when we talk about toolkits or libraries targetting developers like source control management, continous integration libraries, UI toolkits and so on, the core library should be written in a technology and platform portable form. In your case, the business rules can be written in a business rule engine. But the business rule engine should be written in a technology and platform portable fashion.

      Hope I made myself clear.

      (0) 

Leave a Reply