VS.NET Language Divergence

[MasterRacker]

This link is a discussion about where the .NET languages are going in the future. Evidently, according to a mMS employee, instead of the current convergence, MS is planning to diverge the languages in future releases. I though it was kind of interesting.

http://www.dotnet247.com/247reference/msgs/44/223370.aspx

Jeff
The future is already here - it's just not widely distributed yet...

 

[theoxyde]

I had the opportunity to see a bit of Whidbey in action at Dev Days, and like the guy there said... they are growing apart in some ways, but becoming more alike in others.

For instance, VB is now getting XML commenting like C# has enjoyed since day 1. Both are getting Smart Tags, but only VB is getting Edit and Continue and "My" -- while C# is getting refactoring and anonymous methods. Both are getting Generics.

I think it's just that the developers have different goals for their languages, and while Edit and Continue would be nice... I must admit that I broke my need for it in a very short time. It's not even on the "Top 10 Features" I want anymore. (FYI: E&C will still not be available for web apps or web services in any language).

All in all though, there isn't much divergence in the languages themselves, just in the IDE.

 

[dilettante]

I'm not sure how I'd feel about significant divergence.

One the one hand it seems like the VFP crowd got a good deal.

On the other, "VB 7" already went a long way down the .Net road already. In addition I'm not sure it would have been a good long-term direction to have foregone the CLR.

Funny with all of the struggle VB had to get to decent native code though. I had been expecting more progress here yet we ended up with just the opposite.

Not only VB, but VBA and VBScript seem to be going out with the bath water though. I wonder how much progress in replacing the latter two people have made so far (except for ASP.Net which seems moderately successful)?


Anybody seen more recent figures re. market penetration of the installed Framework? Has it reached 5% of Windows servers yet? 1% of desktops? When can we expect consumer desktops to have it deployed at 25% levels? Business desktops? Servers?

Any ideas as to what will drive deployment? New computers with "XP Reloaded?"

Is there a solid leader in terms of Framework versions? Any ideas regarding stability and compatability once the "Whidbey" CLR (2.0?) comes out?

Whidbey is lableled "2005" - how soon can we expect "Orcas," 2008?

Lots of questions. Anyone heard any answers?

 

[dilettante]

Anybody else get a chuckle out of "Microsoft offers four programming languages with Visual Studio?"

Let's see, you have:

[tt]1. a. C++
1. b. C#
1. c. J#
2. "VB"[/tt] (maybe this ought to be called V#?)

Yep, nothing like diversity. ;-)

 

[RiverGuy]

dilettante,

As far as desktops with the framework installed, I believe that the new versions of Windows XP include the framework. Someone correct me if I'm wrong.

So, its got to be much more than 1% penetration.

 

[dilettante]

I guess I haven't bought any newer distributions of WinXP myself. Mine are all early originals patched to SP1.

I'd be glad to know whether the Framework shipped with it and installs by default, and which version(s). I'd still have to think some industry pundit (or Microsoft themselves) can offer an overall penetration estimate. For .Net runtimes in total if not for various versions.

Anybody heard of any mass-market .Net-based title at all yet for desktops? That's probably not its niche today, but it has to happen someday.

 

[theoxyde]

I've seen several OEM machines shipping with .NET 1.1 preinstalled, mind you these are all XP Pro systems. I don't know if XP Home systems are getting it or not.

Maybe the next version of Office will have some .NET components. That would probably have the best chance at widespread deployment of the framework. Aside from Visual Studio itself, SharpReader and NewsGator are the only .NET apps I have used that either I or someone in my office did't write.

 

[lionelhill]

I really enjoyed the fact that VBnet is for armatures.

 

[Dimandja]

Have you noticed that many examples of VB.NET code provided by MS help do not work? While they work in C#?

Dimandja

 

[dilettante]

Nuttin to get "wound up" about though lionelhill. ;-)

Then again, my typing can get pretty sad at times too.

Armatures... hmm, would those be the kinds in motors, or the core used to stiffen a statue or dummy?

 

[chiph]

Dimandja
The VB.NET examples were afterthoughts. The betas of .NET only had examples in C#.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[MasterRacker]

The last couple of machine we built with XP Home did not get .NET runtime be default and these were OEM disks that had SP1A slipstreamed onto them.


Jeff
The future is already here - it's just not widely distributed yet...

 

[Tarwn]

My latest work laptop (Dell) came with 1.1 installed already...course it also had 4 media players and a whole slew of useless utiltities, plus 3 differant applications that were attempting to call to their various homes, so after a controlled flash fire in my file system i couldn't tell you ifthe Framework is still there

[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:

http://www.tiernok.com/

 

[chiph]

Found an example of something that VB.NET does that C# does not. It was in the latest MSDN magazine.

It turns out that MSIL supports the idea of exception filtering. Under VB.NET (but not C#), you are able to write a custom exception filter function. So when you catch an exception, you are able to call this function with it to determine if you really want to do anything with it, or just allow it to progress up the call stack.

For example, if you have your own DotBombException, which inherits from System.ApplicationException, and your DotBombException has a property called "CEO_Overspent", you are able to write a filter function that looks like this:

Public Function DidCEOOverspend(DotBombException myException) as boolean
  DidCEOOverspend = myException.CEO_Overspent
End Function

and you're able to use it like this:

Try
   ' "Try" block that raises
   ' a DotBombException exception

Catch ex As DotBombException When DidCEOOverspend(ex)
   ' "Catch" block.

Finally
   ' "Finally" block.

End Try

note: this is from memory and hasn't been tested

What happens is when the DotBombException is thrown, the Catch block catches it, but only when the DidCEOOverspend function returns true.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[octothorpe]

But... wouldn't "best practice" dictate that you throw a CEOOverSpentException?

try
{
}

catch ( CEOOverSpentException ex )
{
}

catch ( CEOIsFunnyLookingException ex )
{
}

catch ( CluelessUserException ex )
{
}

finally
{
}

I guess I fail to see the usefulness of such an ability when it would seem to be precluded by "best practice". I could be wrong though. I just don't see why I would ever need a conditional catch.

 

[chiph]

It's probably not a feature that gets used everyday (or at least, I hope not!).

But if you have some program data condition on which you would want to catch or not-catch, then the facility is there for you. Maybe a better example would be where you'd condition it on the release version of your application?

[tt]If greater than version 5.10, catch it & deal with it. Otherwise, let the exception bubble up the call stack.[/tt]

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first