This page in no way represents the opinions of ANYONE except the maintainer of this web page. Well, actually, it might. But it certainly does not reflect the opinion of my current or any former employer, nor my co-workers. I know for a fact that it doesn't represent the opinion of Sue Rubin or of filePro Technologies or of STN. I may be the only person on Earth who dislikes filePro. If so, you may happily ignore this page, and bask in my foolish rant.
March 2006 update: Apparently, filePro users aren't above whitewashing the history of things. Check out the History of Wikipedia's entry on filePro. Indeed, it wasn't even ME putting the bulk of stuff in there--some guy at cox.net really ripped fpTech a new one. If you've got the time, reading the entire history is best. Particularly what the gent at 24.248.80.171 has to say. If you don't believe that I didn't enter those things, just check the netcraft history for angelar.com -- which is my gateway to the outside world. I guess I'm not the ONLY person who fails to respect filePro.
Indeed, if you're wondering why this page even exists? See my page on the people who are promoting filePro.
Here's a guy in 2002 who had come to the same conclusions that I have about filePro
filePro is a Rapid Application Development environment originally made available in the late 1970s. At the time, it was fast, relatively easy to use, and friendly to non-programmers. It is based around architectural decisions that were state-of-the-art for the period before ALGOL. That is, late 1960s, early 1970s. Even when it hit the market, filePro was out-of-date. It was acceptable for small projects, but was nowhere near as flexible as a true relational database.
filePro is a DBMS, not a relational database. This is what defines a relational database. Alternately, check out the MBA-friendly summary.
It is still available. I have to spend a good part of my time developing in it. But it is one of the more nightmarish development environments available. It has a built-in proprietary "database" structure based on b-tree file formats. It has a tiny core of dedicated developers, similar to Amiga-philes, who refuse to acknowledge that technology has moved on.
Some people have Good Things to say about filepro. I'm not one of them.
a succinct summary of why filePro is a bad 4GL
UPDATE: Apparently the company which develops filepro FPTech, Inc. doesn't deal well with dissenting opinion. You'll notice that on this page, there is no mention of my former employer by name. Nowhere in ANY of my webpages is there any mention of that company's name (hereafter known as $COMPANY). That's not something everyone needs to know. Sue Rubin of FP Technologies, however, took it upon herself to send a little note to $COMPANY, suggesting that if we're having problems with it, perhaps we can settle this in a private venue. Note that even though my email address is clearly shown at the bottom of this page (and can be gathered from a "whois" on my domain name), she never bothered trying to contact me. I believe that she wanted $COMPANY to order me to take this page down. As you can see from the email in question, she even referred to us as valued customers. Well, that wasn't the impression I got from the condescending attitude of their chief programmer, on the mailing list. I stand by my opinion: filePro is the very definition of a legacy system. It is, by design, incapable of allowing best-practices development. Implementing new systems in filePro is akin to implementing new systems in PL/I.
In filePro, any piece of code can modify any table in the database. There is no way to prevent this from happening, nor any way to track (short of grepping through all the files) to see which pieces of code are hooking into each table
Until recently, it didn't even store it's 'processing tables' in clear text, but rather in an obfuscated binary format. This means with legacy applications, you have to recompile the code to even use grep on it.
Furthermore, code use is strictly cut-n-paste. There is no logical way to reference code in such a way that arguments can be passed. Code is divided among several files, which are executed at different times, and are associated with specific tables. There is no concept of a while loop, and all the code is inherently dependent on using "goto", which is an incredibly bad idea.
Since it's not really possible to do a genuine join in FP, you end up creating an "index". There are up to 10 "demand" indexes, and 16 automatic indexes. Essentially, this is a saved View. However, indexes are stored such that if an operation is cancelled while creating one, the index is entirely destroyed--along with all data on what records were in the index, how it was sorted, and whatnot. This means that every filepro programmer must have a separate system for keeping track of all indexes, sort orders, and which records should be selected for each.
Would you believe that every line begins with an implied "if" and is followed by an implied "then"? Yet, there is no concept of an 'else' or 'elsif' or 'case'. Frankly, shell scripting offers better control structures and maintainability than does filepro.
The filepro applications all run setuid 'filepro', which is...well, suboptimal. A better approach would be to have them run setgid, and make sure that all users who can run the app are in the filepro group. This would allow for much better integration with CVS. Basically, if you aren't using the official FP editors and whatnot, you have to set the code/screen/menu files to be world-readable. This is an odd DOS-like model for an application which runs on so many flavors of Unix.
data constraints: filePro cannot enforce a simple "NOT NULL" clause at the table level--it has to be done in code, in every SINGLE PIECE OF CODE which can reference the table in question.
Scoping is mostly a myth, and due to the nature of code, is arcane. There are local and global variables. Variables can be defined at their first use, unless you'd like them to have names longer than 2 characters. In that case, you have to define them specially. Processing (their word for code) is broken into several pieces: input processing, (which is executed in various forms every time a record is entered), automatic processing (which is executed every time a record is accessed) and output processing (which is executed once for each selected record, when you're trying to output data to a report). This sounds simple, and my description is. It is, however, incomplete, because there are many modifiers on what happens when the user leaves a specific numbered (or named with a 1- or 2-character alphabetical name) field, or when they enter such field. Other exceptions exist, and there is also the concept of "sort/select processing", which is executed to select specific records for an output format. Back to scoping: variables defined in the automatic table are automatically available in the input and output processing table, even if they are not marked global. There is no way to define variables specific to a subroutine. One CAN put subroutines in a separate file, but there is no easy linking system, such as one finds with C and make, or Perl, or Python.
fields in a table can be named, but cannot be referenced by name--only by column number, basically. Here's a short comparison of perl and filepro.
There is a marked lack of open-source tools to use with filepro. I consider this a major disadvantage. Furthermore, there is a single printed book on filepro (with a price tag of $160), and the vendor has stopped shipping manuals with the product. I know of one instance where a company paid $6000 to upgrade from version 4.5 to version 5.0 (required because 4.5 was no longer supported, and the company was changing operating systems), and they received not a single printed manual. What they received was a jewel case, with stickers showing the registration codes for the development and runtime versions.
screens are limited to 80x24, with really only 20 rows useable. This is regardless of screen resolution or window size. Bought a 19" monitor, and you're running it at 1600x1200? Good news! You can fit MULTIPLE filepro windows on it--but you won't be maximizing any of them to any advantage. The color scheme is also apparently hardcoded, and uses some ugly, ugly colors. Particularly when using xterminals on Linux, this can be less than flattering. When using putty, one can simply redefine the ANSI colors to be something else. I'm open to suggestions on how to do this with Cygwin's xterm, btw.
On this page, I will list off tools and tips which are helping me to link to filepro where necessary, and eliminate it where possible.
As of the writing of this page, filepro was at version 5.0.15. Unless, of course, you're a customer of eData Technologies, who are claiming to be using Version 6--and this was their claim long BEFORE version 5.6 of filePro came out. I bet some other fptech customers would have liked to get their hands on that. If you look at the FP Tech user testimonials, you'll notice something interesting--almost all the testimonials are from people running one-man consulting shops. This is telling--because filePro is VERY difficult to use in a shared-development environment. Note that the company didn't put out a single press release between 9/11/2003 and 4/8/2005 -- 19 months! Does that sound like a forward moving company to you?
This is a particularly cogent argument against 4GLs. Also, Tim Bray has an excellent definition of 4GL, and he is quite right when he says the last 10% of the project is simply incompleteable. Also, this CIO Update article rails against 4GLs, quite rightfully so.
In short, filePro is not a good choice for a development environment. In comparison to modern programming languages like ALGOL, it is non-supportable. It is cryptic, highly obfuscated, and doesn't play nice with CVS. It stores data in the same directory as code. Even bad C code is more straightforward than filePro. It strikes me as similar to the 4GLs I've used in the past (touchtalk/write1 comes to mind), which save _some_ effort, but in the long run are more expensive and complex than traditional languages. If you're thinking of developing a proprietary language: Don't. Build a library to Python or perl. Your users will thank you. Your technical staff will thank you.
It may seem counterintuitive, but IT systems age. So when you're buying trucks for your company every year, give a thought to your venerable back-end systems. IT systems do not last forever. Read this excellent cautionary tale of neglected IT Infrastructure.
Don't think for a minute, however, that I think you should get a shiny batch of new Windows 2003 servers. You need to analyze what your company really needs, find out what kind of support you can get for various software. When someone proposes moving in a given direction, take a look at whether or not you can get people trained in this. Fortran may be a fine language, but you'll be hard pressed to find an expert these days!
Furthermore, if you have a lone voice declaring the inherent value of PHP+MySQL, but you cannot find a PHP+MySQL programmer anywhere, do you think adopting it would be such a wise move? My biggest argument for moving away from filePro is this: To how many filePro programmers do you have access? If you've got one programmer, and potential hires are shying away from your company because of the arcane technology you're using... Well, I'll let you connect the dots on that one.
Comments, kudos and death threats to: