I downloaded RubyCLR today to play around with it and found that it was much more productive than IronPython. The reason is quite the same as what I mentioned in my previous blog entry. The Ruby-CLR bridge, which is essentially a library, is implemented as a native Ruby extension. So, this gives the developers the choice of using both C based modules and .NET based assemblies from the same script. And thus, in my opinion, RubyCLR is better than JRuby. We do not have to rewrite most of the native wrappers that are already written. In fact, some of them can be brought to .NET. I am not sure on how to embed Ruby as a scripting language for .NET applications. The other way is pretty clear from the samples that are distributed with the download.
Go ahead. Try it out. You will be surprised on how productive you become.
Thursday, November 23, 2006
Tuesday, November 21, 2006
Madai Thiranthu - A really cool Tamil Hip Hop Remix
While I was browsing the net, I came across this amazing remix. As Yuvan is busy butchering his father's masterpieces in the name of remixes, this group of Malaysian hip hop artists have produced another masterpiece remixing the older master piece by Ilayaraja.
http://www.youtube.com/watch?v=uQSDr4609BU
Wednesday, November 15, 2006
When Cross Platform is not good enough...
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.
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.
Subscribe to:
Posts (Atom)