The first thing I learned when I started methodology was what a model actually was: a limited representation of a real world object or process. There is an inverted relation between the limitations and the usefulness of a model. It is always a real challenge to make a simple model that has few limitations. Unfortunately, when you put object orientation to the test it is a very limited model.
You can tell a microwave to fry a chicken. You can tell a video recorder to shut itself down. You can insert a coin into a vending machine and trigger the release of a candybar. But you can't tell a screw to screw itself into the wall. You can't tell a table to move itself. Wow, if that were the case moving would be a lot easier, although I would have a little trouble getting accustomed to all these items running on the streets.
I still get comments on an blog on object orientation I wrote some time ago. Some seem to have concluded that I don't like object orientation at all. That is not true. I used object orientation in the I/O system of my 4tH compiler. Object orientation is the basis of an architecture I designed to make unrelated information systems communicate by the web.
The problem I have with object orientation is that it seems to have become a paradigm. Some claim it even is, that everything is an object. Object orientation has even mythical properties. You can't reuse code when it is not object oriented. Object orientation boosts productivity. Object orientation results in safe code.
Well, none of that is true. It is a good design that results in reuse. I've seen horrific programs crammed into an OO-design that I wouldn't want to use, let only reuse. Object orientation needs serious deliberation before putting it into code. When a problem isn't suited for OO-design in the first place, your productivity goes down the drain immediately. And a badly designed or conceived OO-design can be terribly buggy, so where is your safe code now..?
In fact, object orientation is a technique, not a paradigm. It is in my toolbox and I use it when I see fit. When a programming language has some syntactic suger to make OO easier, fine, but I'd rather use C. There are techniques I use all the time, like CATCH, and I techniques I never use, like overloading.
Object orientation should have been the magic bullit that would allow boys to do a man's job. Like SQL should have been. Or 4th generation languages. Or Case tools. I've seen a lot of magic bullits flying over my head in my time. But what remains is the man doing his job, like I have for 20 some years.
Although I'm actually responsible at work for high level system management processes, I'm often forced to do the programming myself. Those guys just can't do it. It takes months to make a trivial design and even longer to do the programming. When it is finally released, it has already lost its usefulness, so it goes back for more design and programming. I finally gave up.
Last week was some nice week. I had just released an incident management application, which featured a nice touch that I call "events". Events come in certain types and categories. You can determine those categories and types yourself. On top of that there is an evaluation module that checks whether all incidents have been properly entered in the application. When not, the key performance indicator of your department drops. One of those department heads came by and complained I was checking on too many events. "Well, I don't" I replied, because I just check on the events the incident manager has flagged as "essential". Note I wrote the entire web-enabled incident management application in just two weeks.
Of course designing and implementing that event model took some time. But I saved a lot of time too, because I knew there would be modifications and I'd rather see them entering these in the application than me changing them in the actual code. After twenty years you know which requirements are subject to frequent change, even if they say they aren't.
My system administrator came by and he told me he needed an tool that converted a LDIF file into a CSV, so he could import it in a spreadsheet or database. I never heard of the format, but when I examined it, I noticed all fields had the format "field=value". Not all fields were in the same order and not all records featured all fields. I fired up my 4tH compiler and wrote a small program that collected all fields, rewound the file and then collected all data according to the format it had assembled. An hour later, it ran. I made an executable and mailed it to him. Five minutes later he stood at my desk, requesting the source. I said, I would print it. The printer spit out a sheet of paper and stopped. He opened the drawer to see if it was out of paper. But no. I needed no more than a three quarter page to achieve my goal.
Since I am a manager myself, I regularly check my databases. One of them, my patch database, was empty. When I researched the matter, I found out they had implemented a new version of Cisco Works. Cisco Works used to dump a CSV file, which was transferred to the database server, where it was converted to a SQL script. The conversion tool had found out there were no records to be converted and had deleted the old records, since there wasn't anything else left to do.
The new Cisco Works doesn't dump a CSV file, but an XML file. The system administrator sent me a sample to examine. XML is notoriously difficult to parse, since you don't know what to expect. Of course I could have done the same thing as the LDIF file, but a generalized solution like that would require a lot of code. I could also try to implement a general purpose XML parser, but it would take me weeks to get that through the system. It was time for a different approach.
I decided that I would treat the XML tags like commands. I only needed to build an interpreter. With 4tH that is easy, requiring only a line or three and a symbol table, mapping the name to the execution semantics. 90 minutes and two pages later, I had my 20K executable. It parses the 11 MB XML file, collects the information, validates it, cleans it up and makes a SQL script along the way. It also checks the command line parameters and is able to recover from internal errors. Even better, if more fields are needed, I only need to make a subroutine that collects the information and make an additional entry to the symbol table.
My system administrator sighed and said that anything he makes, I can make too, but only twenty times smaller, a magnitude faster and within a timeframe he can only dream of. I wonder whether you OO-boys can beat me and my 64K, low level, almost assembly 4tH compiler on that. If you do, I'll be happy to convert and I promise I'll never write blogs like this again.