Any high level language in fact, use Perl, Python, Ruby, or even Javascript. I don't care. Steve Yegge, someone I have a lot of respect for after his
talk at OSCON last year, has posted another
rant on his blog and given us a
portrait of a newbie...
Steve argues that new programmers over comment their code. That they're using comments as a crutch to help them think through their approach to the problem.
He's got a point, it's not that I don't comment my code any more, although to be honest I don't comment my code that much any more. It's not that I don't write extensive documentation, although to be honest I write really lousy documentation these days, far worse that I used to, when I actually wrote several cookbooks and user manuals for my
old project that apparently people actually quite liked.
It's not that I can't be bothered, or that I think documentation is unimportant, it's that the sort of problems I'm solving mean that documentation isn't really relevant. The people that need to understand the code already do, and the people that need to use the code couldn't fix it even if I'd spent weeks documenting it. Not because comments and documentation are a bad thing, it's just that you can have too much of a good thing.
Of course Steve's real target isn't comments, it's data modelling, and by extension statically typed languages. Steve argues that over using data models is just like, exactly the same in fact, as over commenting your code. It doesn't actually help you get stuff done.
...data modelers who were overly-concerned about data integrity when the real business need was flexibility, which is sort of the opposite of strong data modeling. When you need flexible storage, name/value pairs can get you a long, long, LONG way.
I find a lot of the data modeling efforts which go on as a pre-cursor to actual work, and in a lot of cases replacing actual work, totally pointless. I've watched people struggle with, in my view totally unsolvable in the general case, data models for months (sometimes years) and not actually produce any code as a result.
...when in doubt, don't model it. Just get the code written, make forward progress. Don't let yourself get bogged down with the details of modelling a helper class that you're creating for documentation purposes.
Which is why I use a loosely typed language. More than one loosely typed language in fact. Because, like a lot of Perl people these days, I'm starting to use a lot of Javascript to solve a certain sub-class of problem. Weakly typed languages help me get stuff done, and more importantly, get it done quickly. As a result my data models aren't that strong, in fact, in some cases they're pretty weak.
However a lot of the time I later hide my weak data model behind an nice fluffy object layer that looks like a strong data modelling. But generally the code underneath has lousy data modeling. You know what? That doesn't bother me in the slightest because data models are constrain what you can actually do with the data, and generally I've found that to be a bad idea. Because someone will inevitably come along next week with requirements you haven't thought about.
Which, as an aside, is why I've
never really understood the obsession Java people have with patterns, which mostly seem to be common sense or not very useful.
I'd much prefer to have got lots of stuff done in a certain amount of time, than a little bit of stuff done, but done "properly". Because you can always go back and fix stuff you did earlier if people find it useful. But if you never do stuff at all, then nobody will ever find it useful. It's amazing how much stuff you do, that seems important at the time, and people have been pleading with you to make happen, that nobody ever finds useful.
I guess I'm a prototype and throw it away sort of guy, the data model doesn't seem that important, getting stuff done is more useful.
