This post in many ways is a continuation of the entry about the proliferation of programming tools that we are inundated with these days. Back in the annals of time I remember a drunken session with some programming buddies, and we were discussing some of the extensions that would be handy to have in the mainstream languages.
This discussion started over a serious problem that we were trying to deal with. It was in 1978, and we were working with an evil piece of IBM hardware called a 3790. This particular computer had very few redeeming features.
Our problem was that we had two programs running that needed to talk to each other. One process communicated with the user, the other performed a database lookup. The theory was that the User process, would request some data, go off and do some other processing then come back and get the data. Unfortunately our early tests showed that 99% of the time when the User process came back, the cupboard was bare! The database lookup had not finished, and so there was nothing in the buffer for the User process to use. This particular problem was resolved over beers, and yes the design document was a beer napkin. We created the "loiter loop". Basically the program went to sleep for a couple of seconds.
I guess management were just used to us Tech's talking babble, cos no one ever asked us what the "loiter Loop" did, it was just an integral part of the synchronization process!
Anyway, over more beers we hashed out our wish list of programming extensions.
Assembler was one of the main tools we used on a daily basis, we decided that the following op codes would be a fine start:
BAL - Branch and Loop
BCF - Branch and Catch Fire
BRR - Branch on Random Register
RXR - Randomly Transpose Registers
BOHP - Bribe Operator for Higher Priority
Of course Assembler uses stacks to deal with data, basically you put things on the stack (push) and take things off the stack (pop). There are two common techniques used in stack manipulation, FIFO, which stands for First In First Out, basically the piece of data that is stuck on the stack is the first piece of data to be dealt with. The other technique is called LIFO, Last In First Out, meaning that the most recent piece of data on the stack is the first to be dealt with.
We decided that this arrangement was to limited, and came up with a third stack manipulation technique, FISH, First In Still Here.
In the world of Structured programming the use of the unconditional branch is frowned upon. The unconditional branch is also known as a GOTO statement. Our solution to not using the GOTO statement was to great a COME FROM structure. This would add a whole new dimension to debugging code!
PL/1 is an interesting language, and to the best of my knowlege was the first to incorporate the ON ERROR block, this was a slice of code that would be run in the event of an error occurring, which in my experience was most of the time! A rethinking of the programming methodology would have the error handling routines as the mainline code, and in the event that there were no errors you could include an ON NO ERROR block. This would simplify the design process.
On a more generic note is the IF THEN ELSE structure. This should be modified to be:
IF(some condition)
Then (run this load of rubbish)
Else (run this load of rubbish)
Or Maybe Try(this load of rubbish)
This new Construct would be ideal for those pesky situations the data does not quite meet the stringent requirements of the conditions.
If you have a very large program there are usually blocks of 'Orphan' code. This is code that under no circumstances will ever be executed. This is the code that drives you crazy if you are trying to debug someone else's program. You lay awake at night trying to figure out how the hell it would ever get triggered. In order to ease the burden of fixing other peoples programs all 'orphan' code should be put in this construct:
NEVER DO
Orphan code
NEVER END
This would make debugging so much easier
No comments:
Post a Comment