Blasphemy
-
Christopher Duncan wrote: All you arrogant C++ bitheads (i.e., my brothers and sisters in arms) who constantly rag on the VB guys, step on up to the plate and tell me why, in practical terms, C# is more powerful than VB for .NET web apps. Ok, I'll bite it. 1. C# can create unsafe code. This means you have pointers, (almost) real pointers. This also means you can stackalloc memory, meaning much faster code. 2. C# resembles C++ syntax. IMHO, its much more beautiful. 3. C# is a type-safe language, VB.NET is not. [plug]VB.NET has some patological syntax ambiguities, which I digress about in my latest article[^], although the focus of the article is not this. [/plug] 4. C# have fine control over integer operation checking. 5. C# have the using statement for deterministic calling of Dispose(). If you don't know what it is, it means no handle leaks, if properly used. Only the mere existance of this statement can be the whole purpose of coding in C#. Without it, you'll need to resort to ugly try/finally in VB.NET. 6. C# generate doesn't generate nops on IL (VB needs it for setting "fake" breakpoints on statements that don't generate code). This means shorter IL. A 1Mb DLL in VB can be reduced to 900Kb in C#. 7. C# has the XML documentation feature. 8. C# can generate, right from the IDE, strong-named interop COM wrappers. With VB.NET, you'll need to resort to some ugly batch files with TLBIMP. 9. C# has "out" parameters. I love them. 10. Fine control of integer overflow checking with the "checked" and "unchecked" keyword. 11. The foreach statement on C# automatically calls Dispose on IDisposable enumerators. VB.NET don't. 12. C# has boolean short circuit. VB.NET has the ugliest sintax ever for this (AndAlso, OrElse). 13. C# has the :? operator. VB.NET has the ugly IIf, whith its collateral effects. 14. C# will have templates (aka generics) and other niceties on the next version. VB.NET will only be able to consume it, which says a lot about its future as a language. 15. Arrays in VB.NET are a nightmare. Redim should be ripped off. 16. Null, Nothing, Empty, "": the 4 constants of the apocalypse. 17. Me, MyBase, MyClass: the new 3 additions to the constants of the apocalypse. 18. Convoluted OOP syntax: a candy for those, without looking on MSDN who can tell me what's the difference between MustInherit and MustOverride. If you do,
This would make an excellent reference article, Daniel cheers, Chris Maunder
-
This would make an excellent reference article, Daniel cheers, Chris Maunder
Chris Maunder wrote: This would make an excellent reference article, Daniel I think you're right. I'll expand it and post ASAP. This is a very FAQ. Kant wrote: Actually she replied back to me "You shouldn't fix the bug. You should kill it"
-
There's a simple answer to that Chris. C# has the
unsafekeyword. I think this suits you. cheers, Chris MaunderThat seem's like a sufficient solution for Christopher D. Although, no-one should be criticised for their choice of languages. Yeah, you get extra functionality with one language, you might have to do things slightly different in another language. It's just down to personal preference and constrictions on time, like whether you have enough time to learn something new. It all ends up as 1' and 0's anyway. Live to ride. Ride to live.
-
Christopher Duncan wrote: All you arrogant C++ bitheads (i.e., my brothers and sisters in arms) who constantly rag on the VB guys, step on up to the plate and tell me why, in practical terms, C# is more powerful than VB for .NET web apps. Ok, I'll bite it. 1. C# can create unsafe code. This means you have pointers, (almost) real pointers. This also means you can stackalloc memory, meaning much faster code. 2. C# resembles C++ syntax. IMHO, its much more beautiful. 3. C# is a type-safe language, VB.NET is not. [plug]VB.NET has some patological syntax ambiguities, which I digress about in my latest article[^], although the focus of the article is not this. [/plug] 4. C# have fine control over integer operation checking. 5. C# have the using statement for deterministic calling of Dispose(). If you don't know what it is, it means no handle leaks, if properly used. Only the mere existance of this statement can be the whole purpose of coding in C#. Without it, you'll need to resort to ugly try/finally in VB.NET. 6. C# generate doesn't generate nops on IL (VB needs it for setting "fake" breakpoints on statements that don't generate code). This means shorter IL. A 1Mb DLL in VB can be reduced to 900Kb in C#. 7. C# has the XML documentation feature. 8. C# can generate, right from the IDE, strong-named interop COM wrappers. With VB.NET, you'll need to resort to some ugly batch files with TLBIMP. 9. C# has "out" parameters. I love them. 10. Fine control of integer overflow checking with the "checked" and "unchecked" keyword. 11. The foreach statement on C# automatically calls Dispose on IDisposable enumerators. VB.NET don't. 12. C# has boolean short circuit. VB.NET has the ugliest sintax ever for this (AndAlso, OrElse). 13. C# has the :? operator. VB.NET has the ugly IIf, whith its collateral effects. 14. C# will have templates (aka generics) and other niceties on the next version. VB.NET will only be able to consume it, which says a lot about its future as a language. 15. Arrays in VB.NET are a nightmare. Redim should be ripped off. 16. Null, Nothing, Empty, "": the 4 constants of the apocalypse. 17. Me, MyBase, MyClass: the new 3 additions to the constants of the apocalypse. 18. Convoluted OOP syntax: a candy for those, without looking on MSDN who can tell me what's the difference between MustInherit and MustOverride. If you do,
Yeah you are right, just having the using statement should be reason enough to code in c#. Cool, never knew there where so many differences. Thanks Daniel :-) An article would be appropriate as you can more whenever you hear a quirk. Daniel Turini wrote: Shadows, Overloads, Overrides and Implements. X| Cheers, Kannan
-
There's a simple answer to that Chris. C# has the
unsafekeyword. I think this suits you. cheers, Chris MaunderChris Maunder wrote: C# has the unsafe keyword. I think this suits you. Man, wear a leather jacket and buy one little Corvette... :-) Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
Christopher Duncan wrote: Here's my question. VB and C# are both managed languages talking to the same .NET runtime with the same restrictions. They strike me as nothing more than different colored wrapping paper around the same box. Strictly speaking, VB.NET is a bit more constraining as a programming language - you must manually declare overloaded functions with the Overload keyword, due to case insensitivity VB (I believe) cannot always consume CLR compliant code because the CLR is case sensitive, VB.NET's Integer is 16 bits instead of 32, etc... To use your analogy, C# is a very neatly wrapped package - there's just enough paper to cover the box, all edges are straight and neatly creased, and only two pieces of tape are used to keep everything together. VB.NET, however, is like a package covered in lots of little strips of leftover wrapping paper - it's messy, funny looking, there's almost as much tape as there is wrapping paper, and God help you if you ever actually need to get at what's inside the package. C# was built from the ground up as the high-level language to target the CLR - the other .NET-targetting languages have been hacked in. -- Russell Morris "Have you gone mad Frink? Put down that science pole!"
Russell Morris wrote: VB.NET, however, is like a package covered in lots of little strips of leftover wrapping paper - it's messy, funny looking, there's almost as much tape as there is wrapping paper, and God help you if you ever actually need to get at what's inside the package. Yeah, it definitely gets the syntax vote on my part. Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
Christopher Duncan wrote: I've got years of dirt on the guy, and I know Krista's cell phone number Sounds like a juicy story for sure. Can't wait for the mud slinging to start. Sorry I don't have an answer for your question. But I do look forward to other responses. Hopefully they will be more tech oriented than marketing driven. Chris Meech "what makes CP different is the people and sense of community, things people will only discover if they join up and join in." Christian Graus Nov 14, 2002. "Microsoft hasn't ever enforced its patents. Apparently they keep them for defensive reasons only. Or, they could be waiting 'til they have a critical mass of patents, enforce them all at once and win the game of Risk that they're playing with the world." Chris Sells Feb 18, 2003.
Chris Meech wrote: Sounds like a juicy story for sure. Yeah, but I've gotta save them for when I can get some mileage out of them. :-D Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
Christopher Duncan wrote: All you arrogant C++ bitheads (i.e., my brothers and sisters in arms) who constantly rag on the VB guys, step on up to the plate and tell me why, in practical terms, C# is more powerful than VB for .NET web apps. Ok, I'll bite it. 1. C# can create unsafe code. This means you have pointers, (almost) real pointers. This also means you can stackalloc memory, meaning much faster code. 2. C# resembles C++ syntax. IMHO, its much more beautiful. 3. C# is a type-safe language, VB.NET is not. [plug]VB.NET has some patological syntax ambiguities, which I digress about in my latest article[^], although the focus of the article is not this. [/plug] 4. C# have fine control over integer operation checking. 5. C# have the using statement for deterministic calling of Dispose(). If you don't know what it is, it means no handle leaks, if properly used. Only the mere existance of this statement can be the whole purpose of coding in C#. Without it, you'll need to resort to ugly try/finally in VB.NET. 6. C# generate doesn't generate nops on IL (VB needs it for setting "fake" breakpoints on statements that don't generate code). This means shorter IL. A 1Mb DLL in VB can be reduced to 900Kb in C#. 7. C# has the XML documentation feature. 8. C# can generate, right from the IDE, strong-named interop COM wrappers. With VB.NET, you'll need to resort to some ugly batch files with TLBIMP. 9. C# has "out" parameters. I love them. 10. Fine control of integer overflow checking with the "checked" and "unchecked" keyword. 11. The foreach statement on C# automatically calls Dispose on IDisposable enumerators. VB.NET don't. 12. C# has boolean short circuit. VB.NET has the ugliest sintax ever for this (AndAlso, OrElse). 13. C# has the :? operator. VB.NET has the ugly IIf, whith its collateral effects. 14. C# will have templates (aka generics) and other niceties on the next version. VB.NET will only be able to consume it, which says a lot about its future as a language. 15. Arrays in VB.NET are a nightmare. Redim should be ripped off. 16. Null, Nothing, Empty, "": the 4 constants of the apocalypse. 17. Me, MyBase, MyClass: the new 3 additions to the constants of the apocalypse. 18. Convoluted OOP syntax: a candy for those, without looking on MSDN who can tell me what's the difference between MustInherit and MustOverride. If you do,
This is brilliant Daniel! More reasons than I could ever come up with. I'll definitely be showing this to some friends who are staunch VB.NET supporters. :)
Hawaian shirts and shorts work too in Summer. People assume you're either a complete nut (in which case not a worthy target) or so damn good you don't need to worry about camouflage... -Anna-Jayne Metcalfe on Paintballing
-
Just do everything in Flash! ;P (kidding, i promise, i'm kidding!) - Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
Nitron wrote: Just do everything in Flash! Yikes! Are you kidding? After how grumpy Paul was yesterday??? Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
[start sarcasm/reality] You can rationalize it all you want, and you can spend countless hours trying to justify your decisions to yourself only so that you aren't so scared when you have to try to justify them to someone else. But, the bottom line is that you are a professional who is trying to get a job done, and as such, you must use the tools you have in your toolbox. They may not be the best tools, but they are all you've got, so your job is to use what you have to the best of your ability to reach the end result. You know that. You've written about it. And when you do end up using VB, don't admit it in public and don't talk too much about it around here. [end sarcasm] Dave "You can say that again." -- Dept. of Redundancy Dept.
David Chamberlain wrote: so that you aren't so scared when you have to try to justify them to someone else. Not me - I'm fearless! One of the few benefits of ignorance... :-) Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
Chris Maunder wrote: C# has the unsafe keyword. I think this suits you. Man, wear a leather jacket and buy one little Corvette... :-) Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
Christopher Duncan wrote: Man, wear a leather jacket and buy one little Corvette... :laugh: That was not a "little" 'Vette. ;P
Hawaian shirts and shorts work too in Summer. People assume you're either a complete nut (in which case not a worthy target) or so damn good you don't need to worry about camouflage... -Anna-Jayne Metcalfe on Paintballing
-
Christopher Duncan wrote: All you arrogant C++ bitheads (i.e., my brothers and sisters in arms) who constantly rag on the VB guys, step on up to the plate and tell me why, in practical terms, C# is more powerful than VB for .NET web apps. Ok, I'll bite it. 1. C# can create unsafe code. This means you have pointers, (almost) real pointers. This also means you can stackalloc memory, meaning much faster code. 2. C# resembles C++ syntax. IMHO, its much more beautiful. 3. C# is a type-safe language, VB.NET is not. [plug]VB.NET has some patological syntax ambiguities, which I digress about in my latest article[^], although the focus of the article is not this. [/plug] 4. C# have fine control over integer operation checking. 5. C# have the using statement for deterministic calling of Dispose(). If you don't know what it is, it means no handle leaks, if properly used. Only the mere existance of this statement can be the whole purpose of coding in C#. Without it, you'll need to resort to ugly try/finally in VB.NET. 6. C# generate doesn't generate nops on IL (VB needs it for setting "fake" breakpoints on statements that don't generate code). This means shorter IL. A 1Mb DLL in VB can be reduced to 900Kb in C#. 7. C# has the XML documentation feature. 8. C# can generate, right from the IDE, strong-named interop COM wrappers. With VB.NET, you'll need to resort to some ugly batch files with TLBIMP. 9. C# has "out" parameters. I love them. 10. Fine control of integer overflow checking with the "checked" and "unchecked" keyword. 11. The foreach statement on C# automatically calls Dispose on IDisposable enumerators. VB.NET don't. 12. C# has boolean short circuit. VB.NET has the ugliest sintax ever for this (AndAlso, OrElse). 13. C# has the :? operator. VB.NET has the ugly IIf, whith its collateral effects. 14. C# will have templates (aka generics) and other niceties on the next version. VB.NET will only be able to consume it, which says a lot about its future as a language. 15. Arrays in VB.NET are a nightmare. Redim should be ripped off. 16. Null, Nothing, Empty, "": the 4 constants of the apocalypse. 17. Me, MyBase, MyClass: the new 3 additions to the constants of the apocalypse. 18. Convoluted OOP syntax: a candy for those, without looking on MSDN who can tell me what's the difference between MustInherit and MustOverride. If you do,
Excellent list! Looks like a lot of it is coding benefits. I suspect I'll end up in the C# camp someday for that reason alone. However, those 2 hours a night are really appealing... Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
This would make an excellent reference article, Daniel cheers, Chris Maunder
Chris Maunder wrote: This would make an excellent reference article, Daniel I concur! Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
C# != C++
NOT VB = VB.NETYou're gonna have to learn the framework and get bit by syntax subtleties either way - choose on merit.
- Shog9 -
I'd show a smile but I'm too weak I'd share with you, could I only speak
Shog9 wrote: NOT VB = VB.NET But wait, you only used one "=". Can you do that?!?!! This is all so confusing... Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
Actually having used about 5 OS's (I'm only counting Windows once) and about 10 languages professionally, I've always stated that you should use the tool that works best in terms of developer productivity and the company's future (with regards to things such as code maintenance and ease of finding developers for the system). You'll remember that I was first an OS/2 programmer years before Windows was even a viable development platform. However, I switched to Windows programming for the simple reason that it was more productive and I could see that despite my personal feelings about OS/2's superiority, Windows was going to win the OS war. Therefore, choosing an OS with the better future was the correct choice for my client. Regarding selecting C# or VB, I would look at how the advantages of each language play out for your particular situation:
VB Advantages
- Most .NET books (especially in the area of ASP.NET) are focused on the larger target audience - VB
C# Advantages
- Has a syntax that is more familiar to C++ developers
- Most "hard-core", or advanced, articles and books use C#. Therefore, when you run into an especially difficult problem, the source code will probably be in C#
- There are some things that VB.NET cannot do. Since I don't use the language, you'd need to frequent those boards and sites to see specifics. However, I do know that the VB coders have complained since the release of .NET that despite the promise that all languages will be equal, C# still gets preferential treatment in terms of functionality.
- Pursuant to my previous point about C# having more capability, there is a feeling among some that C# will become Microsoft's language of choice for .NET development. I don't VB.NET will be dropped, but that could mean that designers and other tools for VS.NET will be developed quicker for C#
- As various news media have pointed out, while you can do about 95% of the things in VB that you can in C#, there is still the attitude in the marketplace that C# is a "real" language and therefore C# programmers command a higher salary.
Will you be more productive with one or the other? Depends. It seems like you're already comfortable with VB.NET so that doesn't seem like an issue for you. I would be more concerned with issues of getting to know C# in terms of future marketability. The bottom line is that I've always used the best tool for the job at the moment so that would be my determining factor o
Tom Archer wrote: Besides, even if this VB.NET thing falls through for you, you can always fall back on being a musician. Actually, I just came out of the studio to check the comments. Been in there all morning recording bed music for the CDs. I almost forgot how much fun this music stuff is. Tell me again why I work for a living? :-) Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
Christopher Duncan wrote: tell me why, in practical terms, C# is more powerful than VB for .NET web apps. Over the past 10 years I've coded in Delphi and VB. Object Pascal is an elegant language and I love it, but VB is where the contracts and the money was. No point sitting at home waiting for the phone to ring with a Delphi offer when there were a hundred VB contracts waiting to be filled. :cool: From there the obvious transition was to VB.NET. Not because I am (or ever was) a big fan of VB. (I can see its shortcomings, and it annoys me no end that script kiddies pick it as their language of choice and pretend they are 'programmers') But for the simple fact I'm not going to sit here for 2 months trying to learn the intricacies of a new language (C#) when I have people breathing down my back to deliver their app. Yes, C# is a lovely language, and I do dabble in it, and I'd love to write all my code in it. But, I don't have the time to go through the pain of re-learning a new language - with little end benefit. Right now I can sit down and churn out VB.NET code that I know will work, without having to really think about it. I've done it a hundred time before in VB. I don't want to have to check syntax, manuals, and examples for even the most simple lines of C# - My memory isn't what is used to be either! :~ The .Net framework has given me even less reason to move to a new language. On .Net all things are equal, regardless of whether you code in C# or QBASIC.Net... :laugh: John www.silveronion.com[^]
John Honan wrote: QBASIC.Net... :omg: Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
Christopher Duncan wrote: Man, wear a leather jacket and buy one little Corvette... :laugh: That was not a "little" 'Vette. ;P
Hawaian shirts and shorts work too in Summer. People assume you're either a complete nut (in which case not a worthy target) or so damn good you don't need to worry about camouflage... -Anna-Jayne Metcalfe on Paintballing
:-D Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
That seem's like a sufficient solution for Christopher D. Although, no-one should be criticised for their choice of languages. Yeah, you get extra functionality with one language, you might have to do things slightly different in another language. It's just down to personal preference and constrictions on time, like whether you have enough time to learn something new. It all ends up as 1' and 0's anyway. Live to ride. Ride to live.
Taslin wrote: Although, no-one should be criticised for their choice of languages. Usually I'm just criticized for the kind of language I use. ;-) Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
This is brilliant Daniel! More reasons than I could ever come up with. I'll definitely be showing this to some friends who are staunch VB.NET supporters. :)
Hawaian shirts and shorts work too in Summer. People assume you're either a complete nut (in which case not a worthy target) or so damn good you don't need to worry about camouflage... -Anna-Jayne Metcalfe on Paintballing
David Stone wrote: I'll definitely be showing this to some friends who are staunch VB.NET supporters. Good! If we can bring only one programmer to the light, all this work will be worthy :) Kant wrote: Actually she replied back to me "You shouldn't fix the bug. You should kill it"
-
Christopher Duncan wrote: All you arrogant C++ bitheads (i.e., my brothers and sisters in arms) who constantly rag on the VB guys, step on up to the plate and tell me why, in practical terms, C# is more powerful than VB for .NET web apps. Ok, I'll bite it. 1. C# can create unsafe code. This means you have pointers, (almost) real pointers. This also means you can stackalloc memory, meaning much faster code. 2. C# resembles C++ syntax. IMHO, its much more beautiful. 3. C# is a type-safe language, VB.NET is not. [plug]VB.NET has some patological syntax ambiguities, which I digress about in my latest article[^], although the focus of the article is not this. [/plug] 4. C# have fine control over integer operation checking. 5. C# have the using statement for deterministic calling of Dispose(). If you don't know what it is, it means no handle leaks, if properly used. Only the mere existance of this statement can be the whole purpose of coding in C#. Without it, you'll need to resort to ugly try/finally in VB.NET. 6. C# generate doesn't generate nops on IL (VB needs it for setting "fake" breakpoints on statements that don't generate code). This means shorter IL. A 1Mb DLL in VB can be reduced to 900Kb in C#. 7. C# has the XML documentation feature. 8. C# can generate, right from the IDE, strong-named interop COM wrappers. With VB.NET, you'll need to resort to some ugly batch files with TLBIMP. 9. C# has "out" parameters. I love them. 10. Fine control of integer overflow checking with the "checked" and "unchecked" keyword. 11. The foreach statement on C# automatically calls Dispose on IDisposable enumerators. VB.NET don't. 12. C# has boolean short circuit. VB.NET has the ugliest sintax ever for this (AndAlso, OrElse). 13. C# has the :? operator. VB.NET has the ugly IIf, whith its collateral effects. 14. C# will have templates (aka generics) and other niceties on the next version. VB.NET will only be able to consume it, which says a lot about its future as a language. 15. Arrays in VB.NET are a nightmare. Redim should be ripped off. 16. Null, Nothing, Empty, "": the 4 constants of the apocalypse. 17. Me, MyBase, MyClass: the new 3 additions to the constants of the apocalypse. 18. Convoluted OOP syntax: a candy for those, without looking on MSDN who can tell me what's the difference between MustInherit and MustOverride. If you do,
Boy I love it when C# bigots post comments about VB.NET without really knowing VB.NET. And why is it that this argument still exists. It's like it moved from C++ vs VB.NET to C# vs VB.NET. Where are the C++ vs C# arguments? Anyways, there a couple of flaws in this list. 1. If I want to do unsafe code, I'll use C++. Removes all the "issues" surrounding this type of development caused by using C#. 2. I personally don't care for the C'ish syntax. This is a choice issue. I like the verbose nature of VB.NET. 3. Option Strict On... 'nuff said. 4. "fine control over integer checking". After 20 years of developing software, this has never been a issue. I just plain turn it off... and check myself when the need/questionability arises in my own code. 5. 'using' is cool. Would be nice to have it. However, it's a nicety, not a necessity. 6. I think if you turn on modifying the compiler options, much of this IL will be removed. However, even with them in there, is there really a performance issue with this? OK, so the file size is a bit larger... we are talking about .NET here, right? Not really a valid argument to discuss file sizes. It requires a 20meg runtime for crying out loud. 7. XML documentation is very nice. However, with the current versions there are several add-on products (free as well) that add this feature to VB.NET. Also, version 2.0 will include this feature as well. 8. Cool feature, but how often are you really doing this? 9. 'out' - as recently posted to my blog at http://www.addressof.com, is available in VB.NET as the attribute. 10. Ummm... are you inflating this list by posting the same thing multiple times? See #4. 11. I'm not positive, but I don't think that foreach really does what you say it does. Again, I could be wrong. If I am, see #5. 12. OK, so you don't like the syntax; but VB.NET can do this. I like the syntax, it's clearer to me. 13. Again, a syntax thing. 14. You are making forward looking statements. Right now the rumor is that VB.NET will have generics. Also, the rumor is that VB.NET will have Edit and Continue in the debugger, C# will not. Again, these are rumors. 15. No Redim? What's the alternative... several lines of code. However, this is yet another syntax "issues". 16. Gee, more syntax... not a limitation. 17. Oh... look more syntax differences. Not limitations. 18. Whatever, learn the language. It's only "convoluted" because you don't know VB.NET. 19. Ummm... a) look up the documentation. b) learn the language. I do know the di