The prospect of (short-term) work panned out - since about Jan 6 I've been working on a smallish database project - telemarketing stuff (to businesses, in biz hours only - not that *other* kind we all hate)...
Using Microsoft Access 2000 and VBA (Visual Basic for Applications).
I used to be somewhat disparaging about VB programming - after all, it's not a *real* language like C or C++ or Pascal (a la Delphi) or Java.... not so sure anymore though. It's taken me longer to get confident with it than I had expected.
I think part of the problem is that there are many ways of doing the same thing with Access (and VBA) - and it's not always obvious which ways are best. The same is true of all programming, I guess.
Books help - I bought a total of 4 to help along with the project - some had code examples which were just plain *wrong* - not sure whether they were tested before being published (as screenshots full of code) - I think not.
The VB(A) environment is pretty nice in some ways - somewhat reminiscent of Delphi or C++ builder... but somewhat clunkier. Some of the completion stuff is annoying - it will give you a list of possible completions when you enter a '.' to start typing a member variable or function of an object - but if you fumble slightly it gives up ad you have to cursor back (or BS) back to the period in order to display the choices again.
There's heaps of stuff listed in the References (add-on stuff with extra controls etc.) - some of it apparently redundant (which version of DAO should I be using? - There are at least 2 - and there seems to be a third one which [replaces/extends?] one or both of the others).
Anyways, it's all a learning curve, and I've certainly learnt heaps in the last 6 weeks or so.
Some ideas floating around in my head (typical!) about how I would improve some stuff in Access - and abstractions of common patterns (how many times do I have to make a slightly-different Enter or Edit form?)... I guess that is where the value-add is in 3rd-party extensions and toolboxes.
Still have heaps more to learn - I hope to take some time to summarize some [IMHO] better ways of doing this kind of project.
Also have been playing with Squeak - a generously-licensed (free-ish) Smalltalk(-80) system for Linux and Windows - see www.squeak.com
I'm impressed with a lot of the rhetoric surrounding Smalltalk - it's held a certain aura for me since the Aug 1981 BYTE magazine issue (virtually solely devoted to Smalltalk). Many of the more modern languages have used Object-Oriented paradigms, but have been encumbered with the dogma of strong typing (which I myself swallowed) - Alan Kay, one of the original Xerox PARC developers, thinks that computing has drifted off into side alleys since Smalltalk's inception - and has some scathing words about modern hardware architectures. One Smalltalk 1979 benchmark runs only 50 times faster on a modern CPU than back then - the hardware should run it about 50 *thousand* times quicker! - so something is out of whack by a factor of 1000! So is it the hardware architecture's fault, or are 'modern' programming languages to blame?
C++ seems to have some arcane (baroque, even) features and feature interactions - it's probably one of the harder computer languages to master. I can't help wondering whether a multiple-inheritance-augmented Smalltalk might be a more comfortable environment in which to achieve similar (Simula-r?) things.
I need to put some feelers out for some more work - I'm hoping to basically finish this database project tomorrow (and take a coupla days off).
...And so to bed.