C# verses VB.Net
-
I'm having an arguement with a coworker that wants me to use VB.Net instead of C# to program our ASP.Net application. I want to use C# because most programmers out of college learn Java, and C# is much closer of a syntax than VB is. We are going to hire 2 people for this project who just graduated from college. The college we are hiring from teaches Java.
His arguement is that VB.Net is much more previlent in the industry and that using C# goes against the industry standard. I have a suspicion that he really just doesn't want to learn C# because he already knows VB. (he's not even on the project)
Anyways, please help.
-
I think I can already see where this is going.
Try to think of it in terms of a negotiation token rather than a life or death decision. You're a smart, saavy IT professional, right? Not at all like those language bigots out there. You know it doesn't really make a whole heck of a lot of difference at the end of the day, so figure out how to use the point of contention to your advantage. Want to put more VB.Net experience on your resume? Give in grudgingly at the end and ask for concessions somewhere else, even if all you get out of it is a free ice cream sundae.
-
My advice is: Don't mix languages. .net allows you to do that, on a technical level, but it's not a good idea. Maintaing becomes much harder if you do. Either you win or your coworker wins.
Anyway, I think it's not bad for Java-programmer like you and your yet-to-hire coworkers to learn another language. If a Java programmer starts C#, he will inevitable use it the Java way. This would not be extremely terrible, but ugly anyway. Take your chance to learn another language and a bit more of .net anyway.
BTW: Tell your coworker to forget this "industry standard" nonsense. Simply not true. Both languages are commonly used.
-
Another point is that it is easier to translate C# to VB than the other way around. VB uses parentheses to mean too many things to narrow it down without reflecting the original VB code. So, if you do end up with a half and half project, it will be easier to make it all VB than all C#. It's also easier to translate C# found on the Internet to VB for the same reason. Good commercial converters have no problem, but the free stuff on the Internet likes C# to VB better.
Sometimes C# can be a little better -- I use C# for our Image library because of its support for unsafe code. GetPixel is really slow, so unsafe is a life saver there.
However, some things are easier in VB. Raising a custom event is 10 times easier in VB than it is in C#. The IDE is also better at making overloads in VB (prior to 2005). The VB IDE is far nicer than C#... it doesn't force you to rebuild to update Intellisense and it can even give you some Intellisense for code that won't compile. VB also fixes case where the C# IDE thinks you meant something different. All the little things add up to a smoother experience and lets you concentrate on what you are doing.
Being closer to Java is not really a good thing. The programmers may keep thinking they are writing Java and screw it up. The real work is learning the framework and that is the same for VB and C# and very different from Java.
At the end of the day, whoever sticks to their guns the most is wrong. Neither language is wrong, thinking that this is a major decision is the big mistake.
-
Doesn't .Net default to C#, like ASP Classic defaults to VBscript?
Why are we still using VB?
-
I'd be more concerned about the college kids joining the project than anything else.
But I concur with the others -- it's not a big deal and an experienced programmer can use either. You can stack up pros/cons on both sides of the scale, but at the end of the day, so long as you use OptionStrict/Explicit, there's no real difference.
-
One thing to consider career-wise is the salary differences between C# and VB.NET programmers. Folks incorrectly assume that VB programmers have less education/experience than C# programmers, and salaries reflect that:
So, if you are hiring developers, VB programmers may be cheaper. If you are working as a developer, you might want to pick C#.
Since the languages use the same common language runtime and the are converted to the same intermediate languages, the actual difference is purely syntactic. (Unless your VB programmers turn off Option Strict and Option Explicit, which can lead to a slow and buggy application)
The real question you need to ask yourself is: Do I like curly braces or do I like begin and end blocks?
Jim
-
@Alex Papadimoulis said:
I'd be more concerned about the college kids joining the project than anything else.
But I concur with the others -- it's not a big deal and an experienced programmer can use either. You can stack up pros/cons on both sides of the scale, but at the end of the day, so long as you use OptionStrict/Explicit, there's no real difference.
The real WTF is that MS doesn't turn those on by default. I hate having to both enable it on the project and then stick it at the top of each source file in case people turn it off.
Larry
-
@lpope187 said:
@Alex Papadimoulis said:
I'd be more concerned about the college kids joining the project than anything else.
But I concur with the others -- it's not a big deal and an experienced programmer can use either. You can stack up pros/cons on both sides of the scale, but at the end of the day, so long as you use OptionStrict/Explicit, there's no real difference.
The real WTF is that MS doesn't turn those on by default. I hate having to both enable it on the project and then stick it at the top of each source file in case people turn it off.
LarryMeanwhile MS support staff and forum moderators are overwhelmed with exchanges that look like this:
VBMan4242: WTF? VS.NET keeps telling me I have to "Dim" stuff! WTF does this mean??? I need help ASAP as my project is due in two hours! I've tried putting quarters into the corner diploma vending machine several times with no results. Help!
JSmith[MS]:VS.NET is informing you not that you need to "dim" anything, but that you yourself are dim. Have a nice day.
-
@Oscar L said:
@lpope187 said:
@Alex Papadimoulis said:
I'd be more concerned about the college kids joining the project than anything else.
But I concur with the others -- it's not a big deal and an experienced programmer can use either. You can stack up pros/cons on both sides of the scale, but at the end of the day, so long as you use OptionStrict/Explicit, there's no real difference.
The real WTF is that MS doesn't turn those on by default. I hate having to both enable it on the project and then stick it at the top of each source file in case people turn it off.
LarryMeanwhile MS support staff and forum moderators are overwhelmed with exchanges that look like this:
VBMan4242: WTF? VS.NET keeps telling me I have to "Dim" stuff! WTF does this mean??? I need help ASAP as my project is due in two hours! I've tried putting quarters into the corner diploma vending machine several times with no results. Help!
JSmith[MS]:VS.NET is informing you not that you need to "dim" anything, but that you yourself are dim. Have a nice day.
LOL that's awesome.
I'm usually a VB programmer because it looks (in my opinion) cleaner than C# (I *hate* curly braces), but with about an hours notice, I can switch to the other one. Why? because both languages are the same, except for curly-braces vs begin-end blocks. They have the same IDE, the same library, the same everything.
And BTW, I think ASP.Net defaults to VB, but I'm not sure.
-
@Albatross said:
@Oscar L said:
Meanwhile MS support staff and forum moderators are overwhelmed with exchanges that look like this:
VBMan4242: WTF? VS.NET keeps telling me I have to "Dim" stuff! WTF does this mean??? I need help ASAP as my project is due in two hours! I've tried putting quarters into the corner diploma vending machine several times with no results. Help!
JSmith[MS]:VS.NET is informing you not that you need to "dim" anything, but that you yourself are dim. Have a nice day.
LOL that's awesome.
I'm usually a VB programmer because it looks (in my opinion) cleaner than C# (I *hate* curly braces), but with about an hours notice, I can switch to the other one. Why? because both languages are the same, except for curly-braces vs begin-end blocks. They have the same IDE, the same library, the same everything.
And BTW, I think ASP.Net defaults to VB, but I'm not sure.
I agree that is awesome - it does sum up what would happen if MS had done that. But since I wouldn't have to answer the questions and it would solve my problems, I wouldn't care. It might actually drive out some of the WTFers. But since MS didn't do that, I guess I'll just have to get the operations guys to push those registry settings through the login script and then lock them down.
I've been programming in VB6, VBA, or VB.NET as my primary language for about the past 8 years. Although I've gotten used to it, I much prefer the C family of syntax as it was the first language I learned. For me, I like the simpler syntax expecially for logical operators. I prefer "if !someValue" over "If Not someValue Is Nothing". I constantly stumble over that syntax in VB since my brain says it should be "If someValue Is Not Nothing" which of course the compiler hates.
Personally, I don't care what language you use as long as you adhere to best practices including OOP, exception handling, tiered designs, etc. I can pick up the syntax by googling or searching MSDN.
As far as whether ASP.Net defaults to one language or another, I'm not even sure it's possible in .Net. I've never seen a similiar option in IIS to set it like you could for classic ASP (Jscript vs VBscript) - I guess it could be in the web config file though. Doesn't the framework handle compilation for code-behind based on the extension (.cs or .vb) and inline based on the language attribute of the page directive? I've never built an ASP.Net page outside of the VS IDE. I just modify the templates your given when you add a new web form.
Larry
-
<FONT face=Tahoma>IMO, like most of the posts here, it's more like a personal preference since they only differ mostly in syntax, although I read books that it is possible that some language (or compiler that is) that supports (or will support) the CLR may include in itself their own language specs / enhancements (like case-insensitivity in VB, etc).
This would be true of course if all the developers code with the framework in mind. And since both support one framework then there should be no problem reading other codes written in a different language. I myself used VB.NET and C#, but mostly C# recently, and I find it to be just syntactically different.
</FONT>
-
@Diamonds said:
I'm having an arguement with a coworker that wants me to use VB.Net instead of C# to program our ASP.Net application. I want to use C# because most programmers out of college learn Java, and C# is much closer of a syntax than VB is. We are going to hire 2 people for this project who just graduated from college. The college we are hiring from teaches Java.
His arguement is that VB.Net is much more previlent in the industry and that using C# goes against the industry standard. I have a suspicion that he really just doesn't want to learn C# because he already knows VB. (he's not even on the project)
Anyways, please help.
anyone who uses "industry standard" in an argument should be smacked on the head at the spot, and subsequently burned at the stake.
-
@masklinn said:
@Diamonds said:
I'm having an arguement with a coworker that wants me to use VB.Net instead of C# to program our ASP.Net application. I want to use C# because most programmers out of college learn Java, and C# is much closer of a syntax than VB is. We are going to hire 2 people for this project who just graduated from college. The college we are hiring from teaches Java.
His arguement is that VB.Net is much more previlent in the industry and that using C# goes against the industry standard. I have a suspicion that he really just doesn't want to learn C# because he already knows VB. (he's not even on the project)
Anyways, please help.
anyone who uses "industry standard" in an argument should be smacked on the head at the spot, and subsequently burned at the stake.
Would that be with an industry standard Clue x 4?
-
Thanks for your input everyone.
Re: college students
I'm actually really looking forward to working with them. College students have the nice natural ability to learn things very very fast. Which is pretty much a requirement in my companies work enviroment.VS.2003 defautls new ASP.Net projects to whatever language you selected it in. If you take out the tag I think the default is VB.
I think the best argument I've heard from people is that VB is a 'for dummies' language, but it can be very powerful. I feel that I'll get smarter programmers, and will be able to identify weak links by using C# over VB.
-
I had this very discussion with someone in the WTF forum. Here's the link. Ignoring the personal attacks, I believe the points I make as to why to use C# over VB speak for themself. My personal opinion is that VB.NET should never be used over C# unless most of the people on the project have never use any language other than VB.
You have to get at least into halfway through page 2 I think to really get at the true reasons.
-
@GoatCheez said:
I had this very discussion with someone in the WTF forum. Here's the link. Ignoring the personal attacks, I believe the points I make as to why to use C# over VB speak for themself. My personal opinion is that VB.NET should never be used over C# unless most of the people on the project have never use any language other than VB.
You have to get at least into halfway through page 2 I think to really get at the true reasons.
[don't worry, I have no intention of hijacking this thread, which as been a good, intelligent discussion so far. :) ]
GoatCheez -- if the "personal attacks" you mention are referring to anything I wrote, please let me know specifically what I wrote and I will immediately apologize. I did not intend to personally attack you.
-
So upset that you follow to another thread eh?
@Jeff S said:@GoatCheez said:
I had this very discussion with someone in the WTF forum. Here's the link. Ignoring the personal attacks, I believe the points I make as to why to use C# over VB speak for themself. My personal opinion is that VB.NET should never be used over C# unless most of the people on the project have never use any language other than VB.
You have to get at least into halfway through page 2 I think to really get at the true reasons.
[don't worry, I have no intention of hijacking this thread, which as been a good, intelligent discussion so far. :) ]
GoatCheez -- if the "personal attacks" you mention are referring to anything I wrote, please let me know specifically what I wrote and I will immediately apologize. I did not intend to personally attack you.
No intentions of hijacking this thread, even though your intentions are
obviously to get a response from me pertaining to your most recent post.
@Jeff S said:
Goat cheeze -- who cares what that particular person thinks of
their programming skills? Does this intimidate you? Do these "vb
programmers" hurt your feelings or affect your career? Should no one
ever be allowed to write any code other than people with 4-year college
degrees, multiple certifications, and 10-years of assembly experience?
Hobbyist programmers shouldn't exist? RAD programming that small
companies often need shouldn't be allowed? All code should be in one
of the languages that you approve of? (have you published a list yet,
by the way?)
Labelling all vb programmers in this manner makes
you sound bitter, jaded, ignorant and close-minded; grow up, open your
eyes and try opening your mind a little.
I don't need to explain how this is a personal attack.
@Jeff S said:
Thanks! That was a close one. I did not realize that if I start a new
project in VB.NET it will end up being the only language I am
comfortable in and I will end up forgetting any other language that I
know and being jobless and wandering the streets speaking only latin in
5-years! It's a shame that Vb and C# don't share any common libraries
or programming concepts...
In case some people are uninformed: Using sarcasm in this context implies that Jeff wants people to think that I am of inferior intelligence (retarded/stupid).
@Jeff S said:
I give up. I suppose any time you ignore the context of any sentence in
any conversation you can blindly draw whatever logical conclusions you
want for your own self-satisfaction.
Do I need to explain this as well?
@Jeff S said:
You must be quite a hit at cocktail parties! :)
What does my social interaction have anything to do with the discussion?
@Jeff S said:
OK. Ummm ... let's just move on, I'll give you a mulligan on that
one. (I love the irony of you finding flaws in my logic and asking me
to do research .. he he ) You are telling me that because those two
statements do not produce the same code, VB.NET is backwards
compatability with VB6. If you are not saying that (even though you
did :) ) then please try to clearly state your point.
You say that you will give me a mulligan, implying our conversation is a game to you. Then you try to mock me for pointing out the flaws in your logic, which are VERY numerous. I didn't comment on this before because I probably missed it. If you had read the articles I had listed, you would know what I was saying.
They do not produce the same code because in VB6, when you did s1 = s2, and one of the strings was null and the other was "", the result was true. This is the same in .NET for backwards compatibility. In C#, s1==s2 where one is null and the other is "" results in false. is you were to do s1.Equals(s2) in VB.NET, you would get the same results as the C# comparison.
@Jeff S said:
Ok, you've strung me along with this enough. ha ha. you got me.
seriously, I've got to stop falling for this trolling stuff and not
assume that everyone is actually trying sincerely to discuss the topic
... go ahead, laugh it up ...
Jeff: you are constantly putting words into other people's mouth for the sake of "discussion", then when they defend their words you call them a troller. I honestly do not understand what you are thinking.
Here it is... Any responses will be left with no reply, I'm done....
Why C# is a better choice than VB.NET:
Both languages are equivelent by most standards. Both use the same underlying API, and both have basically the same features, although there is a feature or two that one will have that the other does not. These features can be dismissed because programming around them is not difficult.
So then, why does such a heated discussion rage on?
Lol. I started writing my personal opinion, but deleted it. I honestly feel that my personal opinion on WHY should be kept to myself.
Ok, so then which should I use on my new project, VB.NET or C#?
Well, that depends on a couple things.
If anyone in the project group has never learned another language other than VB, then go with VB.NET. Chances are that C# is just too different for them to grasp quickly enough.
All other cases should go with C#. The reasoning: It will be easier to maintain in the long run. The maintenance has VERY LITTLE IF ANYTHING to do with the actual language. The only way language plays into it is in the form of the s1=s2 note. The fact is that most students learn Java or C. C# is EXTREMELY easy to pick up if you are coming from one of those backgrounds. You and your team probably won't be working on that project forever, so if you do pick up another person, they will most likely either know C#, or will be able to pick it up really fast. If they are limited to just using VB, then it was a bad hire. A programmer that is limited in their language selection is a limited programmer.
-
Sorry about the "cocktail party" joke ... I didn't think it was too offensive, I was kind of goofing around (i.e., did you see the smiley face?) but it was off topic and personal, so I apologize. That was rude and wrong and I am sorry it upset you. Please accept my apology. Heck, it didnt' hurt my feelings to omuch when you told me I should have learned basic logic in basic geometry, or that I should not call myself a programmer due to my lack of logic skills, or that I should "do my research", but I understand that we all have different levels of self-esteem and respond differently to different words. I will try to remember this in any future correspondence between us and promise to respect your feelings.
However, everything else you accuse me of has nothing to do with personal attacks, and every "tactic" you accuse me of using -- sarcasm, being condescending (how many times do you tell me I should do some research or learn basic logic), putting words in mouths, changing things around, etc -- is an oddly accurate description of what you did.
What is really rather humorous about this whole thing is this: what were my points? What was my position? Where was I coming from? I bet you don't even know. VB is better than C#? VB is "cool"? I am smarter than you because I like VB? You should be using VB? I only know VB and that's all I need to know? VB6 was a good language? There are no bad VB programmers out there? Nope. yet you were fighting and hammering away at me like I was trying to shove those ideas down your throat.
My points were quite simple:
a) VB.NET does not "suck"
b) All programmers who prefer VB are not "idiots"
c) It is not a "bad idea" to start a "new project" in VB.NET
That is what the "debate" was about. That's it. Those were my points. And those were the points that you were trying to refute over and over in any way you could, throwing random opinions and observations and "researched facts" out there, many of which were not only untrue, but often had nothing to do with VB.NET at all, and eventually you were forced to admit as much!
Ironically, I prefer C#, always have. I also would like to see those starting out in programming, who intend to make a career out of it, learn C# first. Yet you were so blind with your ignorance* on the topic that you didn't even understand what we were "debating" about.
--
* No, that is not a personal attack -- your postings and your
stance and your general remarks about "vb programmers" as well as your many
incorrect and misleading "researched facts" about VB.NET show a very high level of ignorance on
this topic; note that this does mean that you are an ignorant person in
general.
-
Use private messsaging please
-
Why C# is a better choice than VB.NET:
Both languages are
equivelent by most standards. Both use the same underlying API, and
both have basically the same features, although there is a feature or
two that one will have that the other does not. These features can be
dismissed because programming around them is not difficult.
Ok, so then which should I use on my new project, VB.NET or C#?
Well, that depends on a couple things.
If
anyone in the project group has never learned another language other
than VB, then go with VB.NET. Chances are that C# is just too different
for them to grasp quickly enough.
All other cases should go
with C#. The reasoning: It will be easier to maintain in the long run.
The maintenance has VERY LITTLE IF ANYTHING to do with the actual
language. The only way language plays into it is in the form of the
s1=s2 note. The fact is that most students learn Java or C. C# is
EXTREMELY easy to pick up if you are coming from one of those
backgrounds. You and your team probably won't be working on that
project forever, so if you do pick up another person, they will most
likely either know C#, or will be able to pick it up really fast. If
they are limited to just using VB, then it was a bad hire. A programmer
that is limited in their language selection is a limited programmer.
-
@GoatCheez said:
The fact is that most students learn Java or C (...) if you do pick up another person, they will most
likely either know C#, or will be able to pick it up really fast.
On the other hand, you might want to reconsider this argument once you see C# programs with getFoo()/setFoo(Foo foo) methods, made by Java programmers who do as they always did.
And I don't even want to imagine what a hardboiled C coder could do with C#.
For that reason, I think it's not too bad that those programmers (comming from Java or C) have to learn the new syntax of VB.net, so they can also learn how to do things the .net way.
-
@ammoQ said:
@GoatCheez said:
The fact is that most students learn Java or C (...) if you do pick up another person, they will most
likely either know C#, or will be able to pick it up really fast.
On the other hand, you might want to reconsider this argument once you see C# programs with getFoo()/setFoo(Foo foo) methods, made by Java programmers who do as they always did.
And I don't even want to imagine what a hardboiled C coder could do with C#.
For that reason, I think it's not too bad that those programmers (comming from Java or C) have to learn the new syntax of VB.net, so they can also learn how to do things the .net way.
I fail to see how learning new syntax would prevent java programmers from makeing Public Sub getFoo/setFoo(Foo foo)... I can see how a lowlevel C guy might start using global variables all over and such... But wouldn't he do that if he was using VB.NET as well? I kinda still fail to see how the syntax would have anything to do with their programming practices... I still think that the fact that s1=s2 is different from s1.equals(s2) would be enough to say "Uhhhhh, I think I'll go with what looks like what I know." Just an opinion though...
-
@GoatCheez said:
I fail to see how learning new syntax would prevent java programmers from makeing Public Sub getFoo/setFoo(Foo foo)... I can see how a lowlevel C guy might start using global variables all over and such... But wouldn't he do that if he was using VB.NET as well? I kinda still fail to see how the syntax would have anything to do with their programming practices... I still think that the fact that s1=s2 is different from s1.equals(s2) would be enough to say "Uhhhhh, I think I'll go with what looks like what I know." Just an opinion though...
VB syntax: Java programmer must at least read a book (and will most likely use the idioms presented in the book)
C# syntax: Java programmer goes a long way with trial&error (and intellisense)
-
@ammoQ said:
@GoatCheez said:
I fail to see how learning new syntax would prevent java programmers from makeing Public Sub getFoo/setFoo(Foo foo)... I can see how a lowlevel C guy might start using global variables all over and such... But wouldn't he do that if he was using VB.NET as well? I kinda still fail to see how the syntax would have anything to do with their programming practices... I still think that the fact that s1=s2 is different from s1.equals(s2) would be enough to say "Uhhhhh, I think I'll go with what looks like what I know." Just an opinion though...
VB syntax: Java programmer must at least read a book.
C# syntax: Java programmer goes a long way with trial&error (and intellisense)
I guess I'll have to agree to disagree. If a person is entering a new API, they may either choose or not choose to read a book describing that API. I believe that if a java programmer was going to read a book when starting their .NET application, then the language they chose would not matter. If they are going to read a book, they are going to read a book, regardless of their language choice. The VB syntax isn't so cryptic that a book is necessary to decipher it. I think in either case, the programmer would either buy a .NET book, or not buy a .NET book. There would be some cases where they would dive right in I guess, but I don't know many java programmers that would do it that way ;-P.
Ok, well, I'll agree to not fully agree lol ;-P
You do make a valid point.
lol.... Was trying to think of how to put this, and it sounds rather amusing...
So, the only advantage that VB has over C# when starting a new project in which none of the project members have used either is that: VB is slightly harder to learn (for syntax reasons) for people coming from a Java, C, or C++ background, so they would have more of a reason to buy a book, and therefore read it, which in turn would hopefully prevent some possibly bad programming practices they might carry over from their background to .NET.
That sounds really funny! lol!
So true, but SOOOOOOOOOOOOOO FUNNY!!!!
-
@Diamonds said:
His arguement is that VB.Net is much more previlent in the industry and that using C# goes against the industry standard. I have a suspicion that he really just doesn't want to learn C# because he already knows VB. (he's not even on the project)
Your suspicion is probably correct. The only difference in the languages is syntax really. There are reasons to use both. Here are some articles that might help you with your decision:
http://www.codeproject.com/dotnet/dnlp.asp http://blogs.msdn.com/csharpfaq/archive/2004/03/11/87816.aspx
From what you have described though, I would chose C#. That's just my opinion.
-
@GoatCheez said:
There would be some cases where they would dive right in I guess, but I don't know many java programmers that would do it that way ;-P.
Just take a look at my C# programs. Naming conventions? Well, in a few cases I remembered that method names should be capitalized. Properties? Hey, what's wrong with getters and setters. string==string? Last time I checked, string.Equals() worked.
Admited, I'm exaggerating, but these habbits are hard to break.
-
@ammoQ said:
@GoatCheez said:
There would be some cases where they would dive right in I guess, but I don't know many java programmers that would do it that way ;-P.
Just take a look at my C# programs. Naming conventions? Well, in a few cases I remembered that method names should be capitalized. Properties? Hey, what's wrong with getters and setters. string==string? Last time I checked, string.Equals() worked.
Admited, I'm exaggerating, but these habbits are hard to break.
Uhhh careful with that string thing.... I'll lay it out again:
In C#:
object1 == object2 compares the object references if they are reference types and not value types. It returns true if both variables reference the same object, or if both variables are value types and their values are equal.
object1.Equals(object2) compares the values of the objects, and returns true if they are equal.
In VB.NET:
object1 = object2 will return true when the objects are strings, and one is "", while the other is null. I assume all other cases work like C#, but I'm having trouble finding any documentation to verify that the other cases work like C#.
-
@GoatCheez said:
[
Uhhh careful with that string thing.... I'll lay it out again:
In C#:
object1 == object2 compares the object references if they are reference types and not value types. It returns true if both variables reference the same object, or if both variables are value types and their values are equal.
object1.Equals(object2) compares the values of the objects, and returns true if they are equal.
Last time I checked, the string class (definitely not a value type) had the == operator overwritten, so it did compare the value, not the reference.// created by ammoQ on 09.06.2006 at 23:19
using System;
using System.Text;
public class Goaty {
public static void Main() {
string x = "hello";
string y = string.Copy(x);
if (x==y)
Console.WriteLine("strings are equal");
}
}
-
Right... It's a value type... I was trying to point out that in VB,
Dim s1 as string
Dim s2 as string
Public Sub ShowStuff()
s1 = ""
Console.WriteLine((s1 = s2).ToString())
Console.WriteLine(s1.Equals(s2).ToString())
End Sub
Will output:
True
False
-
@GoatCheez said:
Right... It's a value type...
No, string is not a value type. Try reading some docs before making false claims (no insult intended)
-
@ammoQ said:
@GoatCheez said:
Right... It's a value type...
No, string is not a value type. Try reading some docs before making false claims (no insult intended)
Doh, good correction... Point still stands tho.
-
So I asked some people who know quite a bit more about this subject.
Q: Can someone give me an example of where using VB.NET in a new project would be a better choice than C# (and the reasoning of the project members only knowing VB doesn't count)
>GoatCheez, maybe when you are too lazy to write a proper runtime callable wrapper and wish to use VB.NET's late binding to call methods on legacy COM servers.
>GoatCheez, or when you want to write weak and dynamically typed code.
>If you ever wish to run your code under Mono, you're going to be screwed since your assemblies will become infected with the Microsoft.VisualBasic assembly.
>The VB.NET API isn't under the same ECMA standard as C#
>GoatCheez, Most universities teach either C,C++,Java, or even C#. That means when college students graduate they already have experience with a C based syntax language. I don't know very many universities teaching VB.NET
(I've been told this isn't entirely true about univerities not teaching VB.NET)
>GoatCheez, There's no Emacs mode for VB.NET but one exists for C# (Ok, now i'm running out of ideas)
>GoatCheez, here is one from Edgar Dijkstra "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
I asked a bunch of VB.NET people the same question in reverse.
Q: Can someone give me an example of where using C# in a new project would be a better choice than VB.NET (and the reasoning of the project members only knowing C# doesn't count)
No response yet
-
You missed my reasons above:
Reasons for VB:
1. Intellisense updates without rebuilding
2. Easier to source events.
3. Prior to 2005, easier to make overrides
4. No case sensitivity (at least for names)
5. Better IDE experience (example: make a property in VB and C# and you'll see that even though the VB code is twice as long, you still end up typing only half as much, the rest is generated by the IDE as you type).Reasons for C#:
1. Support for unsafe code
2. C# 3.0 looks realllllly cool, so better get practiced up.
3. Less typing
4. I'm sure there are more, but 99% of the other reasons boil down to less typing.
-
@jsmith said:
You missed my reasons above:
Reasons for VB:
1. Intellisense updates without rebuilding
2. Easier to source events.
3. Prior to 2005, easier to make overrides
4. No case sensitivity (at least for names)
5. Better IDE experience (example: make a property in VB and C# and you'll see that even though the VB code is twice as long, you still end up typing only half as much, the rest is generated by the IDE as you type).Reasons for C#:
1. Support for unsafe code
2. C# 3.0 looks realllllly cool, so better get practiced up.
3. Less typing
4. I'm sure there are more, but 99% of the other reasons boil down to less typing.
I love the auto-updating Intellisense in VB, although it's usefullness may not be as great in larger teams due to checkins/get latest. Its very nice when your the primary developer This also has the advantage of immediately informing me of syntax errors in the dependent projects when I'm refactoring some of my base classes - adding new parameters, method renames, etc. I do prefer the Select Case in VB over the switch statement in C#. The ability to put several conditions on one line is a plus over the multiline syntax of C#.
I do like the unsafe keyword in C# - can't beat the ability to do pointer manipulation when you need it. I've also noticed that C# does tend to produce faster code. I noticed this when I was building some basic deduplification component for a data warehouse. To preprocess 100k n-terms in VB took 50 seconds, while mostly equivalent C# code took about 30 seconds. Since performance is at a premium in DWs, I went with the C# even though SSIS uses VB.Net for Applications. I can't wait for C#.Net for Applications (if and when MS develops it. There is a language dropdown in SSIS, so I'm hoping that MS has something in the works).
Larry
-
@lpope187 said:
I've also noticed that C# does tend to produce faster code. I noticed
this when I was building some basic deduplification component for a
data warehouse. To preprocess 100k n-terms in VB took 50 seconds,
while mostly equivalent C# code took about 30 seconds. Since
performance is at a premium in DWs, I went with the C# even though SSIS
uses VB.Net for Applications. I can't wait for C#.Net for Applications
(if and when MS develops it. There is a language dropdown in SSIS, so
I'm hoping that MS has something in the works).
Why would C# or VB make a difference in a data warehouse? Are you not
using set-based T-SQL to process your data? Just curious.
-
@Jeff S said:
@lpope187 said:
I've also noticed that C# does tend to produce faster code. I noticed
this when I was building some basic deduplification component for a
data warehouse. To preprocess 100k n-terms in VB took 50 seconds,
while mostly equivalent C# code took about 30 seconds. Since
performance is at a premium in DWs, I went with the C# even though SSIS
uses VB.Net for Applications. I can't wait for C#.Net for Applications
(if and when MS develops it. There is a language dropdown in SSIS, so
I'm hoping that MS has something in the works).
Why would C# or VB make a difference in a data warehouse? Are you not
using set-based T-SQL to process your data? Just curious.
For a few things, but for the most part I was using Integration Services to process the data. At the time, I was integrating data from a call center system based on Sybase, a custom ERP system based on Oracle, web logs (both Apache and IIS), as well as various other SQL databases. As you could imagine, there was plenty of cleansing needed, everything from deduplification to stripping phone formatting to processing XML workflows. Doing all the data manipulation in SQL was possible, but tremendously slow.
In a typical data warehouse ETL, your processing a day's worth of
transactions in about a hour or so. Anything you can do to speed up
the process is a necessity. The advantage of SSIS is that the data is kept in memory and rarely dropped to disk increasing throughput. In SSIS you can build Script Tasks that use VB.Net for Applications - I used these when the standard tasks did not provide enough functionality. I used these to generate my own identity IDs, therefore the database engine did not have to generate them. I built several custom data transforms for SSIS in C# - one was a checksum/hashing component that could effectively deal with null columns. Another was a simple bi-term fuzzy matching component.
I employed every method I could to increase throughput such as disabling all the foreign keys, dropping indexes/constraints prior to load, generating my own identities, and setting the database to simple recovery to reduce transaction logging. Data warehouses are very strange beasts - I had to abandon all my prior database knowledge when I first started working on one.
Larry
-
@lpope187 said:
@Jeff S said:
@lpope187 said:
I've also noticed that C# does tend to produce faster code. I noticed this when I was building some basic deduplification component for a data warehouse. To preprocess 100k n-terms in VB took 50 seconds, while mostly equivalent C# code took about 30 seconds. Since performance is at a premium in DWs, I went with the C# even though SSIS uses VB.Net for Applications. I can't wait for C#.Net for Applications (if and when MS develops it. There is a language dropdown in SSIS, so I'm hoping that MS has something in the works).
Why would C# or VB make a difference in a data warehouse? Are you not using set-based T-SQL to process your data? Just curious.
For a few things, but for the most part I was using Integration Services to process the data. At the time, I was integrating data from a call center system based on Sybase, a custom ERP system based on Oracle, web logs (both Apache and IIS), as well as various other SQL databases. As you could imagine, there was plenty of cleansing needed, everything from deduplification to stripping phone formatting to processing XML workflows. Doing all the data manipulation in SQL was possible, but tremendously slow.
In a typical data warehouse ETL, your processing a day's worth of transactions in about a hour or so. Anything you can do to speed up the process is a necessity. The advantage of SSIS is that the data is kept in memory and rarely dropped to disk increasing throughput. In SSIS you can build Script Tasks that use VB.Net for Applications - I used these when the standard tasks did not provide enough functionality. I used these to generate my own identity IDs, therefore the database engine did not have to generate them. I built several custom data transforms for SSIS in C# - one was a checksum/hashing component that could effectively deal with null columns. Another was a simple bi-term fuzzy matching component.
I employed every method I could to increase throughput such as disabling all the foreign keys, dropping indexes/constraints prior to load, generating my own identities, and setting the database to simple recovery to reduce transaction logging. Data warehouses are very strange beasts - I had to abandon all my prior database knowledge when I first started working on one.
LarryI hear you, I've written many warehouses myself. However, in my experience I have always found that loading the raw data into staging tables and getting it all into SQL as soon as possible allowed for very fast processing. Once it is in staging tables, you can very quickly handle dups, nulls, lookups, identities, etc with set-based sql that will always outperform client-side processing either in C# or VB or whatever you're using. Then again, each situation calls for its own soluton and depeding on your skill level in the different languages and what technology is available there many ways to solve any problem so I can definitely understand your approach.
-
@Jeff S said:
I hear you, I've written many warehouses myself. However, in my experience I have always found that loading the raw data into staging tables and getting it all into SQL as soon as possible allowed for very fast processing. Once it is in staging tables, you can very quickly handle dups, nulls, lookups, identities, etc with set-based sql that will always outperform client-side processing either in C# or VB or whatever you're using. Then again, each situation calls for its own soluton and depeding on your skill level in the different languages and what technology is available there many ways to solve any problem so I can definitely understand your approach.
I think most of it had to do with the custom ERP system. The backend Oracle database was some hybrid design. It was partially object-oriented and partially relational. There was no customer master - each transaction was linked to an instance of a customer. The XML workflows contained the current status of the transaction, so you would have XQuery the column to understand what to do with it. For 100k transactions the XML workflows took up 6Gb of space - As you can imagine batch processing was slow.
The custom ERP system was definitely enterprisey. Each object was serialized and deserialized every time it was passed around. It didn't matter if it was being passed around in the same app domain or not. At least they knew it was f***ed up. When I left to take my current position, the were eliciting ideas to simplify the system including only serializing when going between app domains. Thankfully I only had to deal with reading data out of the system and not designing and supporting that monstrosity.
Larry
-
@jsmith said:
1. Intellisense updates without rebuilding
4. No case sensitivity (at least for names)
5. Better IDE experience (example: make a property in VB and C# and you'll see that even though the VB code is twice as long, you still end up typing only half as much, the rest is generated by the IDE as you type).
1. I have VC# 2005 Express on here and intellisense updates automatically without rebuilding.
4. Entirely subjective.
5. VC# has code snippets to automatically generate code, and it does so in an unintrusive way, which is one of my main hates about VB's IDE. I don't want the editor to write code when I haven't told it to.
-
The main reason I prefer C# over VB.Net is it is so much easier to find automated tools that will work with C#, and many others will only output in C#. Seems a lot of the open source community doesn't really care for VB.Net.
ᐈ eSports News & Tricks (2024) 🥇 ENEWS.GG
