I’ve come to realize that the paradigm of the expert programmer has changed dramatically over the past few years. There was a time when the expert in the group was the person who really understood whatever language was being used by the shop (or, in the case of companies with poor technology management, whatever languages were being used by the shop). After learning the language, the next area of expertise that a programmer developed was an understanding of the database or file system being used. And that, probably, was that.
Over the past few years, though, things have changed. For one thing, languages have become simpler. Recently, I had to compare my favorite mainframe language, PL/1, to VBA, and it was an enlightening experience. PL/1 had far more functions than Visual Basic, for instance. I still miss the Ceiling function, which, when given a list of numbers, would return the largest one. PL/1 also had far more keywords than VBA has ever had.
To make matters worse, ever since Visual Basic 3.0, the number of keywords in VBA has actually been decreasing. The precursor of this movement was C, which was designed to be a radically small language so that it would be easy to create compilers for it. In C, what had been built into older languages was provided through functions in a set of standard libraries. As the authors of the language pointed out, the cry of many new C programmers was, “What do you mean, I have to call a function just to compare two strings?” In the same way, many of the functions that used to be built into the Visual Basic language, circa version 3.0, have been removed. Instead, functions like Date and Time have become methods of pseudo-objects like _DateTime.
If it wasn’t before, VBA has become a very simple language. When someone asks for the “secrets of VBA,” it’s hard to know how to respond. There isn’t much in the language that benefits from deep study. Currently, SQL is the only language that I can think of that reveals deeper secrets the more that I study it. A complete course in the VBA language probably wouldn’t take much more than a week.
As Access developers, you know that you’ve probably spent as much time learning the DAO object model and the Access object model as you did learning VBA. And, if asked, you’d probably admit that you have more to learn about those two object models than you have left to learn about VBA.
And you’re not done yet. Over the past five months, Russell Sinclair has provided you with as complete an understanding of the ADO object model as we could fit in this newsletter. I’m sure that if you aren’t familiar with Microsoft Transaction Server (a tool for managing objects), then you’re wondering if you should be. If you want to make your Access application data available on the Web, then you have to learn about the ASP object model. I just wrote an article for Pinnacle’s ActiveWeb Developer about using the objects and controls that make up Remote Data Services.
People ask me what my area of expertise is, and I say, “Anything that I can get at with VBA: Access, Office, Visual Basic, ASP, you name it.” VBA is really just a tool to manipulate the objects that you need to meet the needs of your application. Part of the reason I have this on my mind is that I’ve been working on a book (The Visual Basic Object and Component Developer’s Handbook, for Prentice Hall) that’s all about creating your own object models. In the last third of the book, I show how to create components that work with Microsoft Transaction Server, ADO, the Visual Basic IDE, and so on. Working through these components brought home to me how objects have become the most important part of my development environment.
So, who’s an expert now? These days, an expert is someone who knows a particular object model in depth. An expert is someone who has worked with a set of objects long enough to know what they really do, as opposed to what the documentation says they do. And that has implications for how you work and how you work with others. But that’s a subject for another issue.
