Finally I'm taking a job at an actual software company. They put out open source, in addition to proprietary software (though they ship all their code). They are small, dynamic and financially successful. Now, in the words of a business development manager (read sales person with a bigger budget and less rules), I can work in a profit centre instead of a cost centre.

But that made me think, in any business, you can see any part as a cost. But then all business costs should be considered investments. Much in the way that Quality is Free.

So I'm happy that at least there won't be people in the business telling me I'm a cost rather than profitable.

OK So the VB thing went away finally. It's funny re-reading that entry after what feels like so long.

I've been ejoying clocking up a couple more years hands on J2EE. There's a mountain of APIs and knowing them really does help. If only the simple matter of knowing the principles was enough to see you through.

Knowing what you don't need to build can be such a time saver when you've got an objective in mind. Although sometimes I just like the zen practice of gardening in code and don't mind if it's a little aimless. So I'm getting over my frustrated amazement at the amount of rework being done in open source. Yes it's wasteful but it may be a healthy primeordial soup out of which not just the best software can emerge, but the strongest and most dedicated teams as well.

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.

Armbothism, dude - I haven't really done much open source at all! I did GPL some code last month but it's not distributed or anything... just a thought.