Yesterday I wrote a review of a programming style book ("Implementation Patterns" by Kent Beck). Right now I'm reading a book about Xen and another on Web site performance optimization, and will have reviews soon, so we'll be moving away from programming for a bit.
But before we leave, I wanted to mention a bit of Filepro work I did yesterday. If you have no idea what Filepro is (no, it's not Filemaker), the Wikipedia entry will give you the basics, but what that doesn't tell you is how darn popular it was on Xenix systems. There was a lot of Filepro written in the 80's; I did a lot myself. As Wikipedia tells us, it was a "RAD" (Rapid Application Development) system, and I don't think the word "rapid" was ever more justified than it was there. You really could hack out useful apps in literally minutes.
However: the downside of Filepro was its weak programming language. When I first used it (1983, beta version on Tandy Xenix) it didn't even have gosub and it had severe problems with floating point numbers..and although it did get better and more powerful, its "if:then" base and extremely limited namespace for variables made for a lot of difficult and confused code. Some folks would even have worse to say, and I would not disagree. "Filepro programming" barely deserves the name.
But just the same, a lot of useful apps were developed (actually, I think "cobbled up" might be a better choice) in Filepro. Some of them still run today, and every now and then I get called to change something. That was the case yesterday. I've mentioned this before; usually these people don't want much.. the app has been working for years and changes aren't frequent. But the change they wanted yesterday looked a bit more difficult..
Remember, I didn't write this code. I'm not even going to complain about the person who did write it, because I have no idea what version of Filepro he or she started with - they may have done the best possible with what they had to work with at that time. Just the same, the code is a mess. Envision 900 lines of code like this:
If field 142 ="Y" then goto abc If field 153 ="" and field 6="M" then field 144= field 147 * field 17; if field 153="Y" and field 144 > "17" then field 153="N";aa="0";dg="15" if field 153="N" and field 144 <= 17 then af="13"; goto def
That's not actual Filepro code; believe it or not I made it easier to read! Want to know what field 142 actually is? Look it up. There are 348 fields in this database, six related databases each with field counts from a few to hundreds.. any time one of those is referenced, it's by number. Variables? Those are the "aa" and "dg" - two character names, not exactly descriptive. In later versions you could use longer names, but they were mapped to those two character names, so you were still limited and also had to be very careful not to overwrite your namespace.. bad, bad stuff.
So anyway, the change they wanted affected a total field. Under some conditions, they wanted it to include a field that was otherwise stated separately. But oh, my, the conditions. This field was set and reset in dozens of places in the code, and sometimes it would jump around sets based on some other field.. I couldn't follow it and wasn't about to rewrite 900 lines of code.
So, I took the cheap way out. At the end of the processing, I put in a "gosub" to a block of new code that tested for their conditions, reset things when appropriate, and then returned. It means that there are wasted tests and sets earlier in the code, but on the other hand if they come across conditions where this should not happen, I can quickly fix it in that subroutine. If I started messing with the earlier code, I could break all kinds of things.
I was thinking that our brains work the same way. We have "old code" (our so-called "reptilian brain") that new code (our conscious brain) overrules. Rewriting the old stuff probably would have broken it, so evolution just added on a new gosub.
I don't think my solution is "good code". It isn't. The "right" way to do this is to take the time to understand the whole process and rewrite (and probably not in Filepro!). But that way would involve weeks of work, maybe even months. It would be very expensive, and neither I nor the customer have any interest in doing that. The current system works, and we can keep hacking at it as needed.
Long live Filepro..
If you have an old app and need a Filepro programmer, I can help.
Got something to add? Send me email.
More Articles by Anthony Lawrence © 2012-07-12 Anthony Lawrence
Much to the surprise of the builders of the first digital computers, programs written for them usually did not work. (Rodney Brooks)