If your project lead doesn't code, then you have much bigger problems than we're discussing here. Also, your accountants will tell you exactly what things cost, this is true. However, this is all that they will tell you. They won't tell you what it would have cost had you taken a different course, what things would have cost if you could work at a higher level of abstraction. There is a point at which individual language features like "with" statements become irrelevant, and you need to think of your program in terms of composing Bayesian filters, simulated annealing, genetic algorithms, and other such high-level topics. VB, C#, and most other languages keep you at the level of writing for loops, when really you'd rather be calling in much higher-level building blocks. You can kind of achieve this by writing a domain-specific language and then interpreting it, but I challenge you to find even one VB programmer among your staff who can manage this. In fact, I'll put my money where my mouth is: I'll bet you $100 that you can't write an AIM-349 scheme interpreter with your hordes of programmers faster than I can write one by myself in Ocaml. And finally, everything that I have spoken is the truth. I am a fairly public person, and you should be able to verify everything that I have said, at least about myself, personally. (Really, though, what the hell does it matter how many companies I own? The real question is who is a better programmer. I'm going to go out on a limb here and say that that would be me. Show me your open source code and prove me wrong. Mine is here.)

Yes. Two, in fact, one of which has developers in 3 different countries, and produces provably secure software. I am also chief architect at a third. It has been some years since I've looked for a job, but you can look at an old CV of mine if you like. I program in many languages; I even speak BASIC as a native language, by linguistics standards (I learned it when I was 3, during the critical language acquisition period). Further, I regularly program in C#, Java, Python, Go, Postscript, Bourne shell, Prolog, Ocaml, Haskell, and Lisp, and have at other points been paid to program in everything from Brainfuck to VHDL. I could keep going, but I think you get the picture. Also, it turns out that, from a human processing perspective, our brains are far better equipped to handle things like tb_pic_name than PictureNameTextBlock; we recognize words by their shapes and so the shorter the word, the more efficient it is to read. Finally, management tends to like things like VB because they look like English... but they are not in so many critical ways that this is in fact a negative feature. At the end of the day, management doesn't need to read code. They only need somebody that they trust to review the code quality of their developers' code, and to make sure that they're getting good value for their money. VB may seem to save a lot of money, but really it's costing you far more than you can imagine.

And this, in turn, is why I wouldn't hire you: you don't look past what is and see what could be. See, a simple rule that ambiguous member references within a With statement are not allowed (and are a compiler error) would sort out the scoping issues, produce something that has significantly more expressive power, and not make the language any more complicated. The fact that this is not part of the language is irrelevant: there are open-source visual basic compilers (eg, as part of the Mono project) that would be easily extended to support whatever extensions you like. This is not, of course, to say that I would advocate for such a feature to be added. It wouldn't result in any increase in code readability (rather, it would significantly decrease readability), and any given piece of code is likely going to be read far more times than it will be written.

Ermmm... those ain't that old. Or, at least not compared to some of mine... the Clipper manual, Win3.1 manual, Assembly language programming for the 8086... Now, I can't say that I've used the first two recently. But, the assembly book is (along with the x86 manuals) indespensible, especially in real mode.