The programming Golden Gate Bridge
Miguel de Icaza, godfather of Mono - the open source implementation of .NET (and it occurs to me that "godfather of Mono" is not a title people would normally like to carry, but it's not my fault, he named his creation Mono) - recently announced on his blog that he had successfully ported Paint.NET to the Mono platform.
These were all problems resolved by Mr. de Icaza. More interesting to me, though, was the fact that an entire application originally targeted at Windows has been made to work on Linux. Granted, it wasn't as easy as moving a Java application from Windows to Linux, but that's beside the point. The Windows development world doesn't use Java.
Granted, the Windows world still has heavy doses of native code development using languages like C++, but that's the situation today. Paint.NET is surprisingly responsive for an application mostly written in .NET. Granted, it cheats a bit and drops down to native code for certain critical operations, but 10 years ago, writing an entire graphics application MOSTLY in managed code would have been madness.
Today, it's possible to do some pretty processing-intensive applications in pure managed code, and that makes the Mono approach to making the Linux platform relevant to Windows developers seem particularly shrewd. I've been trumpeting the merits of .NET as the bridge across which Windows developers might walk to other platforms for some time now. They simply aren't going to make the journey if they have to climb cliffs, swim fast-moving rivers and dodge herds of wild buffalo - which is the functional equivalent of what it takes to move from the Windows programming domain to the UNIX programming domain.
A fact that seems lost on most fans of non-Windows platforms - save for Mr. de Icaza - is that Windows programmers, for the most part, don't just program for Windows because they have to. If you spoke to most Windows programmers, most LIKE programming for the Windows platform.
Now, we can argue about whether or not that preference is the result of market realities guiding educational choices leading to preferences based on ingrained knowledge of a particular platforms' idiosyncrasies (now say that quickly...backwards). Again, however, that is beside the point. The fact is that those developers will find the UNIX world as alien as the UNIX programmer accustomed to "makefiles" (which Mr. de Icaza generated in the course of converting from the Windows-oriented Paint.NET source base) would find the Visual Studio project files which are the de facto standard for Windows development.
As long as that state of affairs persists, Windows and Unix developers will sit behind their walls, refusing to spend much time considering the other. Mono tries to change that by making it easier for people to spend time outside the walls. Americans have an easier time travelling Europe now that most Europeans speak at least rudimentary English. Mono tries to be the "English" for Windows programmers, making it easier for Windows programs to run "as is" on non-Windows platforms.
Granted, there's still work to be done to make those applications work, but with each passing month it becomes possible to handle more advanced features found in Windows .NET. Furthermore, with each passing year, the power of hardware reaches a point where more and more functionality can be handled within managed code with reasonable performance characteristics, a fact which works in Mono's favor as diving down to the native level becomes a less common requirement.
The Mono approach made sense to me back in 2002. It still makes a lot of sense to me. Instead of requiring Windows developers to climb mountains, they build tunnels with nice music and soft carpets. Make it easy, and the developers may come.