VBA & .NET - differences ?

[garywork]

Hi

i know what vba is esp. vba for applications in Office but what is .NET ?

Is it a newer version of VBA but not the office version which is still going ?

was going to learn some VBA but not sure if i should be going .NET instead

i'm a programmer on older tech and vba appeals at the moment

any pointers appreciated

thanks

 

[Inquisitor]

VB.NET and VBA are utterly, utterly different. VBA is an old scripting language with fairly limited applications (i.e. Office), while VB.NET is a fully-fledged, modern, object-oriented programming language that can be used to write large-scale programs, websites, etc. much in the same way that a language such as C++ would allow. VB.NET is almost certainly a better choice, unless all you want to do is automate certain tasks in Office.

 

[garywork]

ok - useful info

tx

 

[estebanrey]

Well techincally ".NET" is a runtime environment and not a language, like VBA.

You can code in VB, C++, C# and more in the .NET environment but if you're talking specifically about VB.NET then Inquisitor's advice is sound.

However, if you want to make big £££, then ironically VBA is probably a better way to go as there's a big demand for automated spreadsheets and Access macros in "the City".

I love VB.NET and it's the language I program in but unfortunately there is a lot of snobbery towards it. Unfortunatley there are a lot of programmers whop switched to C# or C++ in the days of VB6 and still hold the same 'superiority complex' over VB despite the .NET itteration of the language being no "worse" than any other language.

The other day I had to correct a professional programmer who told me that C# programmes were 8-10 times 'faster' than application ran in VB. I proved him wrong with an article from Microsoft themselves and he still doubted it!!! I wouldn't have minded but the company I work for had just paid this guy £35k for a piece of software (which I could have written in VB).

It's a hard one, as I said I love VB.NET but at the moment being a VB.NET programmer is still seen as a lesser skill than other languages.

 

[Inquisitor]

The thing about VB.NET and C# is that they fulfil practically identical purposes. They're almost the same language with different syntaxes and a few minor differences in their feature sets. There's really not much reason for both of them to exist, and I think since VB.NET has the legacy of VB6's verbose and somewhat child-like syntax, people decry it for being pointless.

 

[estebanrey]

"child-like syntax", hmmm I would say 'easier to read' but you highlight the snobbishness point I made quite well.

There are programmers who think unless a language looks like a random bunch of letters and symbols to the untrained eye then it aint "real".

I would also say C# was closer to Java than VB.NET (in syntax anyway).

 

[Goofball]

There's really only one place where VB is lacking, The aforementioned lambda syntax. It's horribly wordy. Doing Moq setups and verificions in VB is something you try once before deleting, and recreating it in C#.

And properties used to be a royal pain in the ***. I wouldn't be suprised if half the code in any given VB 7-9 system is property declarations (9 lines each!). At least you got adept at scrolling... (and you still do if you want your types to be immutable)

Other than that, I don't really mind either now that VB finally got auto properties and somewhat proper implicit line continuations.

 

[estebanrey]

There's really only one place where VB is lacking, The aforementioned lambda syntax. It's horribly wordy. Doing Moq setups and verificions in VB is something you try once before deleting, and recreating it in C#.

And properties used to be a royal pain in the ***. I wouldn't be suprised if half the code in any given VB 7-9 system is property declarations (9 lines each!). At least you got adept at scrolling... (and you still do if you want your types to be immutable)

Other than that, I don't really mind either now that VB finally got auto properties and somewhat proper implicit line continuations.

But on the other hand you save one character every line as you don't have to put a semi-colon there!

You sure you're talking about VB.NET and not VB6 and previous (which was a different language)?

Here look at this example which is written in both VB.NET & C#

http://msdn.microsoft.com/en-us/library/system.windows.forms.application.doevents.aspx

The VB.NET version is 1642 characters on 55 lines of code whereas the C# version is 1612 chars on 62 lines of code so actually the C# takes up more space!

At least you got adept at scrolling

 

[Pho]

.

/devils advocate

With spaces the VB.NET version is 55 lines and 1854 characters. Using an online converter to convert the VB.NET version to C# (which is probably largely similar to how MS do their examples) then the C# version is also 55 lines but only 1788 characters. That's a saving of 66 characters .

The reason the C# version is longer to start with is that they'e just dropped function parameters onto a new line when they don't need to be.

 

[DanF]

vbnet c# comparison

Personally I prefer the c# way

Dim o As Object = 2
vs
object o = 2;

Sub SayHello(ByVal name As String, Optional ByVal prefix As String = "")
Console.WriteLine("Greetings, " & prefix & " " & name)
End Sub

vs

void SayHello(string name, string prefix = "") {
Console.WriteLine("Greetings, " + prefix + " " + name);
}

Also didn't they find that c# tends to make slightly better IL and get a really minor speed advantage, probably nothing to write home about.

 

[Dj_Jestar]

http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET

How did I know this would turn into a C# vs VB.NET thread

 

[estebanrey]

vbnet c# comparison

Personally I prefer the c# way

Dim o As Object = 2
vs
object o = 2;

The VB.NET example could be cut down to...

Dim 0 = 2

You don't need to say "as Object" and if you do want to define it then in that case you'd say "as Integer" (in your example) but as I said you don't have to declare it at all.

Sub SayHello(ByVal name As String, Optional ByVal prefix As String = "")
Console.WriteLine("Greetings, " & prefix & " " & name)
End Sub

vs

void SayHello(string name, string prefix = "") {
Console.WriteLine("Greetings, " + prefix + " " + name);
}

Why is the C# better? It looks more messy IMO and the word "void" makes it look like you don't want it to do something.

Also didn't they find that c# tends to make slightly better IL and get a really minor speed advantage, probably nothing to write home about.

NO, NO, NO!!!!! Again you are compring C# with VB6 and not VB.NET which is a diffrent language. Please read this...

“Although the Visual Basic Runtime uses some additional memory, there is no perceptible performance penalty. As shown earlier in this paper, Visual Basic .NET and C# applications compiled with comparable compiler options run equally fast.”

source: http://msdn.microsoft.com/en-us/library/aa289509(VS.71).aspx

 

[Goofball]

The IL should be equivalent, apart from the VB compiler adding some "nop" instructions on non-executable statements for the debugger ("else", "end if" "end function" "case else" etc..) in debug mode.

You sure you're talking about VB.NET and not VB6 and previous (which was a different language)?

If bothered reading my post, you'd know I was not talking about VB6 as the senence you comment states "VB 7-9", where declaring a mutable property takes up 9 lines of code.

 

[estebanrey]

The IL should be equivalent, apart from the VB compiler adding some "nop" instructions on non-executable statements for the debugger ("else", "end if" "end function" "case else" etc..) in debug mode.

If bothered reading my post, you'd know I was not talking about VB6 as the senence you comment states "VB 7-9", where declaring a mutable property takes up 9 lines of code.

Don't you use the StringBuilder class? Give me a coded example......

 

[Goofball]

Don't you use the StringBuilder class? Give me a coded example......

What does a StringBuilder have to do with this? Do you even know what a property is? Seems like you're missing some of the basics here...

' The messy pain in the b*** VB 7-9 way
private _myString as string
public property MyString as string
   get
        return _myString
   end get
   set(value as string)
       _myString = value
   end set
end property

// The C# 3 way, no backing variable
public string MyString {get; set;}

' The new improved VB 10 way, implicitly declares a private backing variable "_myString"
public property MyString as string

In short, a class with n properties will have n*10 lines of code (including newline in between then) just for declaring basic setters/getters. For instance an entity (table) in NHibernate with 10 columns would be 100 lines of code in VB 7-9, while it is 10 lines in C# 3-4 and VB 10.

 

[Mr^B]

Technically .Net is a framework, not a runtime environment. The runtime environment (CLR) is part of the .Net framework.

CLR + Class Library = .Net Framework

*pedant mode off*

VB.Net and C# arguments are pointlesss. C# developers will earn the most (typically) because of the perceived additional skill required to master it. VB.net is still seen (rightly or wrongly) as a basic language (pun intended) and most self-professed 'hard-core' developers will sneer at VB.Net, even though it will produce almost identical IL.

 

[Inquisitor]

"child-like syntax", hmmm I would say 'easier to read' but you highlight the snobbishness point I made quite well.

There are programmers who think unless a language looks like a random bunch of letters and symbols to the untrained eye then it aint "real".

I would also say C# was closer to Java than VB.NET (in syntax anyway).

Well I say that because VB originated from BASIC, which was designed for pedagogical purposes and was never intended to be used in a production environment. For that reason it inherited a syntax that was designed to be easy for beginners to understand rather than for terseness and efficiency in every day use. Perhaps child-like was a little unfair, though

VB.NET vs. C# arguments are pointless because the languages are so similar. Ultimately it's down to which is more appropriate for the job (which is usually irrelevant as the feature sets are nearly identical) and the developer's preference of syntax. Really, though, any .NET developer should be able use both given a little bit of time learning the syntactic differences.

 

[estebanrey]

What does a StringBuilder have to do with this? Do you even know what a property is? Seems like you're missing some of the basics here...

' The messy pain in the b*** VB 7-9 way
private _myString as string
public property MyString as string
   get
        return _myString
   end get
   set(value as string)
       _myString = value
   end set
end property

// The C# 3 way, no backing variable
public string MyString {get; set;}

' The new improved VB 10 way, implicitly declares a private backing variable "_myString"
public property MyString as string

In short, a class with n properties will have n*10 lines of code (including newline in between then) just for declaring basic setters/getters. For instance an entity (table) in NHibernate with 10 columns would be 100 lines of code in VB 7-9, while it is 10 lines in C# 3-4 and VB 10.

I thought you meant a mutable object and by default strings are immutable so you have to use the StringBuilder to create a mutable one. The term "mutable property" is one I admit is not familar with me and after a quick Google check it seems something that is only mentioned by C# developers so I'm not too gutted about it as I don't know C#. It's like critisising me for not knowing a C++ expression.

But as I use VB10 this is all irrelevant anyway, which you admit in your last line!!!

Again, I am not talking about old versions of VB, you might as well start highlighting the flaws with VB6 and before otherwise. So I don't actually get what your point is....

Technically .Net is a framework, not a runtime environment. The runtime environment (CLR) is part of the .Net framework.

CLR + Class Library = .Net Framework

*pedant mode off*

VB.Net and C# arguments are pointlesss. C# developers will earn the most (typically) because of the perceived additional skill required to master it. VB.net is still seen (rightly or wrongly) as a basic language (pun intended) and most self-professed 'hard-core' developers will sneer at VB.Net, even though it will produce almost identical IL.

Exactly, I just wish they'd admit it instead of giving example from old versions of the language and obscure code that has very specific useages and very rare.

Well I say that because VB originated from BASIC, which was designed for pedagogical purposes and was never intended to be used in a production environment. For that reason it inherited a syntax that was designed to be easy for beginners to understand rather than for terseness and efficiency in every day use. Perhaps child-like was a little unfair, though

But VB.NET language is not the same as VB language. Yes it supports backward compaitble statements but I have a VB6 expert at my work and he is no better at reading my VB.NET code as I do reading C#.

 

[HumbleCoder]

The VB.NET example could be cut down to...

Dim 0 = 2

You don't need to say "as Object" and if you do want to define it then in that case you'd say "as Integer" (in your example) but as I said you don't have to declare it at all.

Not to be picky but I presume (not being a VB.NET mastero) Dim O = 2 C#'s equivalent would be var O = 2; which is different to the other poster wrote. Missing off the type would cause the type of O to be inferred to Int32 which is not the same as Object O = 2;

If you're saying no one would assign to 2 to an Object type then I'd agree, both compilers would emit IL to box the value type to the reference type which is bad for performance.

 

[Inquisitor]

But VB.NET language is not the same as VB language. Yes it supports backward compaitble statements but I have a VB6 expert at my work and he is no better at reading my VB.NET code as I do reading C#.

Of course, but my point still stands. Despite being a totally different language from VB6, VB.NET retains the legacy of "beginner-oriented" syntax, whether or not that's still its purpose.