Filepro spaghetti

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.

6 comments

More Articles by Anthony Lawrence - Find me on Google+

Click here to add your comments




Mon Jan 14 17:05:35 2008:   anonymous


I work for a company that still uses Filepro and nothing else. You are very kind in your remarks about Filepro code. It is worse then you can imagine. We have processing tables that are over 3,000 lines, talk about hard to follow. What gets me is people still think this program can do anything/everything yet we can't seem to do anything and keep adding programs on top of it to make it print properly etc. It's horrible! I don't know why people keep saying it's fast. My experience shows it to be much slower than say MySql. I am also amazed that so many people build such large tables 348 fields. Why? I thought we were the only one's who did that. I guess it's because it's so hard to display information from other tables/databases in Filepro. Also hard to due lookups correctly. It just amazes me anyone still uses this broken down program. It hasn't changed much since the Tandy days.



Mon Jan 14 22:06:44 2008:   TonyLawrence


No, you are not unusual.. I've seen a LOT of Filepro code and most all of it is really, really bad.

It is fast though.. in spite of all that..



Wed Jan 16 16:17:14 2008:   BigDumbDInosaur
http://bcstechnology.net

I haven't looked at FilePro in at least 15 years. Frankly, I never liked it for a variety of reasons and sure wouldn't relish having to work with it now. In the late 1980s, I switched all my RAD work to Thoroughbred, which had (still has) far more functionaility and power. I can't imagine any reason at this point in time intentionally using FilePro as a development tool. It is still pretty crude, in my opinion.



Wed Jan 16 22:07:49 2008:   TonyLawrence


You won't get any argument from me!



Tue Feb 5 15:39:04 2008:   anonymous


It's nice to know I'm not alone here. I think the reason people still use this program is because they're afraid to change. Pretty crude is a nice way to put it. I use it every day and I still believe that it has severe problems with floating point numbers or any number for that matter. If you want your computer system to be the way computers were 30 years ago then FilePro is for you. My company wants this so bad they are willing to spend hundreds of thousands of dollars for new equipment just to run FilePro. And yet they can't figure out why their reports never match and they can't do this or they can't do that. Just amazing. Thanks guys for making me not feel alone in a world where people think FilePro is the best program ever written.





Fri Feb 8 15:32:01 2008:   BigDumbDInosaur
http://bcstechnology.net

My company wants this so bad they are willing to spend hundreds of thousands of dollars for new equipment just to run FilePro.

Switch 'em to Thoroughbred Dictionary-IV. Far more powerful, math works right, much better support for modern page printers, more structured environment, good screen-driver support, etc. Since going with Thoroughbred in the late 1980s I've never looked back at File Pro.

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.