I happened upon this thread and had to register so I could reply.
VB6 bites. I never met a good programmer who uses VB.
Most VB prgrammers do not understand the nuances of OOP.
They have never programmed service applications or robust COM components and do not program event/message driven applications. Their applications usually resemble scripts and are very inefficient. NOTE, I haven't met EVERY VB programmer so this is a generalization, but the world is run by heuristics and it will continue to be.
Sorry, VB programmers need not apply in my shop.
VB.net does compile down to the CLR, but it is still clunky. There are some truly efficient and elegant techniques available in the .NET world you CANNOT, I repeat CANNOT, implement in VB.NET
Myself, I am partial to C#, but I am a former Delphi (RIP) devotee and C# has the robustness and flexability that was previously only available in Delphi. And the beauty of C# is that I can show my code to the non programming stakeholder and he can, for the most part, read it and tell me if my algorithms are correct. Still, this is due primarily to my using an effective coding style. One that incorporates the nouns and verbs of the problem domain and not because of the language in which I program.
There is no end all be all when it comes to programming languages. A good programmer will be language agnostic. He will simply know how to program. He will have the general skills necessary for effective investgation and be able to leverage any available technology to produce an efficient solution.
Key skill required? A formal education in software engineering.
Why? Because he will know the taxonomy of software engineering.
He will know is meant by such terms as persitance, serialization, instrumentation, and profiling. He will know when an application will call for these features. He will investigate the various implementations and apply the flavor that will yeild the most efficient approach. Effecient does not always mean fastest execution, but also time to delivery, configuration, documentation and revision. thebeauty of .NET, as far as I can see, is its homogeny.
C# might be really smooth fulfilling functional requirement 'A', C++ for functional requirement 'B' and an interop assembly addresses requirement 'C.' Meanwhile, my Distribution manager only knows how to run the VB.NET command line compiler (he uses the command line because he is not a devloper and doesn't need the studio suite, and we are driven by costs) and we are able to deliver the product.
Also, keep in mind, there is a category of applications called 'code generators.' Their development is critical in many areas where traditional applications are not adequate. These applications are developed in one language, take input from the user and output a second application customized toward a specific need.
My last contract, in the pensions industry, called for an application that had to give the user the ability to input user defined FORTRAN procedures that would perform specific tasks for different end users. This program was devloped in Delphi, and consisted of a skeleton executable with defined points where the users FORTRAN code would be inserted. Why fortran? well actuaries seem to only undestand FORTRAN (you think computer geeks are nerds? ever seen an actuary? they make geeks look GQ) At any rate, the user would manually enter fortran code or a reference to an external DLL at specific 'entry' points, press a button, and the result would be a set of executables and libraries
that implement a truely robust, company specific Retirement Plan software suite. Devolping this application meant knowing FORTRAN, Delphi and general windows programming. Did we know FORTRAN going into the preoject? No,. but we knew we had the skills that would enable us to learn it.
To sum it all up. . . VB'ers, learn to program. . . PLEASE! I am sick and tred of having to clean up your code!
