Linked by Thom Holwerda on Tue 15th Jan 2013 21:24 UTC
Thread beginning with comment 549045
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Every single problem you have brought up and every solution has to be due to bad development practices in the vast number of cases.
I have no idea what you mean by "crufty" VB code, everything I can do in VB has direct C# equivalent apart from some minor things. But I come from a Java background.
Yes there are a few shitty things, but much like JavaScript and PHP if you are mindful of them you can successfully mitigate the problems ... again this comes down to whoever is writing the software.
Every single problem you have brought up and every solution has to be due to bad development practices in the vast number of cases.
I'd argue that whilst that may be true, all of the examples I've given demonstrate why VB is not a safe language to use. The fact that one can get away with writing such bad code in the first place is key. Come on - you have a Java background and VB is a good language over C#? Really? I respect that you have your own opinion and that you are writing the code you use, but my experience with working with varied VB shops tells me that I will never employ anyone to write code in VB going forward. All our VB is legacy and we are actively (though slowly) migrating it away from that language.




Member since:
2006-05-30
In your opinion. I've had zero issues parsing Xml in C#. The VB syntax makes my eyes bleed. The best integration I've seen is Actionscript.
If you say so. I think most sensible people that have encountered VB programmers would beg to differ. Even recently, a contractor was "let go of" because his code was pretty much the epitome of VB legacy over sense.
Haven't we all? And I've seen exactly the same in VB - plus all the other cruft that language brings with it. Between rewriting a few methods with bad decisions regarding exception handling and dealing with crusty VB code, well - I know what I'd prefer.
Seriousy? Here is how I deal with that: 10 minute talk including best coding practices handout, misconduct warnings (1 verbal, 2 written), bad yearly review if there's no improvement, removal from project work - probable contract termination. Do you know how often my organisation has had to go past first formal written warning? Probably 2 times in the last 15 years. This is why you interview carefully - with a formal practical element, pay for training when required and don't hire incompetent people. That's not to say mistakes are never made, but that's also why you give new hires a 3 month probation and make sure contractors are on weekly contracts until they have proven themselves.
And you can go on making excuses. Or you can just not use it. I know which one is better for my business and saves me the most money.