338 - Source-Code-a-k-a-Useful

It seems that I’ve had less to write about recently than usual. In part this is because of working at HP. Firstly, I’m generally pretty tired and not in the mood for writing when I get home in the evening. Secondly, much of the interesting stuff is happening at work; I’m not sure how much I can say about it so I’m taking the safe route and saying nothing!

There are some really cool looking things on the horizon that I’ve seen, however. One is the Mono/Java debate that is happening in the Open Source, and in particular Gnome, world. I’ve coded a lot in both languages, and they are both nice to program in. They are also both good for high-level desktop application writing, better suited to this domain than C/C++ in my opinion because of the simple syntax and extensive built-in libraries. I am running a C# (i.e. Mono-based) music player called Muine, which I really like and seems very stable — far more so, in fact, than Rhythmbox which is coded in C.

For my own coding, I would rather use either Java or C# to program desktop applications. Somewhat slowly I am tending towards C# and Mono just because Mono seems more integrated into the Linux environment than Java is. Sun’s efforts to make Java cross-platform might be good for server programs, but for desktop applications it just seems a hindrance. Coding the core program-logic to be cross-platform and writing the OS specific parts, especially the SWT and Eclipse for a great example of this in practise.

In this vein, it is a shame that both Java and C# have issues surrounding their use in open-source software. Most important is the patents that Microsoft hold around C# and the CLI and the fairly closed evolutionary path that both languages are and will be taking for the foreseeable future. It’s a shame that companies such as Sun and Microsoft desire such control over their creations. Surely it is the applications built on top of these foundations that matter.

At least Sun will give you the source code. The ability to see inside libraries to see what is happening — whether its your bug, their bug or just that the docs are ambiguous, the source code is there to help clear up the problem. With the MS libraries, you have none of that. If they don’t work, you either have to ask Microsoft what is going on or try and find a workaround via trial and error. Source code is invaluable.

Last year I worked in C#, using the MS.NET libraries. Each time I came across a problem, it was off to the MS forums to see what is going on, try and get a response and so on. This year I’m working in Java with full source code to the libraries that are shipped with the language. Being able to step through the code in a debugger has proved useful on at least two occasions. Having the code is also reassuring in a way. You have the code, you could, if you wanted look through it; Grep for TODOs and FIXMEs =).

There will always be bugs, and access to the source code helps you isolate where the bug lies. The vast majority of the time it will be your code, but for those occasions where it isn’t, the source code is a far faster resource than many other places.

This brings me to the subject of bug databases. Why oh why do Microsoft not maintain a bug database that is accessible, if not to the public, then to MSDN subscribers. With all the emphasis that Microsoft puts on developers, you would think a bug database of the bugs in developer libraries would be a fairly obvious thing to provide. Source code and a bug database. Come on, it’s the ideas people can take, not the code. Code can be easily implemented once the idea is visible, and most of the ideas are by necessity there for all to see. Hiding source code is not a form of protection of ideas. Patents cover ideas. (As for the crazy state of patents at the moment, don’t go there). Code is merely an expression of the ideas.

The notion that hidden code aids security is also an obvious temptation. As the recent exploits against Windows show, this is not the case. Of course, Linux and associated software are also exploited a reasonable amount. They are not exploited to a greater extent than Windows though, which the hidden code = security argument would predict.

Opening code doesn’t matter a jot to the majority of the world, but for developers a more open development process would be a great boon, I’m sure. It wouldn’t attract me back to Windows, but looking from this side of the fence, it’s obvious that it’s a shackle for Windows (and Mac, I would guess) developers; and one they shouldn’t have to put up with.