I found a good article on what makes a good 4GL. Read that article, and then I'll explain why filePro is a bad 4GL.

1. filePro's definition is not independent of hardware or operating system. In fact, it is known to behave differently on MS Windows than on various versions of unix. In fact, code must often be altered to migrate between platforms--and this is after you've purchased the extra licenses to move it in the first place.
2. filePro's definition is standardized, but hidden, so it is impossible to tell if the compiler on a given platform fully complies with the standard.
3. filePro does not support software engineering technology, it does not prohibit nor discourage poor practices, and doesn't really help in maintenance. It doesn't integrate with source-control systems, it bundles data and code into the same directories, and it cannot pass arguments to subroutines. Furthermore, it has no provisions for anything approaching object orientation.
4. filePro does support the application domain of interest: it is a rapid way to do simple "database" queries, though it lacks the features of a real database.
5. does filePro support the required level of system reliability and safety? Some errors are handled only at runtime, but this is generally a feature of bad programming.
6. filePro's compiler implementations are nowhere near the current state of technology. See point #3.
7. filePro's development environment has not changed in 20 years. In the editor window, one can view exactly 6 statements, and there is no provision for code indenting. Ugly. One cannot resize the code window to dimensions other than 24x80, and colors are fixed.