About: Item (3) - VB.NET provides the tools to check the types at compile time, and displays a warning. If the programmer with a brain knows what to do. In C #, instead, displays an error, preventing compilation. VB.NET compiler itself initializes the variables, so it is not necessary.
Item (5) - The speed of the code in C # and VB.NET the same way. Slow code, it is programmer error, not the compiler and language. We must be guided by the fact that we use only the natural function calls from NET Framework, rather than through a runtime VB.dll, which is natural if we want to squeeze speed.
i think u have no idea of computer language.
and u have just made an user interface and did something in the code and then....publish as an article.
U are cheating with guys...who are trying to use this tool.
don do that and remove this article and above all this bullsheet implementation!!!!
Go to http://codeconverter.sharpdevelop.net — I use it all the time, and it hardly ever messes up. It is not just a glorified regular expression engine, it actually runs the code through the SharpDevelop compiler, although it will handle code snippets. It can go C#->vb.net or vb.net->C#, and frankly I would not bother with anything else (unless someone comes up with a tool that can converter a whole project without cut-n-paste) . Sorry if this sounds like a sales pitch, I have no connection with SharpDevelop whatsoever. Someone may know of others out there as well.
I have not tried sharpdevelop converter, but I can recommend online converter at http://www.developerfusion.com/tools/convert/vb-to-csharp/
I used it to convert a C# 2.0 WinForms app with 32 .cs files into VB 2005, for a client who only knows VB. Copy/pasted each one. There were a few minor issues, that the VB compiler flagged and I easily corrected. Only serious annoyance is that C# comments at the end of a line usually got moved to their own line, BELOW the line being commented. Often, that made the comment looked like it was talking about the NEXT line. I had to manually move over a hundred comments back to where they belonged.
Still, if you've ever tried manually converting code, this is a minor complaint.
If I was going the other direction, I would also use this or the SharpDevelop one, for anything less than about 100 files. Beyond that, I would try the products at vbconversion.net (VBConversion) or elegancetech.com (C-Sharpener for VB). ~$200 US.
Have seen a lot of good and bad programming practices.
Which programming language is best depends on MANY factors such as which computer the software package will be run on, what computer language that the individual or team understands best, as well as many other factors... Not which language it is!
Sometimes the best solution is to mix code from several computer languages into ONE executable.
Case in point... Most Modern Computer Games are written with 90+% C Code with the timing dependent code optimized in Assembly Language for pure speed.
Michael Abrash wrote a book on this subject: Zen of Graphics Programming: The Ultimate Guide to Writing Fast PC Graphics. I would suggest this book highly to those interested in learning to speed up their executable code.
What MOST modern computer programmers seem to forget is to DOCUMENT their code. It is very very easy to document your source code so that whomever is to look at your code later will understand how and why the code is written the way it is written.
Assembly is the fastest language overall based on not calling unnecessary code like many compilers do.
For Example, to use a MS-DOS Console executable from Assembly takes just 15 bytes of executable code (6 which are used for the message) and 9 bytes that setup and call existing MS-DOS Functions. (1 to display the message, 1 to exit from the code.) On the other hand to do the SAME thing in the last 10 to 15 years with just C or C++ creates a 50+ Kilobyte executable. (over 50,000 bytes)
Visual Basic IS still a viable language to this day (November 2008)... it is LONG from being a DEAD computer language.
I have many VB.Net Projects that perform quite well with very few if any timing issues.
Visual C/C++/C# is a decent language... but at least for me has issues on large projects where most C/C++/C# programmers are used to using way way too many included files in a project. C Code tends to be spaghetti coded by most programmers that use it.
A really good example of this would be the VLC Media Player Program. A very nice executable but very very poorly documented for those that are not familiar with the project.
At present I have ONE C#.Net Program... Coding in C# takes me 3 to 10 times longer than writing the same code in VB.Net!
Syntax in C#.Net is too picky for my tastes. It is too easy to miss the ";" at the end of a line or use the right variable name but using the WrOnG CaPiTaLiZaTiOn causes the compile to not compile correctly.
In VB.Net, the intellisense in Microsoft Visual Studio editors works much better for me than coding in C#.Net!
One very often overlooked item is stress testing your software and having others help you do the same thing.
I have seen way too many programs that crash on something that would have been easy to fix had the programmer and his/her testing team focused on it properly.
Too many Computer Programmers are too lazy to document their code as well as too lazy to take the time to write well tested code.
Good computer programs are NOT an accident... it takes time to do the job right and not have to rewrite over and over and over.
Tim Sweeney of Epic Mega Games fame has told the story of writing code to the original Unreal Game. He wrote the software and rewrote it 6 or 7 times before he ended up with the final product. The end result was a very graphically stunning and a very well behaved software gaming product.
Bottom Line, Don't throw out the Baby with the Bathwater... or in terms of Computer Programming: Don't delete a running program written in a language that you don't comprehend until you have totally rewritten it in a computer language that you are familiar with using.
The poster of this message seems to have misread the article. I've voted for removal of the message, because it is irrelevant, off purpose, even misleading. The poster has the impression that the author of the article claims C# is better than VB, so that code SHOULD be ported. This is not what the article says. The article does state some specific well-documented issues with VB. The article also observes that some people prefer C# syntax. It could as easily have been about a C# to VB converter, and describing issues with C#. Either way, the article is providing something useful, and explaining when you might be interested in it -- which is more than can be said about the "Good Idea ... Bad Implementation" post.