Lambda the Ultimate

VB.Net and backwards compatibility
started 1/18/2001; 1:47:27 PM - last post 1/20/2001; 12:44:56 PM

Chris Rathman - VB.Net and backwards compatibility

1/18/2001; 1:47:27 PM (reads: 720, responses: 4)

VB.Net and backwards compatibility

Some developers are complaining about the sweeping changes being made to get VB compatible with .Net. Although I've done quite a bit of VB, I've not done anything with VB.Net to comment one way or the other.

Personally I believe that VB could stand to be overhauled as it's got a multitude of problems that have been carried forward through the years - adding new ones along the way. Still, there is a major investment in VB code out there, so it will be interesting to see how rough the migration to the new version will be.
Posted to "" by Chris Rathman on 1/18/01; 1:48:09 PM

Ehud Lamm - Re: VB.Net and backwards compatibility

1/19/2001; 2:00:55 PM (reads: 732, responses: 0)

I always regarded VB as a product and not as a language. This is the kind of thing I was afraid of.

Adam Vandenberg - Re: VB.Net and backwards compatibility

1/19/2001; 5:39:05 PM (reads: 712, responses: 0)

I find it interesting that MS is putting so much effort into .NET and yet all developers will have to learn new languages to use it, not just new libraries.

C# isn't Java or C++, though it will be easy enough to pick up. VB.NET has incompatibilities with existing VB 6 code.

It's not just ease-of-learning here, as the article points out it's also the ease of migrating existing stuff, getting it to work under .NET.

Sure .NET allows for any number of languages. But I don't that there's any reason to use Perl.NET or Python.NET (for example) unless I really, really need to interoperate with other objects written for .NET.

I can write Python (or Perl or whatever) code that integrates with a service via SOAP right now and not have to be using Python.NET.

I'd actually much rather be using C# to write objects for use in my web projects than using C++ to write COM objects... but what about all my existing COM components? We can't justify rewriting them just-because.

I'd also rather be writing my .ASP scripts in VB.NET instead of VBScript... but we can't migrate our stuff page-at-a-time whenever .NET is ready for prime time. It's an all-at-once rewrite of all of our tested code.

Ehud Lamm - Re: VB.Net and backwards compatibility

1/20/2001; 5:50:54 AM (reads: 710, responses: 0)

If .NET can not be treated just like any other platform, than it should not be viewed as a platform.

andrew cooke - Re: VB.Net and backwards compatibility

1/20/2001; 12:44:56 PM (reads: 719, responses: 0)

but what about all my existing COM components?

As far as I understand things (I went to a MS conference that I sumamrised here), COM objects will be usable from within .NET. There will be/is some way of treating them as black boxes (in a similar way to using packages developed by one .NET language in another). I don't think you will need to rewrite them to do this.