|
In first example, an extra local is generated for the VB.NET function. I think that is there because of the alternate return value syntax (vb legacy).
i.e. instead of using return <expression>, one can use <function name>=<expression> as alternate syntax. However unlike return statement that exits the function, the alternate statement simply assigns the return value to its placeholder. This value will be picked up as a return value whenever there are no explicite return paths (using return statement).
Now, as far as language comparison goes, I think its a subjective judgment. As far as I am concerned, I am a vb guy and IMO c# sucks simply because of case sensitivity. Frankly speaking, I don't see any reason why any morden language should be case sensitive unless for legacy reasons (which exactly is the case for c# - its case sensetive not because its a good thing (rather its a bad thing, do human mind really care about case while naming entities? Is sam differen from Sam?) but because it makes migration from java, c, c++ simpler.
|
|
|
|
|
Few more things...
1) In VB.NEt, developers have to make sure to set Option Explicit and Option Strict whi;e C# is case senstive anyways and you can't use a var before declaring and initializing it.
2) Case Statements in VB.NEt suxz!! In C#, developers have tp use "break;" which is a good thing. Also "goto", "jumps", "goto case" are other valid options.
3) In VB.Net u've to use newline continuation character & _ which is really annoying, in C#, no need to use anything.
4) VB.NET array is a descendant of the System.Array of the .NET Runtime which by definition has a fixed size on creation. The ReDim Preserve statement creates a new array - and the elements of the old array get copied into the new one. As this happens under VB.NET, it becomes performance killer.
5) C# uses PInvokewhich allows you to call functions and have data types be marshaled correctly which is much better than VB.NEt's "Declare <api>" to call Windows API.
6) C#.Net permits you to write unmanaged code.
7) In C#, you can declare an object as "volatile" so it can be modified asynchronously.
8) VB.Net allows for a lot of implicit casting while C# requires casts to be explicit (Thank God!!)
9) When computing for checksum or hash on a class, the behavior of C# of not checking arithmatic overflow is reaaly helpful and then it provides "checked" and "unchecked" keywords.
MY FAV ONE
10) C#.Net is ECMA standardized and believe it or not, this is a HUGE difference to consider.VB.Net is still not standardized (and probably will never be ) so it lacks the cross-platform & vendor-support possibilities that a language like C++, C#, SQL92 offers. Therefore, C# IS a better choice over VB.Net
Hmmmmmmm, I think this much is good enough for now.
Cheers,
Neel
|
|
|
|
|
Misty_Blue wrote:
"In VB.NEt, developers have to make sure to set Option Explicit and Option Strict whi;e C# is case senstive anyways and you can't use a var before declaring and initializing it."
First of all, I think it's fantastic that a single language can be used as both a loosely typed and strongly typed language, and that it can be controlled at the file level. Furthemore, I also believe it's powerful that a single language gives you the ability to declare or not declare your variables before using them, and that it can be controlled at the file level. All the more power to the developer. I myself have no use for these features, except when I have to interact heavily with COM, in which cases late binding is sometimes useful, however, that doesn't mean someone else doesn't have a need for them. The options are there for the programmer to decide when and how to use them, if ever, and to me that's powerful . Finally, I don't see what case sensitivity has to do with either feature.
Misty_Blue wrote:
"2) Case Statements in VB.NEt suxz!! In C#, developers have tp use "break;" which is a good thing. Also "goto", "jumps", "goto case" are other valid options."
Are you kidding me? The VB Select Case statement is much more powerful than C#'s switch! You can specify a list of values, a range of values, or even both, or you can test using relational operators, etc... How do you do this in C#:
Case 1 To 4, 7 To 9, 11, 13, Is > MaxNumber
Well, you can't! At the most you can do something like:
case 9:
case 11:
case 13:
Or you have to "goto" the block of another case label. Sucks! In the end for complex relational operations you have to use the if statement, although there's nothing wrong with that, but to say that C#'s switch is more powerful is completely false. I do think it's cool that you can jump from one case block to another, but I think it sucks that you have to explicitly break out of one. I know there's no such thing as fallthrough as in C++ but couldn't this have been done without forcing an explicit break ?
Misty_Blue wrote:
"3) In VB.Net u've to use newline continuation character & _ which is really annoying, in C#, no need to use anything."
Oh please ! First of all, line continuation is acheived with just the underscore and not the ampersand. Second, I would rather have to use the line continuation character on the few occassions that a code line is too long for a single line rather than have to type in a semicolon for every single line of code I write .
Misty_Blue wrote:
"4) VB.NET array is a descendant of the System.Array of the .NET Runtime which by definition has a fixed size on creation. The ReDim Preserve statement creates a new array - and the elements of the old array get copied into the new one. As this happens under VB.NET, it becomes performance killer."
First of all C#'s array also derives from System.Array, so they're one in the same with VB's. Second, ReDim Preserve is just a VB specific way of calling Array.CopyTo, which is what you would do if you want to increase the size of an array yet keep its current values, in the end you still have to create another one. Regardless of how you do it, yes I know it's a performance killer.
Misty_Blue wrote:
"5) C# uses PInvokewhich allows you to call functions and have data types be marshaled correctly which is much better than VB.NEt's "Declare " to call Windows API."
So does VB! Sure you have the option to use Declare, in addition to DLLImport, but in the end all Declare statements are replaced with DLLImport. Once again, it's all about options .
Misty_Blue wrote:
"6) C#.Net permits you to write unmanaged code."
So :-> Besides, I already told you that C#'s pointer is a poor excuse of one, and that if for some bizarre reason you need to use pointers, then you should be coding in C++. I also told you to give me a specific example of doing something with C# pointers that I cannot do in VB by using the System.Runtime.InteropServices.Marshal class.
Misty_Blue wrote:
"7) In C#, you can declare an object as "volatile" so it can be modified asynchronously."
what can I say other than I will do my locking explicitly.
Misty_Blue wrote:
"8) VB.Net allows for a lot of implicit casting while C# requires casts to be explicit (Thank God!!)"
No doubt, but it ALSO can funtion in explicit mode as well (option strict on baby ) It's all about options!
Misty_Blue wrote:
"9) When computing for checksum or hash on a class, the behavior of C# of not checking arithmatic overflow is reaaly helpful and then it provides "checked" and "unchecked" keywords."
VB also allows you to disable overflow. No we don't have checked and unchecked, but I don't care .
Misty_Blue wrote:
"10) C#.Net is ECMA standardized and believe it or not, this is a HUGE difference to consider.VB.Net is still not standardized (and probably will never be :sigh so it lacks the cross-platform & vendor-support possibilities that a language like C++, C#, SQL92 offers. Therefore, C# IS a better choice over VB.Net"
True, perhaps it's not standardized but it's making its weight felt. Ever heard of MonoBASIC?
Are you still standing ?
Take care dude!
|
|
|
|
|
Of course I'm still standing!! r ya kiddin me??
It all boiling down to "OPINIONS" just as i predicted. I mean u'r saying tht "that a single language can be used as both a loosely typed and strongly typed language" which is so funny!!
It's like VB.Net allows you to do all the mistakes in the world. However, if youw ant, you can stop doing those mistakes. It's extremely stupid!! loolz
All those things you replied to are in the same fashion. Ultimately i'm just hoping that people would get my point that it is bogus to say one language is better than other when we're talking about C# and VB.Net and i wish that unlike some people who trash VB.NEt, you should stop trashing C#.Net 'cuz it's really pointless. Anyways, good luck =
Neel.
|
|
|
|
|
Sorry man but very weak counter, come on dude, you can do better, after all you started this and all the other threads . I didn't drag you into anyone of them.
Misty_Blue:
"i wish that unlike some people who trash VB.NEt, you should stop trashing C#.Net 'cuz it's really pointless"
Dude I don't understand why you like to tag on the ".NET" to C#. I myself can't stand the fact that VB.NET wasn't just simply called VB7 .
Well, I give up, you win! You may still be standing, but you've tired the hell out of me .
later
|
|
|
|
|
Hehehehe well, i wasn't discussing to "win". Besides, It's not even that i "hate" VB.net (or VB7 ) I just wanted to give the real answer that there is no such thing as "best/better language" in .net (i mean at least if we are comparing c#.net and vb.net)
and no i'm not tired of you. It was indeed interesting to brush up my knowledge of VB.Net (/VB7 )
Keep up your good work and keep posting articles.
Cheers,
Neel.
|
|
|
|
|
Coming at this from someone who uses both languages, and has used VB since 1.0...
Giancarlo Aguilera wrote:
First of all, I think it's fantastic that a single language can be used as both a loosely typed and strongly typed language, and that it can be controlled at the file level. Furthemore, I also believe it's powerful that a single language gives you the ability to declare or not declare your variables before using them, and that it can be controlled at the file level.
Actually, I see this as one of VB's greatest weaknesses, and a reason why it isn't being taken seriously by many non-VB developers. When discussing a function or subroutine out of context, or at a formalized code review, you can't see how these options are declared at a file level, and so information that you need to know if the implementation is correct or not isn't there.
Option Explicit should not be supported in VB.NET. It was a mistake in VB 6, and it was a mistake in all previous versions, but in VB.NET (in particular) it should have been dropped outright.
Late binding is the only marginally acceptable use, and Microsoft could easily introduce a keyword or operator to support late binding.
The issue with Option Explicit off is it causes numerous hard to track bugs in an application of any moderate complexity, and it makes it impossible to deal with a function out of context (at a peer review, etc.).
Sub DoSomething()
Offset = 0
Do While Not Done
Offset = Offset + 1
Done = True
End While
End Sub
Is Offset class local? Is it sub local? Is it global (in VB6-)?
Does the line incrementing it set it to 1, or 01? If the loop ran multiple times, would it increment normally or would it end up being 01111111111?
You can't tell any of this from looking at the sub in isolation, and that is a barrier to communicating with other developers. It is also a barrier to effectively catching problems before code ships, which is traditionally what earned VB it's low reputation among other programmers.
Giancarlo Aguilera wrote:
Are you kidding me? The VB Select Case statement is much more powerful than C#'s switch! You can specify a list of values, a range of values, or even both, or you can test using relational operators, etc... How do you do this in C#:
The C# approach lends itself well to things like interpreters, while the VB approach lends itself to certain varieties of data validation. Generally speaking, break is one of the statements in C++ and C# that causes the most odd, untrackable bugs (because people forget to use it a lot).
Both approaches have merits in different situations. Personally, I dislike break and think it should be removed from the C# language as well. Break doesn't get you anything a function wouldn't, and the function makes your intent crystal clear.
But then I think C# and VB.NET both should get inner functions and inner subs in order to promote clear, readable code -- so what do I know...
Giancarlo Aguilera wrote:
Oh please ! First of all, line continuation is acheived with just the underscore and not the ampersand. Second, I would rather have to use the line continuation character on the few occassions that a code line is too long for a single line rather than have to type in a semicolon for every single line of code I write .
VB needs an equivalent of /* ... */ comments, which is where this complaint usually originates:
void Func(
int param1, // This parameter is for (blah)
int param2 // This paramerter is for (blah)
) {..}
In VB.NET, you can't do anything equivalent:
Sub Func( _
param1 As Integer, _ 'This won't compile with a comment here
param2 As Integer _ 'This won't compile with a comment here
)
If you look at were continuations are useful, it's almost always a sub/function declaration or an expression. If you allowed ( to auto continue until there was a matching ), without continuation characters, you could also address both complaints. But that won't happen anytime soon.
Giancarlo Aguilera wrote:
First of all C#'s array also derives from System.Array, so they're one in the same with VB's. Second, ReDim Preserve is just a VB specific way of calling Array.CopyTo, which is what you would do if you want to increase the size of an array yet keep its current values, in the end you still have to create another one. Regardless of how you do it, yes I know it's a performance killer.
If you're talking like a game loop doing pixel manipulation or the like, in a C# unsafe block, it's possible to use a native array. It still doesn't perform as well as the equivalent C++ code, and it requires the full trust profile (which can be annoying) since it uses unsafe, but it can be done.
Giancarlo Aguilera wrote:
5) C# uses PInvokewhich allows you to call functions and have data types be marshaled correctly which is much better than VB.NEt's "Declare " to call Windows API."
So does VB! Sure you have the option to use Declare, in addition to DLLImport, but in the end all Declare statements are replaced with DLLImport. Once again, it's all about options .
Declare should generate a deprecated warning, in fact (it doesn't, but it should), because it's actually intended to be an aid in porting old code, versus something for new use. You open any VB 6 code that does anything with Windows, and Declare is the first line you'll see. There had to be a migration path, but they should inform you its a migration path and steer you in the right direction.
Giancarlo Aguilera wrote:
"8) VB.Net allows for a lot of implicit casting while C# requires casts to be explicit (Thank God!!)"
No doubt, but it ALSO can funtion in explicit mode as well (option strict on baby ) It's all about options!
Option Strict is another one that should be locked on. Most programming shops I've worked at the last 10 years have required it to be on for all code. It's another one that was originally intended to ease migration from GW/Q BASIC that has served its purpose and should be out of there.
To support late binding, there should be a specific language pseudo-type or a modifier for System.Object:
Dim A As LateBound System.Object
Giancarlo Aguilera wrote:
Misty_Blue wrote:
"9) When computing for checksum or hash on a class, the behavior of C# of not checking arithmatic overflow is reaaly helpful and then it provides "checked" and "unchecked" keywords."
VB also allows you to disable overflow. No we don't have checked and unchecked, but I don't care
Checked and unchecked are necessary, in rare cases, for performance.
In the case of the stated applications, though, I would typically use the C++ implementation of checksums or hashes in System.Security.Cryptography; even with unchecked, running in an unsafe block, you're unlikely to beat the implementations there for performance.
Microsoft omitted anything from VB.NET that is intended for use by low-level processes, where performance is typically critical. In C#, they put these capabilities in; in C++, they were standard. Any time you get into a feature that would benefit from low-level support, C# is a better fit than VB.NET. It's not that you can't manipulate an array in VB.NET, for example. It's that you can't do it as fast as in C# can in an unsafe block.
In general, option explicit off and option strict off will cripple performance. It's not that the process won't run, or won't compile. It's that every 2nd or 3rd line of code is boxing/unboxing. With implicit conversions, you have overhead at every assign, above and beyond box/unbox.
Generally speaking, my opinion is that Microsoft should have said "sorry, not supported anymore." Most apps require significant work to port anyway, so backwards compatibility didn't need to be a concern.
|
|
|
|
|
I agree with most of what you said, only when I put my programmers hat on. However, for people that are not programmers that need to program, the hacking VB provides is great for them.
When you get a chance please read my latest article: http://www.codeproject.com/useritems/vbdefamation.asp[^]
good luck
|
|
|
|
|
It's all about options? This line of thinking seems to imply that a language should not "force" the developer to anything in particular, but only provide such things as type checking as an option. In my opinion, based on my experience, this is the best solution only in a completely academical and hopelessly unrealistic world. Can you give me a practical example of a situation in which weak typing is a real advantage?
I can see how *inferring* types can save some code with no loss of strictness, but I seriously do not understand how it can be disadvantegous to declare what type a variable is. It is true that we will sometimes get little benefit from strong typing, such as when we declare variables of type "object", but at the very least it forces the programmer to explicitly choose.
So, to me, the argument that "VB can do it" only scores half a point. Yes, it can do it, and that is a good thing, but it does not guarantee it, and that is a bad thing.
As for the volatile modifier, your response "what can I say" really does say it all and you'd have looked more honest if you had just plainly admitted there is no corresponding feature in VB.NET.
I'd agree that the VB.NET case statement is more powerful than C#'s, and I think it is weird that you haven't mentioned optional parameters. They can be of great benefit at times, particularly if you're coding against something like MS Office, where the APIs were designed for VBA and assume the caller can provide just the arguments he is interested in. Methods have up to 30 arguments, and it does little for the readability in C# to pass 29 default values and somewhere in there the one you're actually interested in using.
That said, I don't do much office interop and for me the choice is easy. With C# I only have to write half as much code as in VB, and this without the slighest drop in information. For the same reason I find it much easier to read. Finally, I must admit that I just cannot help myself for hating how VB tries to "improve" on long-established oop terminology with its "MustInherit Friend" classes and the like. For me, even though I understand intellectually that it is a perfectly usable language, it still feels like a baby's toy.
Lastly, you claim that VB is clearly superior to C#, while somewhat contradictory providing evidence that simple functions may require a 100% increase in memory consumption for a simple non-void method returning a value, and a 50% increase in stack size and a reduction in performance when doing string comparison (not exactly exotic, I might add). Yet you do not provide any clues as to what exactly it is that makes VB superior in your opinion.
Unless working with office interop, I see no compelling reason to choose VB, and if named parameters are added to C# as well I'm unaware of any area in which VB might be considered superior.
And nobody's even mentioned anything about the C#2.0 and 3.0 features. I haven't paid enough attention to know if VB has added anything similar... please enlighten me (us?)
|
|
|
|
|
Sorry man volatile != automatic locking. It is an optimization technique used on fields that are typically locked, and goes all the way down to basic CPU constructs.
C# programmers will spend more time making something (but spend less time making it fast). VB developers spend more time making something fast (but less time making it).
Niether is better. Pick your poison and shut up.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
By looking at all the comments about Vb vs C#, I can see lots of the fellwos are talking about OO.
But I have a question, do you really utilize the OO models? In this world, we are still using RDBM like SQL Server as the backend, and still manipulating recordset in mid-tier, and still using table styled data grid or data grid like front end tabular stuff. And all the reports are still tabular based (most of them). XML is not a solution for OO, it's just a serializable class formatter.
But here lots of folks are talking about OO design and implementation. I have seen really good OO design (costs the company tons of money to set the architecture). And see 99% of the company I have worked with are all OO claimed and has nothing to do with OO at all. All them implements are just inheretence and some interface design. They still use a controller based code to do real transaction or enquiry. That's not OO at all.
So please don't put OO as a word in your mouse all the time. Until a real OO database is matured in the market place, then lets talk about real OO.
Your comments,
Ian
|
|
|
|
|
What about apps that don't use a database? And I though inheritance was part of OOP?
Regards
Senthil
My Blog
|
|
|
|
|
Ian Ying Xiao wrote:
"But I have a question, do you really utilize the OO models?"
Are you asking me whether the software I develop is the result of proper OO analysis and design? If so, well my answer is not all of it, it depends on the context I find myself in, with the most influential factors being time and resources. If there's enough time and resources to do things right, then I'd be a fool not to. Otherwise, delivery always takes priority even if it means sacrificing what you call the "OO Style".
Ian Ying Xiao wrote:
"In this world, we are still using RDBM like SQL Server as the backend, and still manipulating recordset in mid-tier, and still using table styled data grid or data grid like front end tabular stuff. And all the reports are still tabular based (most of them)."
And your point is? Are you saying that using a relational database inhibits OO? If so, please look into ORM. By the way, that dataset you're using in the middle tier is a beatiful abstraction of a database.
Ian Ying Xiao wrote:
"XML is not a solution for OO"
I assume you meant to say that XML is not an ideal way of storing objects. I think that depends on the type of object. Regardless, I think you place way too much emphasis on how objects are stored rather than on the objects themselves.
Ian Ying Xiao wrote:
"So please don't put OO as a word in your mouse all the time."
Just to clear things up here, first, I don't know where you got the idea that everything I say is somehow related to OO. This article, for example, has nothing to do with OO. Second, the only reason OO has come up is because of the discussions I've had with other coders as seen in the threads. Finally third, I know you said please, but please don't tell me what I can and cannot say unless what I am saying is inaccurate, in which case I will make to shut up.
Ian Ying Xiao wrote:
"Until a real OO database is matured in the market place, then lets talk about real OO."
Please speak for yourself, you can wait all you want. I myself could care less how an object is stored as long as it's an object that I'm storing. An OO database perhaps is "ideal", and I know there are some stable ones out there right now, but until the prices go down, I'll do without them.
Thanks for your feedback, although I respectfully disagree with most of it.
|
|
|
|
|
Giancarlo, I agree with you in this matter.
|
|
|
|
|
You fail to make clear what you think it means to "code" OO style. In my opinion, it isn't a question of coding style but a question of design (and, usually, architechture).
What does object-orientation mean? Broadly speaking, it is an approach to programming that centers on the common everyday language concepts of "objects" and "classes", or uses this concepts as metaphores to help us think about a system. Certain concepts have come to be seen as the "core" concepts: Inheritance, encapsulation, polymorphism. But it is not automatically obvious how exactly these are to be used. They just help clarify the thinking by drawing analogies to the more familiar world. For example, ask yourself what a class member is. In my view, the best "oop" answer isn't anything to do with static linking or indeed anything very technical at all -- the best answer is that it is a member that pertains to the class as such, rather than to any particular instance.
Sometimes a class can be thought of as all the instances collectively, and the number of Car instances is indeed a good example of what would be a class member - how many instances there are is clearly not an attribute of any particular car. Other times, it may not make sense to speak of instances at all; the class may model something abstract, such as Mathematics. (Yes, the Math class is static, but a static class is also an abstract class.)
I think that most of use make much use of these metaphores, if in sub-optimal ways, and that the OOP paradigm is of great value overall. Inheritance and thinking of your model in terms of more and more specific classes facilitates reuse and polymorphism facilitates extensibility. There is nothing of this that you could not achieve using structured programming techniques, but it is much easier to think in terms of objects and classes in the same way that we subclass "Person" into "Man", "Woman" and so on in our daily lives. The reason the metaphor is so useful is just because it happens to promote good practices: By thinking about what is the common stuff that belongs to "Person" and putting in the base class I promote reuse, which in turn reduces bugs and increases maintainability, testability, and productivity.
That said, its not always good to use OOP and its not always obvious when a principle should be considered "fulfilled". Take encapsulation, for instance: A completely encapsulated type would have no public members at all, and hence it would be completely useless - there would be no way to interact with it, hence to use it.
A completely different set of problems emerge when developing servers, including web applications. Consider ASP.NET web pages, which live (exist) only during the processing of a web request. Once a response has been sent, all the objects are garbage collected, and the next time the page is posted back, even though it seems like its "the same text box" in some sense, another object instance is created and its state set up so that it is representative of the page as it was on the client when posted back. Exactly how this is achieved doesn't matter to the present subject, but it involves using a combination of the aspx page definition and postback data (including the hidden-input stored viewstate). My point here is just that in cases like this, it could make more sense to use stateless "objects" (they aren't really objects at all!), in this case logic that renders a textbox given its text value. Since the state anyway has to flow in and out of the object the encapsulation just leads to a potentially huge amount of instantiation/garbage collection overhead.
As it happens, the fact that servers generally need a fairly different design from desktop applications in order to be efficient is one of the main motivations behind SOA, service-oriented architecture. Just like OOP centers on the object metaphor, SOA makes use of another common metaphor, services, to help us think about software design in a way that promotes good and useful programming practices.
Finally, I do not agree that there is any fundamental problem with using relational databases and still call a system object oriented. The database is just a persistence medium, and if I persist an object in the form of rows in tables there is nothing wrong with that. It would be nice if either high-performance object databases emerged or really good O/R mapping tools came to our rescue so we didn't have to write all that mundane DAL code, but merely using a relational database to store information does not prevent a system from using OOP design principles.
|
|
|
|
|
1) u've a choice 2 write unsafe code with pointers in c# but not in vb.net
2) xml documentation is supported in c# and not in vb.net
3) C# supports operator overloading while VB.Net doesn't support it.
4) C#.Net is sytactically much cleaner than VB.Net, may be 'coz of the fact tht C#.Net is entirely new n specifically targeted for the .net framework.
5) C# is a bit faster then vb.net (this thing has been tested by many of the organizations by doing the benchmarks but MS didn't accepted till now (as far as i know). This might be because .NET framework itself is written in c# although the difference between speed isn't that noticeable so we can ignore this part.
Some Interesting articles:-
===========================
--> Top 10 reasons C# is better than VB.NET
http://www.vbrad.com/pf.asp?p=source/src_top_10_cs.htm[^]
--> Top 10 reasons VB.NET is better than C#
http://www.vbrad.com/pf.asp?p=source/src_top_10_vb.htm[^]
--> C# Conference Session
http://www.simonrobinson.com/DotNET/Discussions/WroxConfDec2002.aspx[^]
--> The .NET Language Paradigm
http://www.codeproject.com/dotnet/dnlp.asp#xx561639xx[^]
--> What are the advantages of C# over VB.NET and vice versa?
http://blogs.msdn.com/csharpfaq/archive/2004/03/11/87816.aspx[^]
--> Visual Basic.NET or C#...Which to Choose? [DOWNLOAD: PDF]
http://www.amazon.com/exec/obidos/tg/detail/-/B00005YX8N/102-5064032-6760145?v=glance[^]
Technically speaking, the language war is ABSURD!! I mean, wht matters is CLR and BCL!! If u know how 2 use the full power of .net platform, u can use either of those 2 languages efficiently. Both DO have minor differences and some pros n cons.
DO NOT fall for the author's comment tht VB.NEt is better than C# (Just 'coz he likes VB.Net). Thtz ABSURD N ARROGANT. I wudn't say C# is better than VB.Net 'cuz i like C#.Net The real answer is "depends" wht u wanna do with ur application. No hard feelings for the author of this article though n i appreciate his efforts. Have a gud 1
|
|
|
|
|
Misty_Blue wrote:
"u've a choice 2 write unsafe code with pointers in c# but not in vb.net"
very true, vb has never had nor ever will have that feature. furthermore, if you need to make use of pointers in .NET, then C++ is by far a superior tool.
Misty_Blue wrote:
"xml documentation is supported in c# and not in vb.net "
bogus, all of my vb.net apps use xml comments, just download a free add in.
Misty_Blue wrote:
"C# supports operator overloading while VB.Net doesn't support it."
true, at least until 2.0 arrives.
Misty_Blue wrote:
"C#.Net is sytactically much cleaner than VB.Net, may be 'coz of the fact tht C#.Net is entirely new n specically targeted for the .net framework. "
that's your personal preference, I could care less about syntax as long as the functionality is there.
Misty_Blue wrote:
"C# is a bit faster then vb.net (this thing has been tested by many of the organizations by doing the benchmarks but MS didn't accepted till now (as far as i know). This might be because .NET framework itself is written in c# although the difference between speed isn't that noticeable so we can ignore this part."
let's not ignore it, bogus!, that all depends on how you code in VB.
Misty_Blue wrote:
"Technically speaking, the language war is ABSURD!!"
I know it is, but it's fun .
Misty_Blue wrote:
"DO NOT fall for the author's comment tht VB.NEt is better than C#"
I think you're the only one that fell for it .
Misty_Blue wrote:
"No hard feelings for the author of this article though n i appreciate his efforts. Have a gud 1"
absolutely none taken, nor could I care less on the vote you gave me .
thanks for the feedback
|
|
|
|
|
Giancarlo Aguilera wrote:
"u've a choice 2 write unsafe code with pointers in c# but not in vb.net"
very true, vb has never had nor ever will have that feature. furthermore, if you need to make use of pointers in .NET, then C++ is by far a superior tool.
--> looooolz. I thought we were comparing VB.Net with C#.Net!! So where did C++ came frm?
------------------------------------------------------------------------------------------------
Giancarlo Aguilera wrote:
"xml documentation is supported in c# and not in vb.net "
bogus, all of my vb.net apps use xml comments, just download a free add in.
--> yes, it DOESN'T!! Like u said poor VB.Net has to look for some "add-ins"!!
------------------------------------------------------------------------------------------------
Giancarlo Aguilera wrote:
"C# is a bit faster then vb.net (this thing has been tested by many of the organizations by doing the benchmarks but MS didn't accepted till now (as far as i know). This might be because .NET framework itself is written in c# although the difference between speed isn't that noticeable so we can ignore this part."
let's not ignore it, bogus!, that all depends on how you code in VB.
--> EXACTLY!! it ALWAYS depends on how u code!! Like i said b4, the question itself is invalid 2 begin with!!
-------------------------------------------------------------------------------------------------
Giancarlo Aguilera wrote:
"Technically speaking, the language war is ABSURD!!"
I know it is, but it's fun .
--> And also, VERY time-consuming hehehehe....
-------------------------------------------------------------------------------------------------
Giancarlo Aguilera wrote:
"DO NOT fall for the author's comment tht VB.NEt is better than C#"
I think you're the only one that fell for it .
--> huuuuh?? u'r funny!! loooooooolz
-------------------------------------------------------------------------------------------------
Giancarlo Aguilera wrote:
"No hard feelings for the author of this article though n i appreciate his efforts. Have a gud 1"
absolutely none taken, nor could I care less on the vote you gave me .
--> Well, I haven't voted ur article yet n i'm not 1 of those persons who'll vote 1 just 'coz our opinions aren't matching. In general, authors REALLY have 2 work hard to get lower than 3 from me hehehehe (Reason: I appreciate tht they cud take sum time out 2 write article instead of being a lazy ass like me hehehehe). I know u don't care wht i'll vote but still, it won't be lower than 3 for sure and like i said, it's gud 2 share knowledge n opinions n tht i DO respect ur opinions as well
-------------------------------------------------------------------------------------------------
Gee, yer killin' my time!! hehehehe
Cheers,
Neel.
|
|
|
|
|
Misty_Blue wrote:
"I thought we were comparing VB.Net with C#.Net!! So where did C++ came frm"
We are, but I'm just letting you know that you should use C++ rather than C# when working with pointers. Besides, can you give me a specific example of a use of pointers in C# that cannot be done in VB via System.Runtime.InteropServices.Marshal? Regardless, C# does have a poor excuse of a pointer yet VB does not.
Misty_Blue wrote:
"yes, it DOESN'T!! Like u said poor VB.Net has to look for some "add-ins"!!"
I can't tell the difference when writing XML comments in VB or C#, so it doesn't bother me. Besides in 2.0 it will come straight out of the box .
Misty_Blue wrote:
"And also, VERY time-consuming hehehehe"
tell me about it, but hey man, you started the thread .
"i DO respect ur opinions as well "
Likewise, I respect your opinion as well, BUT I have ZERO respect for your language (C#) .
Well, I must say that this debate has been better than others because at least it seems you know something about VB. Others talk trash, but that's all, no words behind the talk. At least you were able to pick out a few insignicant features C# has that VB does not. Yet of course there's a flip side to that coin:
1) what's up with C#'s lack of declarative event handling that VB has via the withevents and handles keywords.
2) what's up with the name mapping C# requires when implementing interfaces, either explicitly or implicitly, why not follow the leader and use VB's declarative implements keyword? Reminds me of VB 6's name mapping interface implementation.
3) what's up with C#'s lack of some type of "when" keyword that allows you to add a conditional test to a catch block? (honestly, I just threw this one in there, I've never use, but on the same token I doubt you make extensive use of pointers in C# )
4) what's up with C# forcing you to declare an event's underlying delegate in addition to the event itself. Why can't it be done inline like VB .
5) what's up with C#'s weak "new" modifier? If you're given a means to hide for whatever odd reason what your base exposes, why limit it. VB's "shadows" is way more powerful. I just threw this one in there, I seldom use it.
6) what's up with C#'s lack of optional parameters? I know, I know, method groups (overloading) accomplish the same thing and in a cleaner fashion, but for heaven's sake COM is still around.
So there!, what you gotta say about that
Thanks for the feedback, and also, please no rush in a response, I know you've got other more important things to do than battle it out with me , too bad C#'s intellisense, at least until version 2.0 arrives, is pathetic and no better than VB 6's .
|
|
|
|
|
-----------------------------------------------------------------------------------------
Misy_Blue wrote:
i DO respect ur opinions as well "
Giancarlo Aguilera wrote:
Likewise, I respect your opinion as well, BUT I have ZERO respect for your language (C#) .
--> Well, i don't care how much respect u've for C#.Net
-----------------------------------------------------------------------------------------
Misty_Blue wrote:
"yes, it DOESN'T!! Like u said poor VB.Net has to look for some "add-ins"!!"
Giancarlo Aguilera wrote:
I can't tell the difference when writing XML comments in VB or C#, so it doesn't bother me. Besides in 2.0 it will come straight out of the box .
--> yeah well, we'r talkin abt language's power not some third-party add-ins. Besides you, yourself agreed in replying massimo's post tht even when .NEt 2.0 comes out, C#.net 2.0 will still have edge over vb.net, we can discuss tht 2 if u want
------------------------------------------------------------------------------------------
Giancarlo Aguilera wrote:
Well, I must say that this debate has been better than others because at least it seems you know something about VB. Others talk trash, but that's all, no words behind the talk. At least you were able to pick out a few insignicant features C# has that VB does not. Yet of course there's a flip side to that coin:
--> Well, obviously, unlike you, i don't have problem with any of those 2 languages. I just prefer C#.Net, thtz all and if there are people trashing VB.Net then you are doing the same thing with C#.Net so i don't think you should complain!! I mean, there's no point of trashing ne language whether it's C# or VB.NEt Anyways here's are some more things:
Giancarlo Aguilera wrote:
1) what's up with C#'s lack of declarative event handling that VB has via the withevents and handles keywords.
1) C# has a different way of even handling and so we can manually/automatically link, subscribe and publish events so it doesn't need tht withevents or handles keywords.
Giancarlo Aguilera wrote:
2) what's up with the name mapping C# requires when implementing interfaces, either explicitly or implicitly, why not follow the leader and use VB's declarative implements keyword? Reminds me of VB 6's name mapping interface implementation.
2) Well, the "leader" (says who??) was buggy so thank god C# is NOT following the "so called leader" looolz I mean why doesn't C# use "Implements" keyword is just way 2 funny
Giancarlo Aguilera wrote:
3) what's up with C#'s lack of some type of "when" keyword that allows you to add a conditional test to a catch block? (honestly, I just threw this one in there, I've never use, but on the same token I doubt you make extensive use of pointers in C# )
3) Well, exactly, i've never used it too but okay, it's there in VB.Net (no biggie though).
Giancarlo Aguilera wrote:
4) what's up with C# forcing you to declare an event's underlying delegate in addition to the event itself. Why can't it be done inline like VB
4) Well, obviously thtz y i don't like VB.NEt! It's more structured and more powerful and i know at least what i'm doing.
Giancarlo Aguilera wrote:
5) what's up with C#'s weak "new" modifier? If you're given a means to hide for whatever odd reason what your base exposes, why limit it. VB's "shadows" is way more powerful. I just threw this one in there, I seldom use it.
5) I don't agree tht shodows is more powerful tht "new" modfier but in any case, it's pointless since it's not a big deal neways.
Giancarlo Aguilera wrote:
6) what's up with C#'s lack of optional parameters? I know, I know, method groups (overloading) accomplish the same thing and in a cleaner fashion, but for heaven's sake COM is still around.
6) So???? :->
Giancarlo Aguilera wrote:
Thanks for the feedback, and also, please no rush in a response, I know you've got other more important things to do than battle it out with me , too bad C#'s intellisense, at least until version 2.0 arrives, is pathetic and no better than VB 6's .
Well, this is a healthy arguement n i liked it so far, Thx 4 ur feedback as well
Neel.
|
|
|
|
|
One of the main reasons .NET was developed was to provide a clean slate and end the continued evolution of the windows api; which has become ever more complex as windows itself has evolved.
C# is a new languages specifically designed for .NET, a clean slate. This argument that VB is superior because it doesn't force you to work in object orientation is IMHO absurd. Object orientation is and has been the future of software development (and a major part of what .NET is). Procedural programming is still a part of OOP and it is possible to code outside of the OOP paradigm using a language designed for it (although I really don't see an advantage).
In the end the reason to use another managed language over C# is to continue to use what your comfortable with. If you've been developing in VB, the transition to .NET is easier with VB.NET. If you extending a legacy application that was written in VB, extend it with VB.NET. If your extending a legacy application that was written in C++, use Managed C++.
If your writing new software, use VB if it suits you (or any other managed language for that matter), personally I don't care. Though if you want to be paid more, you might think about using c# (see latest salary reports).
-Paradox
|
|
|
|
|
paradoxdev wrote:
"This argument that VB is superior because it doesn't force you to work in object orientation is IMHO absurd."
Yes, and I do make perfectly clear to the reader that this is the case, as is the case when C# is argued to be a superior language and that VB programmers, including myself, are idiots.
paradoxdev wrote:
"Object orientation is and has been the future of software development (and a major part of what .NET is)."
No dispute there.
paradoxdev wrote:
"Procedural programming is still a part of OOP and it is possible to code outside of the OOP paradigm using a language designed for it (although I really don't see an advantage)."
Sure, in C# just create a type with some static fields and methods, include it into your source file, and off you go into the wild destined to get eaten alive when things get serious. But it's good that C# as a language can give itself the luxury to force the programmer to at the very least type the word "class" or right click->Add New Item->Add Class. Whether or not he or she knows what the heck it is that's another story.
paradoxdev wrote:
"Though if you want to be paid more, you might think about using c# (see latest salary reports)."
Here I have to disagree. If you want to get paid more, or at least try, then you must be fluint in both, the sacrifice for doing so being negligible thanks to the CLR and the BCL. If you just don't have the time or the option to mix but are sharp with the CLR and BCL, never discard a project that involves the other language and your type of work, rather just give it a shot and try to express your knowledge of the framework to the interviewer, assuming it's technical, and hope that knowledge hits solid and foreshadows the lack of syntax familiarity.
Thanks for the feedback.
|
|
|
|
|
I totally agree with your dismissal of the claimed "advantage" of VB's lack of strictness, and also your observation that structural programming is still a part of OOP - the toolset if not the mindset. But I want to comment on your failure to see any advantages to programming outside of the OOP paradigm.
The thing I have in mind is servers. The problem with OOP when applied to servers is that objects in the real world, and therefore in well-designed OOP apps, have state. An instance of a chair may have such state as the angle of inclination (reclination? and the direction in which it is facing, and methods such as Recline() and Rotate() to allow a user to modify this state. However, in the context of a server the consumer of such operations will generally not be known to connect again in the future, so you generally can't keep your objects around for future use. Thus, to do the equivalent of rotating the chair the consumer would have to first specify the chairs initial state as well as how to rotate it, and then obtain the result. And on the server, one would have to instantiate a new chair every time, set up the initial state, and then perform the operation and return the result.
In short, where a static method would have been more appropritate, using good OOP design can lead to a huge amount of instantiation/garbage collection overhead in a server.
This is one area in which ASP.NET controls could be dramatically improved. A server-side ASP.NET control is basically logic that knows how to render itself as HTML, how to load postback data, and how to save and load viewstate. Each time a page is requested, all the controls are instantiated and initialized, and on postback given the opportunity to load postback data and fire postback events. But once the response is sent the object goes out of scope and becomes eligible for garbage collection. This is not really a good idea, since all textboxes on all pages are the same type and they must always be created from scratch every time a page containing a textbox is processed. If controls, here the textbox, provided all their logic with static methods depending only on the parameters, there would be much less memory (de)allocation going on. (With the existing design something could perhaps be achieved by adding object pooling to the classes.)
If you believe this is a non-issue I suggest you make a simple page to test for yourself. Add a datagrid and write a simple query to select a hundred rows from a northwind table, or whatever, and databind the grid. Then add a script line to post the form after half a second ("setTimeout(500, form1.post)" inside the head section of the ASPX suffices), and then open up a few browsers and point them at the page. This isn't an unrealistic load at all - it's quite relaxed actually. Then take a look in PerfMonitor and check how much time is spent just on garbage collection. I've read (I think it was here on codeproject) of people who had to abandon the use of databinding as a direct consequence of GC overhead.
|
|
|
|
|
All the languages lend different functional advantages when developing. The battle has always been fought on that battle field and that is the wrong battle field. It is not the IL that wins unless you are comparing C++.NET to “VB.NET and C#”. It is how the IL is achieved with VB.NET and C#, and that is in the C# and VB.NET "code" design. VB.NET is a much more dangerous language.
VB.NET enables the VB 6.0 developer to continue to develop in a non-OOP fashion by using extra VB namespaces provided by Microsoft that wrap other .NET namespaces. This allows for some very dangerous developing to take place when it comes to performance and coding best practices.
THIS IS NOT TRUE OF ALL VB.NET DEVELOPERS. Some have taken the time to learn how to avoid the VB.NET pitfalls of developing in a non OOP way. So if you are one of those guys, don’t start blasting me.
In truth VB.NET is harder to use that C#. Because it makes it harder to do “Code” design, because it’s syntax is not an OO syntax.
I am a firm believer that all Enterprise level applications should be developed in C# and if needed C++. VB.NET is great for Rapid Application Development of front end applications. C# is geared to be a RAD code level development tool, where as VB.NET is geared to be a designer RAD development tool.
Microsoft of course says the languages are equal, but that is a marketing ploy to not loss their VB community of developers. Culturally however, in the architect and developer community, an enterprise framework coded in VB.NET is not viewed as being very credible. I have seen more VB 6 developers develop unusable code in VB.NET, than I have seen successful development since .NET has come out.
The same is true in ASP.NET. ASP developers that have not been properly trained on OOP make complete messes out of ASP.NET applications. ASP.NET site can be 10 times better than an ASP application, or 100 times worse. Many have been built without the proper training, and are ending up 100 times worse.
I always try to do what MS does, and try to avoid doing what they say to do. MS never used DNA internally. They only did that at customer sites to make it easier for them to develop. They provided Web Applications through an ISAPI filter. Now they are using C# development for any product that goes to the world. BizTalk is a good example. BizTalk 2004 has been developed in C# by Microsoft.
In truth I would be quicker to hire a 5 year veteran of Java to code C# than I would be to hire a 10 year VB 6 veteran to code VB.NET or C#. Java developers understand OOP, Most, not all, VB guys have been fooled into thinking that they understood it. By the way, I hate Java.
If I were a VB 6 guy coming to .NET, I would move to C# for a minimum of a year before going to VB.NET.
|
|
|
|
|
I would agree with everything said above, with just a couple of added points:
1. I have run across very few VB.NET programmers who knew how to use the FCL properly, and had practical OOP/OOD skills. Most of them just happened to one day stop using VS 6.0, and opened up a copy of VS.NET. They then assumed they were .NET programmers. The majority do not realize that VB.NET under the hood is a totally different machine that VB 6.0 - the similarities between them are only skin deep if you know what I mean. I would say the author of this article is an exception to this rule.
2. As I was once a VB 6.0 programmer, I know that when I was taking my classes, my instructor constantly, (even the text book) stated that I was learning OOP! When I started to make the jump to .NET and C#, I was quite upset to learn that dropping a "button object" on my form designer was not necessarily OOP.
While I prefer C#, and do not write VB.NET as I am ashamed of my VB 6.0 background , I have to say that of all the bad VB.NET code I have seen was the programmer's fault - not VB.NET. Many of the VB.NET apps I have see were simply VB 6.0 code that was cut and pasted into the VS.NET IDE - didn't even use the code migration tool. They just added some namespaces that allowed them to use the old VB 6.0 constructs or calls. They then claimed to have re-written the app in .NET. Rubbish! When it performs like a snail on a cold day, management claims .NET is the problem, not their star VB 6.0 programmer. Only when the requirements that the bad app are trying was to meet was thoroughly analyzed and a solid OO design developed, then implemented in C#, did management realize that it wasn't .NET, it WAS the programmer! But even then, it wasn't the c# code that allowed me and my team to deliver a fast, efficient, scalable app. It was the upfront requirements analysis, the time we spent learning the business rules, and the resulting design.
And I all fairness, I have seen some pretty darn bad C# code, too. For example, at a previous company I worked for, one "C# programmer" (at least that what she said she was), wrote a WebForm with one method in it. The only problem was that this method was over 4000 lines long made up of basically 20 or 30 chucks of code that were essentially the same thing, except for variable assignments. She was fired the next a few days later.
|
|
|
|
|