Most of you probably saw the slashdot link yesterday but Chris has posted 2 *long* replies that really dig deep into a lot of the myths about Microsoft and Word.
Did you know that Word is binary backwards and forwards compatible starting with Word97? Have you seen the cool things that Word can do with XML in 2003?
A great blog entry that lets you get past the myths about Office.
I'm not on the ASP .Net team but I am on the VB team. Anything I say on this, though, is pure speculation.
VS is a complex eco-system. Something that seems simple to fix from the outside may not be that way on the inside and things that look complex can be really tough to change. Also, since every version of VS .Net targets the same version of the CLR that it shipped with and only that version, we have available all the new whiz-bang features of the CLR as well as access to all the work done by other teams (if ASP .Net writes a cool uploading subsystem that handles http, ftp, unc, local, etc. and offers a nifty new browse dialog then other teams my use that component). VS is very interconnected and makes use of MS development technology pretty extensively.
What I'm getting at is you don't know how many of these new features the improvements in HTML formatting used. If it's written in managed code (which I would guess that it is) then it could use generics, anonymous methods, different access level properties, etc. Maybe it takes advantage of some new .Net libraries that are only in Whidbey. Porting it back to 2003 could not only be hard, it could be impossible.
Also, remember that at the end of the day we are selling a product and we have to get that out the door. If the ASP .Net team took a month and back ported this feature then they would either start slipping on our release date or be forced to drop features from Whidbey. Also, the more features we backport the less incentive people have to move up to Whidbey. If we backported this (assuming it was possible) then the floodgates would open; why not backport Master Pages? Snap lines in winforms? DataGridView?
I think that everyone wins if we backport the critical stuff but focus on getting the next version out the door. I don't make these kinds of decisions but this seems to be feature level work rather than a bug fix and features usually belong in new versions.
Given how much public confusion arises from Microsoft Code names, imagine how much internal confusion there is!
Some projects have 2 or 3 names that they go by. Sometimes it's an old code name (such as Everett for VS 2003), the official name (VS2k3), or non-official version number (VS7.1). Of course, by the time we RTM we have an official external name (VS 2003 in our case) but that doesn't kill off the multitude of internal names for the project.
So if you think you've got it bad!
The few times that I actually write code in a language that uses braces, I stick to the new line method:
Also, I put spaces between my equals:
x = 4
Of course 98% of the time I'm writing VB inside Visual Studio so I don't have to worry about this kind of stuff (Ctrl+A, Ctrl+K, Ctrl+F is your friend).
The thing that I like about most of the replies on this thread is that people are picking languages based on what they like and how they think.
Me? I love VB. I like the syntax, I like the IDE and I like that it has all the power (minus unsafe code that is, but who needs that ) of and every other .Net language. That's one of the things I love about .Net: we all get to use the language that makes sense to us yet we can all interoperate and we all get the same power from the platform.
This is true even here inside Microsoft. We use C#, VB, and C++ inside Visual Studio and everything works together thanks to .Net (and COM).
Man I love this platform.
Lwatson, I feel the same way about VS
Jamie, unfortunatly I'm not really in a place to say what you can and can't get access to. I'm just a dev working hard on VB .Net deployment. Maybe another fellow MS'er can comment more about getting into things like that.
ktegels, I assume you're talking about MSBuild when you talk about the longhorn build system. Whidbey uses MSBuild as it's project format and uses it to build all managed projects (you can see this today in our PDC preview as well as the community preview). I'd direct you to my former comment about compilers. When developing all this stuff at once, we can only use it to a limited degree and maintain our build stability and our sanity. While I'm sure some where people are building with MSBuild, we still use our tried and true build system for most of our stuff. We have a lot of investment in it and it gets the job done.
A look at rotor may be enlightening...
I learn more about official XBox stuff from external sources than I do from internal ones.
Those XBox guys are tight lipped!
We use the same compilers but we the reason we don't build from VS is because that has the latest and greatest bits but also the most unstable. We build using a last known good compiler that gets updated much less regularly than everyday. That's the fun of writing the compiler, the platform, and the tools all at the same time (and writing the tools in the new languages for the new platform!).
As far as the build system goes, it's ancient ways are best left to those who know it's secret incantations . Well, its not that bad but there are whole teams dedicated to getting our daily builds done and I have nothing but respect for the feats they pull off each day. I wish I could tell you more but I haven't plumbed the depths of our build system too far...yet...