November 13, 2009 at 12:32 pm
michael.rosquist (11/13/2009)
I find VB.NET better.3. C# is harder to read (and uglier) due to parentesies and brackets:
C#
public static void HandleControl(System.Web.UI.Control oControl, System.Type oType,
ProcessControlDelegate controlMethod, DelegateArgs delegateParam, bool exactType, int depth)
{
if (((exactType == true) && (oControl.GetType() == oType)) ||
(oType.IsInstanceOfType(oControl)))
{
if (null != controlMethod)
{
controlMethod(oControl, delegateParam, depth);
}
}
depth += 1;
foreach (System.Web.UI.Control oChildControl in oControl.Controls)
{
HandleControl(oChildControl, oType, controlMethod, delegateParam, exactType, depth);
}
}
I didn't read the whole thread and this post was a long time ago, but it made my eyes bleed so I had to respond.
If you intentionally introduce unnecessary curly braces in order to make the code look bad, then the code will (of course) look bad. Only one set of braces is needed for your code block:
public static void HandleControl(System.Web.UI.Control oControl, System.Type oType,
ProcessControlDelegate controlMethod, DelegateArgs delegateParam, bool exactType, int depth)
{
if (((exactType == true) && (oControl.GetType() == oType)) || (oType.IsInstanceOfType(oControl)))
if (null != controlMethod)
controlMethod(oControl, delegateParam, depth);
depth += 1;
foreach (System.Web.UI.Control oChildControl in oControl.Controls)
HandleControl(oChildControl, oType, controlMethod, delegateParam, exactType, depth);
}
As for the original question (VB.Net vs C#), I have to agree with all of the people who favor C# due to its similarity to C/C++/Java/JavaScript as well as the number of jobs targetting C#. I'm not sure that there is a technical superiority one way or the other, but external factors such as syntax familiarity and potential jobs give C# the edge (IMO, of course).
That said, if I were a career VB developer I would find no reason to switch to C# unless I were actively looking for a job. And if I were to hire a new developer I would have no problem with a VB.Net candidate applying for a C# job. If you're a good VB.Net programmer you're going to pick up C# just fine.
November 13, 2009 at 12:32 pm
Threads like these always get out of hand (look at my previous post), but I like them anyway as it is a nice occasion to voice ones views. For me C# and VB .NET (as well as Java) are from an architectural point of view dead ends, all they do is candy problems over and push the deadline we have to deal with a few years further in the future.
There will be a distinction in software that needs more power and has to go multi-threaded or at least be aware of it and thus require subsequently more programmer control, and the single thread coding we are all used to from today/yesterday. There really is no magic middle ground that isn't been used or in use today already. From this angle I rather see people actually learn how things work and become good at programming (controlling things) then learn to accept blind faith that the magic platform will solve it all.
The question of which GC language without time precise destructors is better is therefore utterly irrelevant.
November 13, 2009 at 12:34 pm
I love VB.NET it'll be unfortunate it it'll be phased out..
i also love the fact that you don't have to build in vb.net to get rid of the compile errors.
November 13, 2009 at 12:43 pm
Peter,
I've worked on a multi-threaded VB.net app. Seems to work fine - full support for debugging multiple threads with switching, freezing, and thawing so you can see what is happening.
Best Regards,
Mark Lauser
November 13, 2009 at 12:45 pm
I started writing code using VB.NET and then switched to C# several years ago. I switched because I was becoming a better programmer and was exposed to larger and more complex projects. These types of projects generally use C# instead of VB.NET. This may be because the "old timers" who had enough experience to build large & complex applications were coming from the C++ camp, there was more street cred in C# projects, or whatever.
Last year I took on a project with fairly complex architectural requirements, but it had to be done in VB.NET (because the government agency we were working for required it). I was therefore switching between two projects...one of them in C# (using the ASP.MVC framework) and the other in VB.NET (standard ASP). I definitely noticed the difference between the two and I find C# to be a better development language. Not because of personal preference to that syntax (although once you get used to C#, VB.NET seems very verbose) but because of little differences that required that I change not only the way the system was coded, but the way the system was designed.
For example, in C# I like to use LinqToSql for data access, but like to have each object in the data model implement a number of interfaces so I can properly implement abstraction, policy injection, and other recommended practices to support good software design. Only problem is...VB can't do it. The way interfaces are implemented in VB.NET didn't allow me to abstract the data layer through interfaces, so I had to totally re-design the way I built the system. The resulting code works, but is inferior to the C# counterpart.
Also, I found a difference in how C# and VB handle the IEnumerable<> interface. In C#, when an object is called using IEnumerable<> the runtime attempts to run it as IQueryable<>. The difference between these interfaces is that IQueryable<> interface builds an expression to go get the data you need but doesn't execute the call to the database until you actually iterate the data (or call the .ToList() method or similar). I chained together multiple Linq calls So I build one system in C# using IEnuemerable<> and it worked great and tried to replicate on VB. The problem is that VB executed the SQL commands for each call and was not performance optimized. Therefore, when load testing we hit serious performance issues and had to rework all the code to implement IQueryable<> interfaces...but then it threw a bunch of runtime errors if not properly typed, etc, etc.
There are other similar differences that I have come across that aren't related to LinqToSql, but I can't recall all the details right now.
I believe these differences may come from the respective development teams at Microsoft. As I understand it, most of their framework features are built around C# and then adapted to VB, and many of their user interface features come from VB and are adapted to C#. Seems like as they port framework features to VB, some of the details are lost in the translation. So I guess if you can stick to one language you would never know the difference, but working with the two side-by-side I have found C# to be better implemented.
That said, I have found VB to be a better interface for event driven coding. I find it very easy to attach events to objects in VB, while I always have to look up the syntax to do the same in C#. I am now mostly doing middle tier and backend stuff so it doesn't come up as often, but it if you're building event driven windows forms, then I think VB is better.
As far as Visual Studio goes, I think VB.NET has a lot of code completion features that help new coders. VB tries to anticipate what you want to type and generally does a good job...but can seriously mess up your code when you are refactoring. This is really helpful for new developers, but can get in the way once you know what you're doing. I prefer to manage my own code without the interface "moving it" on me, which can affect the functionality. VB has introduced several hard-to-track-down bugs during refactoring by guessing what I want.
As far as the bracket and semicolon discussion is concerned, the semicolon is a discrete end to the command. I don't like having to put "_" at the end of every line like I have to in VB. This comes up a lot when writing LINQ expressions. I prefer to just continue the expression to the next line and then add the semicolon at the end.
Anyway, I mostly wanted to point out that while VB.NET and C# seem to operate the same (and generally do) that when you're coding with both "side-by-side" there are definite differences between the two and I've found that more often than not C# works more like you'd expect it to. The rest of the differences really only have to do with coding syntax, and that of course is just personal preference.
November 13, 2009 at 12:46 pm
Using both "Option Explicit" and "Option Strict" together does prevent type shifting issues. Or using "Option Explicit" and "Dim As" on every declaration will eliminate type shifting issues.
However setting "Option Explicit" and "Option Strict" in the project's properties is the only way to make sure it isn't missed in a file or Dim. Unfortunately "Option Strict" is not on by default for VB.NET projects. And I've come across very few projects which have both set.
November 13, 2009 at 12:48 pm
You're correct, setting "Option Strict" and "Option Explicit" in the project properties will make VB.NET strongly typed. However that is not the default setting and I've found very few VB.NET projects which have both set in the properties.
November 13, 2009 at 12:49 pm
GSquared (11/13/2009)
scole-1025617 (11/13/2009)
acarlson-861483 (11/13/2009)
GOOD FOR YOU! I sincerely expect that your work SHOULD have improved over 5 years. As you develop in C# you will continue to improve with that as well. Patterns and practices may also change and be invented that will make what we all do now look like a hack.I attribute sample code in books as being highly influential to how well a person writes code as a beginner. I also see a trend to teach patterns, practice and principles along with syntax these days. I suspect we will see better "new" programmers because of it.
C# does NOT force you to write "good code". You can ignore things like encapsulation, separation of concerns, programming to an interface, etc just as easily in C# as VB.Net. I have been the guy to fix lots of poorly written "legacy" C#...
Wow...touchy. You must be a VB person. It's amazing how the VB ppl get so sensitive over a personal opinion. It's also amazing how you only pick this paragraph out and glaze over my disclaimers. It's like Coke vs Pepsi...I like Coke because it tastes better and IS better. Uh oh...an opinion!
And I like rootbeer! So VB and C# both suxor! Hahahaha!!!1one LOL!!!!!111!! I win, u lus!
All seriousness aside, I'm assuming you didn't read the part where he stated that he's had to fix a lot of C# code that was poorly written.
I used to have a sig that was a quote. Went something like, "There does not now exist, nor will there ever, any programming language that makes it the slightest bit difficult to write bad code." No language makes a coder skilled. Study, practice and experience do that.
I actually meant that in all sincerity but looking back at my all caps... sorry about that.
Actually, I am a C# developer. As GSquared pointed out, I have inherited some pretty bad C# code and really wish the language did promote some better construction. However, I've learned as much or more from bad code as good. Like Edison said, (paraphrased) "We now know 99 ways the light bulb does NOT work." I like to advocate code reuse also, but sometimes you simply DO need to throw out the old and write it new. (although I strongly argue against doing that if you can. Even in-elegant code that works is better than the time and opportunity cost of developing it from scratch.)
I do however stand by my statement that regardless of language and tools, that we should be getting significantly better at what we do over a 5 year span, especially as tools and methodologies evolve. Look at how c# itself has evolved from 1.0 to 4.0! I personally am excited by the new ways of doing things I get exposed to simply by it being included, highlighted or made easier in new versions of the language.
So to get back on topic, I would encourage some fluency in both languages. Sometimes trying to grasp new concepts such as lambdas, generics, functional language statements and so forth, might be more easily expressed in one language than another and thus easier to understand. Consider the 'for' loop.
For programmers with no previous experience of a C-like language, VB.NET code will, in most cases, be easier to understand than the C# equivalent. You could read this VB.NET version aloud and understand what it does:
For i As Integer = 0 To 7
TabControl1.TabPages(i).Text = "Tab: " + i.ToString()
Next i
The same cannot be said of its C# equivalent:
for(int i = 0;i < 8; i++){
tabControl1.TabPages.Text = "Tab: " + i;
}
However, digging into exactly what each of the parameters of the C# sharp version may be more helpful in understanding type conversion handling.
November 13, 2009 at 12:59 pm
Charles Kincaid (11/13/2009)
Jeff Moden (11/12/2009)
Heh... I have an odd personal preference... I don't like languages that require semi-colons or line continuation characters. It seems that they should all be smarter than that. 😉Poor Jeff. :crying: You are going to hate SQL then. Semicolons are going to be required in SQL server soon. :w00t:
Really? SQL Server (T-SQL, really) will require semicolons? How interesting. When will that happen? How about all of the bazillion lines of SQL code currently in SP's, triggers and what not, that doesn't have semicolons?
Kindest Regards, Rod Connect with me on LinkedIn.
November 13, 2009 at 1:06 pm
dsneed (11/13/2009)
I started writing code using VB.NET and then switched to C# several years ago. I switched because I was becoming a better programmer and was exposed to larger and more complex projects. These types of projects generally use C# instead of VB.NET. This may be because the "old timers" who had enough experience to build large & complex applications were coming from the C++ camp, there was more street cred in C# projects, or whatever.Last year I took on a project with fairly complex architectural requirements, but it had to be done in VB.NET (because the government agency we were working for required it). I was therefore switching between two projects...one of them in C# (using the ASP.MVC framework) and the other in VB.NET (standard ASP). I definitely noticed the difference between the two and I find C# to be a better development language. Not because of personal preference to that syntax (although once you get used to C#, VB.NET seems very verbose) but because of little differences that required that I change not only the way the system was coded, but the way the system was designed.
For example, in C# I like to use LinqToSql for data access, but like to have each object in the data model implement a number of interfaces so I can properly implement abstraction, policy injection, and other recommended practices to support good software design. Only problem is...VB can't do it. The way interfaces are implemented in VB.NET didn't allow me to abstract the data layer through interfaces, so I had to totally re-design the way I built the system. The resulting code works, but is inferior to the C# counterpart.
Also, I found a difference in how C# and VB handle the IEnumerable<> interface. In C#, when an object is called using IEnumerable<> the runtime attempts to run it as IQueryable<>. The difference between these interfaces is that IQueryable<> interface builds an expression to go get the data you need but doesn't execute the call to the database until you actually iterate the data (or call the .ToList() method or similar). I chained together multiple Linq calls So I build one system in C# using IEnuemerable<> and it worked great and tried to replicate on VB. The problem is that VB executed the SQL commands for each call and was not performance optimized. Therefore, when load testing we hit serious performance issues and had to rework all the code to implement IQueryable<> interfaces...but then it threw a bunch of runtime errors if not properly typed, etc, etc.
There are other similar differences that I have come across that aren't related to LinqToSql, but I can't recall all the details right now.
I believe these differences may come from the respective development teams at Microsoft. As I understand it, most of their framework features are built around C# and then adapted to VB, and many of their user interface features come from VB and are adapted to C#. Seems like as they port framework features to VB, some of the details are lost in the translation. So I guess if you can stick to one language you would never know the difference, but working with the two side-by-side I have found C# to be better implemented.
That said, I have found VB to be a better interface for event driven coding. I find it very easy to attach events to objects in VB, while I always have to look up the syntax to do the same in C#. I am now mostly doing middle tier and backend stuff so it doesn't come up as often, but it if you're building event driven windows forms, then I think VB is better.
As far as Visual Studio goes, I think VB.NET has a lot of code completion features that help new coders. VB tries to anticipate what you want to type and generally does a good job...but can seriously mess up your code when you are refactoring. This is really helpful for new developers, but can get in the way once you know what you're doing. I prefer to manage my own code without the interface "moving it" on me, which can affect the functionality. VB has introduced several hard-to-track-down bugs during refactoring by guessing what I want.
As far as the bracket and semicolon discussion is concerned, the semicolon is a discrete end to the command. I don't like having to put "_" at the end of every line like I have to in VB. This comes up a lot when writing LINQ expressions. I prefer to just continue the expression to the next line and then add the semicolon at the end.
Anyway, I mostly wanted to point out that while VB.NET and C# seem to operate the same (and generally do) that when you're coding with both "side-by-side" there are definite differences between the two and I've found that more often than not C# works more like you'd expect it to. The rest of the differences really only have to do with coding syntax, and that of course is just personal preference.
I would like to say that I normally don't want to bother reading a long post, especially not in a topic like this where everything is so opinionated.
But I would like to say that I am very impressed with your comments. Your experiences are exactly what this thread needed. I think I have ran into the same issues. Usually for a project I am able to pick a language and stay with that. Its good to see so many examples of comparisons between the two.
Good job.
November 13, 2009 at 1:14 pm
dean.rother (11/13/2009)
1. I should have use marked the code as code.2. I copied both samples from http://www.asp.net. I assumed MS could code to their own standards and the c# seemed a fair representation to me so why not the vb?
3. If I do come across non-standard code, I, personally would rather it be c#
4. Speaking of fair comparisons, why did you remove all the white space from the c# code sample? (I could have let this go otherwise.)
....
I removed all the whitespace from the C# because that's what was done to the VB. Made it completely unreadable, in both cases.
Comparing the readability of the two samples you originally posted is like comparing the flavor of Coke vs Pepsi, when one of them has had rotten eggs mixed into it. Not really a fair comparison. All I did was reverse which one had the rotten eggs in it, to make a point.
Assuming that Microsoft will follow their own published standards is a stretch. Just look at what they do to table and column names in the databases behind SharePoint, for an example of really, really bad design practices!
I totally understand that you prefer C#. Lots of people do. Personally, I haven't used either one enough to have an opinion. HOWEVER, my point is, don't try to make your point by setting up the contest unfairly. If you're going to compare readability, lay them both out in the best way, or lay them both out in the worst way, but don't load the dice. Makes you look like a politician, not an engineer.
Of course, the primary concern with "readability" isn't going to be layout. It's going to be the knowledge of the person doing the reading.
I could say that I prefer the "readability" of Greek:
Ge?? s??, t? ???µ? µ?? e??a? GSquared.
But if you don't read Greek (I don't, though I used to read Classical Greek), then it's probably better to put it in English:
Hello, my name is GSquared.
No amount of layout, typsetting, or picking the right font and background, is going to make the first one readable to someone who doesn't read Greek, or the second one readable to someone who doesn't read English.
So, readability of the language isn't, in my opinion, a valid test of worth. Either can be read by someone familiar with it. Neither can be read by someone unfamiliar with it (though VB comes closer on that point, but it still doesn't get there). Layout, typesetting, and font, make it easier or harder for either, even to those familiar with it. Same as any written language. (Or spoken for that matter. Ever encounter someone with a heavy Indian accent trying to talk to someone with a heavy Scottish accent? I have, and it's pretty amazing how bad the "readability" gets, even though both are ostensibly speaking English!)
Basically, I don't buy the "readability" argument making a difference in whether one language or the other is "better".
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 13, 2009 at 1:15 pm
peter-757102 (11/13/2009)
There will be a distinction in software that needs more power and has to go multi-threaded or at least be aware of it and thus require subsequently more programmer control, and the single thread coding we are all used to from today/yesterday. There really is no magic middle ground that isn't been used or in use today already. From this angle I rather see people actually learn how things work and become good at programming (controlling things) then learn to accept blind faith that the magic platform will solve it all.
Both C# and VB support multi-threaded applications just fine. I'm not sure I follow you.
peter-757102 (11/13/2009)
The question of which GC language without time precise destructors is better is therefore utterly irrelevant.
I'm not a huge fan of GC either. And the notion that you don't have to worry about memory management with a GC language is flat out false. You still have to remember to "derefenence" all objects - which isn't always as easy as it sounds.
November 13, 2009 at 1:18 pm
Rod at work (11/13/2009)
Charles Kincaid (11/13/2009)
Jeff Moden (11/12/2009)
Heh... I have an odd personal preference... I don't like languages that require semi-colons or line continuation characters. It seems that they should all be smarter than that. 😉Poor Jeff. :crying: You are going to hate SQL then. Semicolons are going to be required in SQL server soon. :w00t:
Really? SQL Server (T-SQL, really) will require semicolons? How interesting. When will that happen? How about all of the bazillion lines of SQL code currently in SP's, triggers and what not, that doesn't have semicolons?
Microsoft has it on their "Will be required in a future version", but doesn't have a date on it yet.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 13, 2009 at 1:24 pm
We were VB windows and changed to C# Web.. Mostly for us our industry is dieing so it is for marketing ourself.
But I think VB was an easier program to read and write. And C# seems to give freaky errors when the code is created correctly, that point you to nothing, and only go away if you rewrite it exactly as the code it didn't like.. VB wasn't tempermental like that and the error messages seemed more straight forward...
I think for the Web, web designers migrate to C# because it is closer to the java & C++ than other VB.. There certainly seems to be more job openings for this then VB windows. Or VB web.
November 13, 2009 at 1:36 pm
"Better" is not a useful concept in this context. If you know VB well and are unfamiliar with C#, you will tend to favor VB and vice versa. However, if you know both VB and C#, which is no great stretch, you may easily use either one, particularly if the client or your employer has a preference.
Viewing 15 posts - 121 through 135 (of 176 total)
You must be logged in to reply to this topic. Login to reply