Ars Technica on the .NET Framework
Ars Technica is posting a series on Cocoa (the Mac UI framework) and part of it is a comparative look at the .NET Framework. And in my opinion, it’s not very fair.
Here’s a quote:
The .NET library does work. It more or less has all the main pieces you need, but it’s full of areas where you have to deal, directly or indirectly, with the obsolescent mediocrity of Win32. On their own, none of these issues would be a show-stopper, but they all add up. It’s a death of a thousand cuts.
He’s talking about Windows Forms, where I find some of what he says to be true. A bit too much of Win32 shines through in Windows Forms. But still, as a wrapper for the Win32 API, it takes it from the death of a million cuts which is straight Win32 development to a death of only a thousand cuts. It’s a big improvement.
And when working with the rest of Win32, things like files or sockets, it’s a much cleaner environment.
I haven’t worked with WPF, but since it’s not based on Win32 at all, I’d expect it to be a clean, well-architected UI framework. Anyone with experience working with it care to say?
In picking on Win64 he says:
Another example; Win32 has a function for getting the size of a file. File sizes on Windows are limited to 2^64 bytes, and so they need a 64-bit integer to be expressed easily. But the API call to get the size of a file doesn’t give you a 64-bit value. Instead, it gives you a pair of 32-bit values that have to be combined in a particular way. For 32-bit Windows, that’s sort of understandable; 32-bit Windows is, well, 32-bit, so you might not expect to be able to use 64-bit integers. But if you use the same API in 64-bit Windows, it still gives you the pair of numbers, rather than just a nice simple 64-bit number. While this made some kind of sense on 32-bit Windows, it makes no sense at all on 64-bit Windows, since 64-bit Windows can, by definition, use 64-bit numbers.
But .NET gives you exactly that. All integers in .NET are 64 bit, and there’s no futzing to do to get the 64 bit size of a file.
Of course:
So Windows is just a disaster to write programs for. It’s miserable. It’s quite nice if you want to use the same techniques you learned 15 years ago and not bother to change how you do, well, anything, but for anyone else it’s all pain.
As I said recently, I’m not using the .NET framework at work, so that’s the world I live in. What can you do? If you want to sell software, Win32 is still where it’s at.
May 6th, 2008 at 9:25 am
WPF is alright, and arguably better than Windows Forms, but I do have some gripes with it. I haven’t spent a ton of time with it, so take these criticisms with a grain of salt.
1) XAML – just feels too bloated. If it were only markup for layout, similar to HTML it would be great. But they shoehorned styling and animation events and things like that into it.
2) Expression Blend & VS 2008. The text editor in Expression sucks, and the WYSIWYG editor in VS 2008 isn’t that great, so you’re constantly switching back and forth. Plus Blend is UGLY. This is more of a criticism of the tools, but considering how tightly integrated they are, I feel it’s legitimate.
3) Too many ways to do the same thing. You can use WPF nearly the same way you use WinForms, which makes it kind of confusing when going over someone else’s code. In my opinion, they should have just made a clean break and thrown away the WinForms mindset.
Ultimately, I think that WPF has the potential to be great, but it still seems a little half-baked.
May 26th, 2008 at 1:09 am
>> All integers in .NET are 64 bit, and there’s no futzing to do to get the 64 bit size of a file.
No it isn’t. You have int64 as long, int32 as int, int16 as short, int8 as byte all of which have their corresponding opcodes to work with.
May 26th, 2008 at 11:07 pm
Ah you’re right. I wonder why I thought it was 64 bit. At least 64 bit integers are a built-in type so there’s no combining of 32 bit values to do.