Blasphemy

[Daniel Turini]

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"

[Cory Smith]

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

[David Stone]

Well, it was Cory Smith, and he just responded to your post. He'll never convert, but I think if we just shine the light at him enough, he'll eventually go blind and have to stop coding altogether. :)

---

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

[Daniel Turini]

Cory Smith wrote: Boy I love it when C# bigots post comments about VB.NET without really knowing VB.NET. You are wrong, I know a bit VB.NET more than you, and I'll show you: Cory Smith wrote: Also, version 2.0 will include this feature as well. "Rumors". :) Cory Smith wrote: 10. Ummm... are you inflating this list by posting the same thing multiple times? See #4. Ok, a typo. This was a post, not a formal article, like I'll do later. But you can swap it for "no support for pre-build/post-build steps". Cory Smith wrote: 3. Option Strict On... 'nuff said. Do you think "Option Strict On" makes VB a type-safe language? Well, MS don't. Read what MS says on "Option Strict Statement" help: "Restricts implicit data type conversions to only widening conversions. This explicitly disallows any data type conversions in which data loss would occur and any conversion between numeric types and strings." Cory Smith wrote: 8. Cool feature, but how often are you really doing this? Probably twice a day. If you coded a lot using System.EnterpriseServices, you'd need signed assemblies and you'd know how big this hassle can be. Cory Smith wrote: 14. You are making forward looking statements. Right now the rumor is that VB.NET will have generics. No, VB.NET won't. And C# generics are not a rumor. Cory Smith wrote: 20. "VB Runtime sucks". Then how come I see a lot of questions that go along the lines of "how do I do x in C#, it's this way in VB.NET"? Using your Replace as an example, the Replace in the VB runtime does a **LOT** more than the Replace in the FCL. More error checking, and ability to replace within a portion of the string. Not really a comparison. If wanting speed and the features of the FCL version are enough, use it. If you need the features of the VB runtime version, use it. Again, learn the language. Possible nasty side-effects on the GC should be clearly docummented. Cory Smith wrote: Using your Replace as an example, the Replace in the VB runtime does a **LOT** more than the Replace in the FCL. More error checking Can you please mention which error checking VBRT does that the FCL doesn't? The rest? You are right: "Only syntax". But on my book, clean code is my #1 goal. So, if the syntax of a language contributes to make the code less readable, I

[Rob Manderson]

I thought that sounded awfully like a hint :) Rob Manderson http://www.mindprobes.net