This is the story of a challenge.
I've just discovered Visual Basic and I can't believe people live this way! The worst thing about it is not that it is closed software, it's that the design of the language is so bad.
Something I've only seen passing mention to, and with much erm, discussion, on Slashdot is the comparison of Visual Basic to Perl.
I love Perl. It's so.. yucky. I use Perl but I don't really like to scroll it very far. It's fine if you can step back from it and see the whole lot just so you never get into the situation where you don't visit parts of the code for months of continuously working on it, only to eventually return and discover that weird stuff has been growing there. "Did I write this?"
At least that's the way it is for me. I've got a tendency to overengineer (which I fight) and I have learned not to trust myself. Larry casts the encapsulation/info-hiding question in Perl as one of people being nice to each other. Well I don't trust myself that far. I make mistakes. Java has been very satisfying (type safe, closures, interfaces). There are lots of opportunities for good designs that scale to larger code bases.
But VB. Oh my. It has the evidence of history, evidence of battles fought on that ground. But the big difference between Perl and VB is just that no-one has cared enough about VB to clean up all the bones which litter the surface of the language.
There are three syntaxes for assignment. Function calls require arguments to be parenthesised only when the return value is to be used "in an expression". They are forbidden otherwise (unless you prefix with the "call" statement). Error handling best practice is to use GOTO. Yes. Null is not a value, it's a type. I could go on all day.
Imagine you had a small team of VB-only developers who are very inexperienced despite having spent 5 years as highly paid professionals. They have no process to speak of, nor any policies or documentation. All they have is a splintered monstrosity, a mountain of VB source code which has been copy-and-pasted for most of a decade and a similarly "structured" cloud of stored procedures on a rusting 50 Gig database. Sound like fun?
Take that team and for every VB coder add two top shelf software engineers, technical leads from internationally widely-known research and development organisations, each with long experience in multiple OO languages and development methodologies.
"Take them from XBox to Redhat" said the CEO. What's going to happen next? It's going to be a bit of a rollercoaster, and there may be tears before bedtime, but as anyone can see we will not be using much (any?) of the legacy VB code. We're not going to .NET either.
My real question is why can't I find a good analysis of the problems with VB? No-one in language design takes it seriously. Yet It's so widespread! The closest I got to open source analysis tools was a parser that didn't quite get finished when it was dropped due to the ascendency of Mono. (a premature move, Mono wasn't anywhere near ready then, actually it looked like an excuse to bail out.)
Sometimes people have to suffer under VB for a while. Hopefully not long, but for me it is long enough to learn the language (though several of the libraries are still opaque to me). In a half-baked effort to close, this brings me back to Perl. I toyed with the idea of writing some lint-like stuff and dependency mapping tools for VB in Perl. In the end I suspect I'll do what everyone else I admire appears to do with VB: Ignore it and move on.