The problem is that you still have to be a skilled programmer; you have to know not only about the language but about good programming techniques also. I have known a lot of programmers that have no business being around any language and some that would be all-stars no matter what language they touched. So would you be judging the language or the programmer?
I don't really want to hijack this thread with that debate, although I will happily discuss it on another thread if anyone likes. I love a good debate and while I normally avoid some issues on forums because it can degenerate quickly - one of the things I like about this forum is that it is consistently good for a non-degenerative debate.
To answer that question though - obviously to establish a meaningful comparison between languages a lot needs to be taken into account. As you say - there is the skill of the programmer(s), also are the techniques they are using appropriate to the task? Is the language they are using a good choice given the objective? Is the project just badly designed from a 'lets design this project by commitee' point of view?
Blaming the language would be easy for a programmer to do when faced with a problem, just as blaming the tech-support guy is easy for some office drone wanting to know why his macro isn't working. I have seen cases where a problematic VB deployment has been blamed on the programmers, or the designers, or the purchasers, or the consultant that reccomended it, and on and on. At what point do you just have to say that it is a problem with VB?
Having been involved in many projects over the years as a programmer, systems analyst (design), tech support guy, troubleshooter of failed systems, trainer, etc etc, blah blah, I can say without a doubt that the there is a 'VB problem' It is the wrong tool being used for the wrong job. Is it un-fair to label this as VB being a bad language? Probably, but it helps to do so if it discourages people from choosing it by default instead at least exploring other options and then choosing VB, based on an understanding both of VB and the needs of the project. I have seen this so many times with VB being chosen by default, by commitee, and then a project ending up needing to be scrapped at an often huge cost and re-designed using something more robust, it is like seeing the symptoms of a disease, eventually you have to ask 'is it a problem with VB, or is it just that VB get's mis-used a lot? What, then, is the place for VB? What is it's purpose?'
Dammed if I know, maybe for knocking up very small front ends for simple repetative tasks for data entry for office temps who are likely to make too many mistakes with something like excel. To be honest, that is about it for VB. That is it's niche. I have seen it used for this and it works well.
Anything else, use..... well anything else..... Anything.
To specifically relate this to Aurora 4X (and disguise a thread-jacking) - this is a one man project where he has developed this over the years from a game assistant into a simulator into a game. He has stuck with it and it has turned into a monster. Nothing wrong there - I have a few projects like that myself.
He has shared it with people and it is really enjoyable. I would not expect it to look good under the hood, and when I say that the dev is to be congtratulated that it works as well as it does I am taking this into account and not just VB.
He is working on a new version not in VB and that is where I would take it too, now that it has been prototyped and he knows more where he wants to go.
My rant about VB is really coming from deferred frustration from the VB disasters I have seen, the stress it has caused real people in real life, and my feeling that I need to somehow reverse my previous failures to help people avoid these VB disasters, so Jesus will love me and I can go to heaven and chill with Dennis Ritchie, drinking endless martinis, and enjoying endless virgins.