Could everyone who uses Visual Studio.Net, and plans on distributing/bequeathing their code to anyone else, please give a thought to people who don't use it? I'm sure it's a lovely environment that makes you x times more productive than me, but be aware that VS.Net can be very invasive to source code. You know (I hope) what I'm talking about:
///
///Summary description of Foo
///
class Foo {
}
and:
//
// Required for Win Form Designer support
//
InitializeComponent();
and:
#region Public methods
...
#endregion
It's not just the fact that this cruft is useless to non-VS.Net users, it's the wider issue of a non-free IDE becoming the de-facto standard amongst .Net developers that annoys me. Now I'm not a hand-waving free-software long-hair or anything, and I'm not suggesting that Microsoft would do this, but I wouldn't like to see a world where VS.Net was required for .Net development. I'm not even happy that it's recommended for .Net development.
I'd guess that a large majority of people who write about, teach and evangelise .Net have a copy of Visual Studio. I think MVP's can get a free copy, anyone who gets an MSDN subscription paid-for (or can afford it themselves) has a copy, and Microsoft staff obviously eat their own dogfood (right?). So there are a boat-load of articles, books and tutorials out there written by and for VS.Net users. How often have I seen this sort of thing: "...just open the solution file, hit F5 and you're golden!"? No, I'm not golden. I'm faced with the prospect of spending the next half-hour writing a batch file to build your IDE-dependent source into something I can run, and yet more time weeding out the useful code from your empty-comment-ridden, #region-riddled, design-time supported, drag-and-droppable "solution" so that I can see what the hell you were on about when you said "...as you can see from the code, foo is completely decoupled from bar!". Try decoupling your IDE, pal.
Cheers.
A while ago I read Jason Whittington's idea for starting a managed demo scene, and got to thinking about what would constitute "managed" graphics code? At first I discounted DirectX, because even the managed bits are wafer-thin wrappers around unmanaged libraries. I started writing some rendering functions using System.Drawing. Then I discounted that, because it's mostly a wafer-thin wrapper around unmanaged libraries. So what are we left with? Am I being a purist?
Maybe it should be anything-goes, but 'karma' is awarded for heavy use of managed code.
I don't like introductions, but it would be rude not to.
My name is Jim. I'm a developer (for no-one in particular right now) with an interest in being a better developer. My geek-interests are 3D graphics, audio, persistence layers, unit testing, games programming and anything I can't do with a computer but wish I could. Except that.
I have no idea how long this blog will remain active, but while the mood takes me I'll be writing about the stuff I'm working on, starting blog-wars and generally representing London Taaaaan, innit?
Cheers.