Over the past 2 years while working on my main project, I’ve been struggling with what programming language to use. I went through many rewrites and many different languages. Now I think I may have arrived at a good solution.
I started with C#. That went down in flames because of the huge overhead in startup time for large assemblies. It also did not have all the code implemented on the Mono side of things. I wanted an easy-to-use language, with all the great Linux technology, like DBus, Cairo, Hal, and GStreamer.
At that point I decided that I was being too much of a wussy, and was going to use C/C++. That quickly crashed and burned as I re-learned why I hated C/C++ in the first place: “Standard Libraries” that are not standard or consistent across platforms; No standard libraries for Lists, Array Lists, and Hash tables (yes. I’ve used STL. It is very fucked up on Ubuntu and Fedora Core); Threads were not “Standard” either; Endless fighting with header files to make the compiler happy; And finally the nightmare that is USING Gobject. It all amounted to too much work, and almost no progress.
My next attempt was to use D. Which was, and is very promising. It is as fast as C, and includes all the threading and collection support. The problem however was that the Gnu D Compiler was not packaged in Debian, and didn’t include the standard ‘Phobos’ library. That was fine. I fought with it and got it working myself. I was cruising along and creating the Postgresql database back-end when I hit a wall. The wall was that the promise of ABI compatibility with C was not entirely true. It was true for the Cairo wrappers I made, but not for the Postgresql wrappers. So I decided to wait a bit longer and see if a solution presented itself.
A solution came a few months later, after I spent a while learning Ruby on Rails, and gained the wisdom that comes with not focusing on performance and over configuration. I decided to try and implementing everything in Ruby. Simply put: Ruby is amazing. Once I understood the Model View Controller technique. And I mean really understood how it works. Not like the outright lie that is in Wikipedia article. I had an epiphany: If you break your programs up into user interface, logic, and data, it makes everything so much more streamlined. All the problems with coupling and optimization simply vanish. Well it was (and still is) sufficient to say that I would do the entire project in Ruby.
But then I started to notice things. Like the amount of memory even a simple Intuitive Document was using. This wasn’t really a problem. But it would be for small machines like the n800, and would inevitably be a problem when the entire desktop consisted of 6 programs that each use 20 to 30 megabytes of ram. We would have all kinds of issues with paging memory to disk, and the CPU waking up like crazy to manage it all.
I decided to wait a bit and see what the community came up with. This was a long stretch where things like Lowfat, Pyro Desktop, and Online Desktop where being revealed. So it gave me hope that someone else would want to write libraries in a high level language.
Then very recently, I started seeing blog posts about this new GObject friendly, C#-like language called Vala. Like this post where a person makes Gtk MozEmbed wrappers for Vala in a few lines of code. This is how GObject should be used! Since I am using a lot of the Gnome infrastructure under the covers, this might be a very good choice for a library-level language.
So this is the plan so far: Once we get more stable, someone will rewrite the Intuitive Framework to use Vala. Then we will need a way to still use Ruby for the Intuitive Desktop and application part.
Sounds good. Now we just need more contributors!
Post a Comment