OK, so don’t get me wrong – there are lots of things I like about .NET:
- I like that there are five main programming styles to choose from (C#, Visual Basic, F#, PowerShell and C++)
- I like that it’s so quick and easy to write nice-looking programs
- I like the Code Access Security model (although most places aren’t disciplined enough to use it)
- I like the lack of remote code execution through buffer overflow
And up until recently, when all I was really doing was reviewing other people’s .NET code, my complaints were relatively few:
- Everything’s a bloody exception – even normal occurrences.
- Trying to open a file and finding it not there is hardly an exceptional circumstance, for instance.
- Similarly, trying to convert a text string to a number – that frequently fails, particularly in my line of work.
- Exception-oriented programming in general gets taken to extremes, and this can lead to poor performance and/or unstable code, as programmers are inclined either to catch everything, or accept code that throws an exception at the slightest nod.
- It’s pretty much only available on the one platform (yes, Mono, but really – are you going to pitch your project as running under Mono on Linux?)
- You can’t search for .NET specific answers in a generic way.
- “Java” occurs sufficiently infrequently in any programming context other than the Java platform / language, so you can search for “string endswith java” and be pretty sure that you’re looking at the Java string.endsWith member, rather than any other.
- I’ve taken to searching for “C#” along with my search queries, because the hash is less likely to be discarded by search engines than the dot in “.NET”, but it’s still not all that handy.
But now that I’ve started trying to write .NET code of my own, I’m noticing that there are some really large, and really irritating, gaps.
- Shell properties in Windows – file titles, description, comments, thumbnails, etc.
- While there are a couple of additional helpers, such as the Windows API Code Pack, they still cause major headaches, and require the inclusion of another framework that is not maintained by usual update procedures.
- Even with the Windows API Code Pack, there’s no access to the System.Thumbnail or System.ThumbnailStream properties (and presumably others)
- Handling audio files – I was hoping to do some work on a sound file analyser, to determine if two allegedly-similar half-hour recordings are truly of the same event, and maybe to figure out which one is likely to be the better. I didn’t find any good libraries for FFT. Maybe this was because you just can’t search for .NET-specific FFT libraries.
- Marshalling pointers in structs.
- So many structures consist of lists of pointers to memory contents, it would be really nice to create this sort of a structure in a simple byte array, with offsets instead of pointers, and have the marshalling functions convert the offsets into pointers (and back again when necessary).
- Better still, of course, would be to have these structures use offsets or counts instead of pointers, but hey, you have to support the existing versions.
So now I have to grapple between whether I want to write my applications in .NET and miss out on some of the power that I may want later in the app’s development, or carry on with native C++, take the potential security hit, but know what my code is doing from one moment to the next.
What other irritating gaps have you seen – or have you found great ways to fill those gaps?