Replies

I mean, if MS killed backwards compatibility going from VB 6 to VB 7 (ooops, VB.Net), then why wouldn't they kill it again going from VB.Net to VB 8?

It could happen, but that would surprise me. They know how much hassle this is. They knew it when they did it. There were probably big fights in the product management shop over leaving the VB-6'ers behind. Nobody ever wants to do that on purpose.

But there does come a time when the engineers tell you that in order to do the New Thing right, they have to break the Old Thing.

It's a very risky thing to do. Intel is finding that out with the Itanium. "Let's do 64-bits right. Unfortunately that means leaving x86 behind." That one will probably turn out to have been a mistake. AMD extended x86 to 64 bits, and they're cleaning up.

I'm not surprised by the stats in #61. That's the risk you always take when you do this. "If we're gonna re-train everybody anyway, let's look around and see what else is out there." So you lose some to the competition.

Microsoft probably had a pretty good handle on what the attrition rate would be, but they must have decided it was worth it to get where they want to go.

But they won't be doing it often. They know what .NET is going to look like five years from now. There's no need to break things again for a long time.

"But they won't be doing it often. They know what .NET is going to look like five years from now. There's no need to break things again for a long time."

I'm unconvinced. No one in the C++ world would tolerate a new C++ release that couldn't run old C++ code, yet that's what MicroSoft did with VB.Net to all previous versions of VB.

Frankly, the sort of child-like programming mentality that would frivolously cast aside backwards compatibility in the name of doing something the "right way" for the future is the same mindset that will repeat that behavior when the next new fad comes along.

For instance, MicroSoft is going to screw *either* their current MS Excel, MS Word, MS Access, and Autocad developers, or MicroSoft will screw current VB.Net developers, when MicroSoft makes its next VBA release for its major apps.

VBA is not currently compatible with the new VB.Net, so the next release of VBA must, by definition, screw either the old VBA developers or the new VB.Net developers.

So I already *know* that MicroSoft is going to screw a substantial number of its current developers again in the near future, the only question is whether MicroSoft will hammer their VBA or their VB.Net developers.

And that makes it difficult to persuade me that MicroSoft isn't going to repeat their VB 6 to VB.Net fiasco again in the future. Frankly, it's a fait accompli.