Microsoft's Roslyn invites VB to Windows 8 party At Microsoft's recent BUILD conference, technical fellow and C# creator Anders Hejlsberg presented a session on the future of C# and Visual Basic. Visual Basic? There were few VB developers evident at BUILD and it seems to be in decline among professionals. Nevertheless, Microsoft is keeping the two in parity: read on for why …
Technically, I think that's all there is here, and so in that sense this is "just" a separation of UI from actual work, which is a technique that has been around (and good practice) for decades. So I doubt the technical people at MS will be claiming a breakthrough here. (Their marketing department will, of course, claim/troll that they've revolutionised programming and made everything multicore friendly at the flick of a compiler switch.)
The only new bit is the level of bullying that is being built into the language in order to persuade programmers to actually write apps this way.
But C# and VB.NET also compile to the same CIL. Indeed, in many cases it is, and always has been, quite possible to compile VB.NET code to CIL and then decompile back to C#.
Add to that, that both VB.NET and C# compiled to the same runtime (.NET or Mono) also share the same API and can utilise the same 3rd party libraries, then, in most cases, the only difference between them is syntactic.
While, indeed, most OO are semantically similar (though I wouldn't go as far as to say identical), there are still far greater (non syntactic) differences between Java and C# than between C# and VB.NET.
Or, to look at it another way. It is far easier to take a C# programmer and get him/her to write VB.NET than it would be for them to write Java, despite the syntactical similarities between C# and Java.
VB "classic" was a pile of steaming doo-doo. It infected a whole generation of devs with sloppy syntax and bad coding practices (ON ERROR RESUME NEXT). IIRC, MS was going to kill VB and go for C# as a forced replacement for VB, but the VB dudes didn't want to move.
So then Microsoft did something awesome; they left "VB" but actually made it so that VB.NET is actually C# with enforced syntactic sugar. Fortunately, the new generations have mostly gone C# or Java; others with PHP, Ruby, some go C++ but the trend does seem to be that most people are finally putting VB out to pasture.
I spent four months in Building 25 on the Redmond campus in 2004, and at the time there was much anticipation and debate around the 64-bit support promised by Visual Studio 2005. Many were saying that VB was dead, and that VB wouldn't support 64-bit dev.
VB is still popular enough that Microsoft added support for it in the Windows Phone SDK. My professional coding is done in C# because that's what the company uses, but I still prefer VB. It is more intuitive and requires less code than the equivalent C# code*, and compiles to almost identical MSIL (both languages share most optimisations, but have some optimisations the other doesn't).
I keep thinking that the point of .NET's multi-language support was missed. Use the language you're most comfortable with, and thereby get productive quickly. And yet all ex-VB6 devs I know decided to learn a completely new syntax by going with C#. Weird, that.
Anyways, F# has an even smaller user base. And that's sad in a way, because there are things that functional languages like F# and SCALA just do a whole lot more elegantly than OO-based languages like VB, C# and Java. The best bit is that a single VS solution can contain projects written in any of the supported .NET languages.
* Before the inevitable flaming starts, have a look at the observer pattern in both languages (specifically RaiseEvent, VB, and the mess that is the C# equivalent).
Oh dear no. VB.NET was kept because of VB6ers whining at MS. Of course, they "fixed" the language, throwing away all the crap and hacking it so it would mostly match C#'s syntax. And C# is basically a pirated Java version which added nifty things that Java lacked, but then tied the whole thing to the MS stack.
Fortunately, the new wave of programmers have a true programming language background, which means C-like languages, that is C/C++/Java/C#; that and having C# being easy to make GUI apps for Windows meant VB wasn't the only easy path for Win32 apps and thus VB is finally dying off. But at least what passes for VB.NET these days is infinitely better than VB6.
It's like saying that Test Driven Development is the only way to unit test.
I've been coding in C++ with MFC since the early 90's, and in C# since the beta was released in 2001. C++ is fast and lean, but that's about it for most modern-day programming tasks. It introduces more security holes than any other popular language these days, and takes twice as long.
...it is also a language for projects which can't afford the development time of C++/Win32.
There is no doubt in the efficiency/speed/resource usage etc of C++ but there are many business projects which require quick turn around for a little scarifies in speed/resources. You simply can't beat the speed of development when using C#.
The latest trendy name for publish subscribe using OO. Still, I suppose giving it a simple name means idiots are more likely to think they can use it properly which is the whole point of design patterns in the first place since most of them just reinvented the wheel for a new , slightly dumber generation.
The reason is that vb.net is so different from vb6 that it's easier to go to c# (which *is* really MS Java). Your VB6 source won't run in VB.net anyway.
They left too much good stuff out of vb.net so it's a C programmer's concept of VB. Pointless.
That's why VB.net is less popular than VB6 was and VB programmers migrating to c#
That's the argument I hear every time this subject comes up. And it's bullshit.
The only thing VB.NET missed that C# had was unsigned ints. And that was included ages ago.
The reality is the other way 'round, actually. The My namespace doesn't even exist in C# (up to and including v4.0). As an (one) example, testing whether a network connection exists in C# requires pinging a server. In VB all you do is check My.Computer.Network.IsAvailable().
How is it easier to go to C#? VB.NET shares an identical syntax with VB6.0. Moving to C# requires learning the framework as well as a new syntax.
VB devs move to C# because they're given stupid arguments like you just made, without doing any homework themselves.
Make a real case.
"Moving to C# requires learning the framework as well as a new syntax."
That's because you didn't either have a proper CompSci education, or were contaminated by VB's thinking. Unfortunately there was no Dijkstra to scare devs off a crap language in the 90's; he did succeed in getting devs off COBOL.
VB.NET is a far more capable language than VB6 (rather VB.NET / C# are, as they are two sides of the same coin).
I'm not sure what has been "missed out", unless you mean such gems as On Error Goto.
The reason VB.NET is dying out, if any. is that migrating from VB.NET to C# isn't difficult and C# offers a somewhat more versatile and terse syntax.
"Developing an enterprise level ERP suite in C++ would be gibbering lunacy."
You should try telling that to Microsoft. They don't seem to be too keen to eat their own dogfood given that most of their major software is still written in C++ and assembler. Windows itself, Visual Studio, MS Office, SQL Server etc.
Anyone who can't see that C# and the CLR are just another MS upgrade treadmill for suckers and 2nd rater coders is living with their head in the clouds. As for all the comments about productivity - haven't you people ever heard of class libraries? No one suggesting you write every app from the ground up.
Dude, are you serious?
Creating an OS kernel is not quite the same as recording a customer interaction in a database. Using Word has different requirements (low memory footprint, 'specially when a document can be 100's of Mb large) to a CRUD app.
Why d'you think that SharePoint, Dynamics, etc. are written (by Microsoft) in C# rather than C++ (not even managed C++)?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
