.NET losing some of its shine

Posted on

I’ve always been a big fan of .NET, especially C#. Microsoft has put a lot of work into making it a very elegant and stable platform. I can create beautiful code in C#; certainly more beautiful than many other languages I’ve come across. C++, PHP, Java… They all have something about them which comes across as “hacky”, or feels like an afterthought. From preprocessor directives in C++, to the weird mashup of OO/linear programming in PHP; and don’t even get me started on Java. Every one of these languages seems to have some peripheral part to it that just detracts from the act of actually writing code to do what you want it to do. Call me a purist. True, there are other elegant languages (Python and Lisp spring to mind, for example), but I’m often struck by the irony that the most commonly used languages in industry are typically outright ugly (C++, I’m looking at you). Perhaps it’s just a necessity of being able to get down-and-dirty in a low-level language, I’m not sure. I just know that I feel considerably less dirty if I’m working with a higher-level programming language, such as C#.

It’s with some disappointment, then, that I keep running up against the odd problem when I try to dig deeper. While basically every language except hand-coded Assembly will be interpreted and translated for hardware at some level, languages running in a VM are typically far more loosely coupled with the underlying hardware that they are running on. This is both a benefit and a drawback. The key benefit is that you can let the VM take a lot of work off your hands, such as memory management, UI rendering, resource management, etc. The drawback being that this separation from the internals means that the only way you can modify those internals, is through interfaces exposed to you by your VM. Such interfaces may be restrictive or incomplete.

For the most part, C# (and .NET in general) is pretty good at letting you get down and dirty when you need to, while allowing relatively non-verbose code when you don’t need to. However, my dabblings with ConsoleWrapper have really started bringing things to a head. Of particular frustration is the built-in System.Drawing namespace. .NET uses GDI+ as its rendering engine (as opposed to the older, more mature GDI). While GDI+ has its merits (and is the way forward in terms of the future of Windows UIs), it’s often outright slow. In particular, I’ve been striking issues with font rendering, which can be easily an order of magnitude slower in GDI+ than its older counterpart. On top of this, only TrueType and a small subset of OpenType fonts are supported by GDI+, which has been particularly frustrating for me when attempting to render some text with a standard OpenType font, supported by basically every other application on my machine.

C# does expose extern as a means of referencing external libraries, so if I get desperate I can always import and use the old GDI libraries. That’s about the point that I start feeling dirty again, though.