Join 307,215 Programmers for FREE! Get instant access to thousands of experts, tutorials, code snippets, and more! There are 1,562 people online right now. Registration is fast and FREE... Join Now!
Recently we discussed some of the upcoming new features in C# so I decided we needed to give both major .Net languages equal facetime. Now we all know, according to Microsoft, that upcoming features to one language will be implemented in the other language, what Microsoft calls co-exist, but we all know that eventually there will be a single .Net Language (not counting Visual C++, F#, J#, etc).
Some of the new features coming to VB.NET (Which will be version 10) are (this is not meant to be an all inclusive list)
Auto implemented properties
QUOTE
When this feature came to C# it created real language envy among VB developers. In those instances where all you need a property to do is hold a value (i.e. where a public field would do the job nicely if it wasn’t evil), C# 3.0 allows the developer to write the property using a shorthand notation and the compiler will implement the private field for you:
In C# this
CODE
public int CustomerID { get { return customerIdField; } set { customerIdField = value; } }
Can now be written like
CODE
public int CustomerID { get; set; }
Now with VB.NET 10 VB will have this with this syntax
CODE
Public Property CustomerID As Integer
Collection Initializers
Another feature C# has that is missing from VB.NET is the ability to declare and initialize a collection in one go. Well, the playing field is getting leveled a little more in .NET 4.0 as this feature is added to VB. The syntax will look like this
CODE
Dim words As New List(Of String) From {"Hello", "World"}
Implicit Line Continuations This is something a lot of VB.NET programmers have been waiting for. It was that you had to let the compiler know the line continued to the next like with a _ at the end of the line. With VB.NET 1.0 the compiler will know what to do with this
CODE
Dim s As String = “Hello” & “World”
So as you can see VB.NET gurus Microsoft is making changes to your language, some a lot will not agree with, as they'll feel it's making it too much like C# (Is that a bad thing?), others will make your lives much easier, such as Collection Initializers.
I know that I'm new to programming, VB.NET is the only language I know, but I do not see this as such a bad thing. I can understand most of C# now, while I can only understand small amounts of Java. I can only imagine what programmers are going to say about this, but are they valid consirns or is it the change that is going to be the biggest issue?
P.S. I've written this post with my phone because I have no other internet; I apoligise for my spelling for all those who read this.
Thanks for the post. It might have been more helpful if the innuendos of "C# is better than VB.NET" were left out, or if a VB.NET developer who understands and enjoys the language had written it.
Each language has its strengths. If a shop of Java or C++ programmers is converting to .NET, C# is the obvious way to go. If a shop was primarily VB6, then VB.NET is the best way to go.
In my experience, Java and C++ programmers have difficulty adjusting to the more advanced, higher-level language syntax of VB. VB programmers have difficulty taking a step backwards into the arcane curly bracket and semicolon syntax of C#. That is why MS made multiple languages in .NET - so programmers could retain much of the familiarity from their previous environment and coalesce around a single framework. Both languages are little more than syntactic sugar around the same framework. In fact, though most of my programming is in C#, I sometimes use the Microsoft.VisualBasic namespace to access some of the stuff they have that isn't available elsewhere. For example, I write "OCXs" in C# that existing VB6 code uses, which is only possible because MS published the Interop Forms Toolkit for VB.NET.
VB programmers who were programming object oriented VB6 code had no trouble moving to VB.NET. The similarities are many. The VB programmers who were stuck in 80s-style procedural programming are the ones who had trouble making the jump to VB.NET, just as many C++ programmers have problems adjusting to using an existing framework.
In the end, the only real differences between C# and VB.NET, where the goal is to deliver a working, stable product, are that VB.NET takes slightly less development time, and existing object oriented VB6 code can be migrated faster to VB.NET than C#. How about an article that spends more time on new VB features and no time on extolling the virtues of C#?
This post has been edited by MSBassSinger: 19 Aug, 2009 - 09:58 AM
I actually won't mind the changes for C#, but the changes for VB. NET are gonna bother me. I am use to the _, now I will be getting syntax errors all over the place. But this doesn't mean I won't upgrade from VB .NET 9, I will... it will just take me a while to adjust not using _. And I do program with C#, but it is not one of the top languages I will use in VS2010.
This post has been edited by Viper2KX: 19 Aug, 2009 - 09:59 AM
Thanks for the post. It might have been more helpful if the innuendos of "C# is better than VB.NET" were left out, or if a VB.NET developer who understands and enjoys the language had written it.
...
In the end, the only real differences between C# and VB.NET, where the goal is to deliver a working, stable product, are that VB.NET takes slightly less development time, and existing object oriented VB6 code can be migrated faster to VB.NET than C#. How about an article that spends more time on new VB features and no time on extolling the virtues of C#?
I think that's a bit unfair he didn't have to post anything at all about the changes to VB. And I certainly didn't see much of the C# is better than VB.NET. It was closer VB.NET compiler is getting some of the extra features that were part of C#
VB.NET only takes less time if you used to using legacy VB6 style methods.
For instance Len(strRandom) is legacy VB and works in VB.NET because of the compatibility namespaces.
In my opinion that code is bad practice in VB.NET and by now you should be using the new .NET methods of strRandom.Length() which is universal to both VB.NET and C#.
I would personally like to see VB.NET get all the refactoring capabilities of C# as well as some of the automatic completion you get in C# with the tab key.
And before you say I am obviously not a VB developer the first language I learnt was VB6, then VB.NET. Then i started to do some web stuff and tiny bit of C++ before starting to learn C#.
I now use C# purely for the extra features in the IDE.
Thanks for the post. It might have been more helpful if the innuendos of "C# is better than VB.NET" were left out, or if a VB.NET developer who understands and enjoys the language had written it.
If you're referring to me I dont see anywhere I even hinted that C# is better than VB.NET. I'm not the type of person who will engage in a debate like that as all languages have their pros and cons, so please clarify that statement
QUOTE(MSBassSinger @ 19 Aug, 2009 - 04:58 AM)
VB programmers who were programming object oriented VB6 code had no trouble moving to VB.NET. The similarities are many. The VB programmers who were stuck in 80s-style procedural programming are the ones who had trouble making the jump to VB.NET, just as many C++ programmers have problems adjusting to using an existing framework.
OO VB6?! That doesnt exist, VB6 is not an OO language, not even close. Visual Basic (before VB.NET) was not created as an OO language, and really has none of the OO capabilities of an OO language. How long have you been programming again?
QUOTE(MSBassSinger @ 19 Aug, 2009 - 04:58 AM)
In the end, the only real differences between C# and VB.NET, where the goal is to deliver a working, stable product, are that VB.NET takes slightly less development time, and existing object oriented VB6 code can be migrated faster to VB.NET than C#. How about an article that spends more time on new VB features and no time on extolling the virtues of C#?
Actually there are far more differences than that (but that's not what this thread is all about), and there is NO "OO VB6" code anywhere, it's not OO capable, not even close
QUOTE(MSBassSinger @ 19 Aug, 2009 - 04:58 AM)
I sometimes use the Microsoft.VisualBasic namespace to access some of the stuff they have that isn't available elsewhere.
Bad idea, that Namespace is only there for lazy programmers who refuse to fully make the switch (and so old applications can still work while the team is converting it to .Net) it was not intended to actually be used all the time.
EDIT: Since you brought it up C# is actually a better language, as evidence of all the features of it that are being brought into VB.NET
I think that's a bit unfair he didn't have to post anything at all about the changes to VB. And I certainly didn't see much of the C# is better than VB.NET. It was closer VB.NET compiler is getting some of the extra features that were part of C#
That, of course, is not what I said. And yes, the context of his post was from the perspective of C# is better than VB.NET. For example: "but we all know that eventually there will be a single .Net Language" "So as you can see VB.NET gurus Microsoft is making changes to your language, some a lot will not agree with" "they'll feel it's making it too much like C# (Is that a bad thing?)"
QUOTE(danny_kay1710 @ 19 Aug, 2009 - 10:21 AM)
VB.NET only takes less time if you used to using legacy VB6 style methods.
Not really. One example is events. Much better done in VB.NET. I never used the legacy VB stuff because that didn't fit in with using the framework, and for some of it, performance was poor. It was only provided to help with interim migration code from VB6, not as what should be in the final production code.
QUOTE(danny_kay1710 @ 19 Aug, 2009 - 10:21 AM)
I would personally like to see VB.NET get all the refactoring capabilities of C# as well as some of the automatic completion you get in C# with the tab key.
Yes, that I agree with, although I haven't seen any lack of code completion in VB.NET. But that is IDE stuff, not necessarily language-oriented stuff. And it is good to see C# is finally getting optional parameters, something VB had even before .NET. And I am still waiting for the edit-and-continue to catch up to what we had 15 years ago in VB6.
QUOTE(danny_kay1710 @ 19 Aug, 2009 - 10:21 AM)
I now use C# purely for the extra features in the IDE.
I would love to see a posting of what the IDE has in it for C# that isn't in there for VB.NET. A free refactoring tool came with the Visual Studio I bought for VB.NET, so it isn't refactoring. I don't doubt there are some, but I have yet to see what they are. There are always things I can learn.
If you're referring to me I dont see anywhere I even hinted that C# is better than VB.NET. I'm not the type of person who will engage in a debate like that as all languages have their pros and cons, so please clarify that statement
See above where someone else asked the same thing. And you final statement in the post I am replying to proves me right.
QUOTE(PsychoCoder @ 19 Aug, 2009 - 10:40 AM)
OO VB6?! That doesnt exist, VB6 is not an OO language, not even close. Visual Basic (before VB.NET) was not created as an OO language, and really has none of the OO capabilities of an OO language. How long have you been programming again?
I have been prgramming since 1978, in a lot of langauges over time. And yes, if you knew VB6, you'd know how to write OO VB6 programs. I've been doing just that since 1997 (with VB5). I can do polymorphism, encapsulation, interface and binary inheritance in VB6. Granted, it lacks operator overloading, and the closest you can come to method overloading is with optional parameters. But, while it is limited in OOP features, it is most of the way there. My VB6 programs rarely used .BAS files. VB.NET and C# implement OOP much better than VB6 for OOP, but you cannot know VB6 and still make that claim honestly.
QUOTE(PsychoCoder @ 19 Aug, 2009 - 10:40 AM)
...there is NO "OO VB6" code anywhere, it's not OO capable, not even close
Care to make a wager? If I thought it would be useful, as out of date as new VB6 code is now, I'd happily post an article on it with the source code.
QUOTE(PsychoCoder @ 19 Aug, 2009 - 10:40 AM)
Bad idea, that Namespace is only there for lazy programmers who refuse to fully make the switch (and so old applications can still work while the team is converting it to .Net) it was not intended to actually be used all the time.
Wrong again. You are thinking of the Microsoft.VisualBasic.Compatibility namespace. That one I avoid.
QUOTE(PsychoCoder @ 19 Aug, 2009 - 10:40 AM)
Since you brought it up C# is actually a better language, as evidence of all the features of it that are being brought into VB.NET
Thus you concede that what I saw in your original post is a reflection of what you believe. And nothing wrong with beleiving that - for C-style programmers, C# is definitely a better language. Of course, there are a lot of features from VB6 and VB.NET that made their way into C#, so that argument fails. Please understand that what makes C# or VB.NET or any of the other .NET languages better than another is what is in the language that makes the programmer more productive.
That, of course, is not what I said. And yes, the context of his post was from the perspective of C# is better than VB.NET. For example: "but we all know that eventually there will be a single .Net Language" "So as you can see VB.NET gurus Microsoft is making changes to your language, some a lot will not agree with" "they'll feel it's making it too much like C# (Is that a bad thing?)"
Where did he suggest the one language would be C#. He highlighted some changes that would make VB.NET a closer match to C# but i do not think it was written in the style to suggest that C# is better because it already has these.
QUOTE(MSBassSinger @ 19 Aug, 2009 - 10:42 AM)
Not really. One example is events. Much better done in VB.NET. I never used the legacy VB stuff because that didn't fit in with using the framework, and for some of it, performance was poor. It was only provided to help with interim migration code from VB6, not as what should be in the final production code.
Basically your arguing that if your used to VB6 you should use VB.NET because the syntax is the same or very similar. Whilst I agree with this to a point, I think a good programmer should be able to look beyond syntax and be able to use both VB.NET and C# since essentially they will both use the same framework functions (barring the compatibility namespace).
QUOTE(MSBassSinger @ 19 Aug, 2009 - 10:42 AM)
I would love to see a posting of what the IDE has in it for C# that isn't in there for VB.NET. A free refactoring tool came with the Visual Studio I bought for VB.NET, so it isn't refactoring. I don't doubt there are some, but I have yet to see what they are. There are always things I can learn.
Code completion seems a strange one, whilst I use it all the time in C# - at work when I use VB.NET it seems temperamental. It doesn't work with as much as it does in C# i believe without diving into specifics.
Well uninstall the re factoring tool you happen to use and maybe you will find out. Remember not everyone has these tools installed.
I have nothing against VB.NET up until recently it was my preferred language. I migrated from VB.NET and stopped using legacy aspects of VB. I cannot see how once you have gotten to this point why VB.NET would be any quicker, regardless of your prior language knowledge
I had never even looked at C# before I attempted my first project in it and within 10 minutes it was as if I had used it for years.
This post has been edited by danny_kay1710: 19 Aug, 2009 - 12:57 PM
I like the addition of Multi-Line Lambdas and Lambda Subs.
Not a fan of the implicit line continuations in the beta, if I happen to catch the return key. Instead of a single press of the delete key to return things how they were, its a mouse highlight delete (to remove all the empty spaces). It needs tweaking that an enter followed be a delete, means the user didn't want the newline so undo.
The parallel extension are nice addition and simple to use but I fear that they maybe too simple and the noobs will misuse them. Also I believe because of this simplicity, noobs will be thrown by the sometime likely event of the results being different in different runs, will make them think there is bug in the code. The error messages which are thrown by the parallel are big. (See Post)