Why FoxPro?

Sometimes I enthuse about FoxPro and readers wonder why. Is it just the resonance with George Fox, our fearless leader (circa 1600s) of Friends?

Actually, for me, that is part of its appeal.

Yet FoxPro is strong in other respects, as a descendent of xBase for example, a language originating at CalTech's Jet Propulsion Lab (JPL), and spinning off into the commercial sector as Ashton- Tate's dBase II.

FoxPro grew up as an implementor of the defacto xBase standard, and has this whole client side way of manipulating database records that's non-SQL, more procedural.

Now, a lot of products bundle some rather primitive programming language, often named PL, with their SQL, but FoxPro's solution is different.

Visual FoxPro is a complete GUI IDE, like Visual Studio, and comes with its own back end, even if you don't have an SQL engine like Oracle's handy.

In any case, I was an xBase programmer, mostly for Portland area nonprofit and government sector agencies, long before I got into Python. The original DOS-based FoxPro was gobbled up by Microsoft, which migrated it to the Windows platform as FoxPro for Windows (FPW).

Then came a more complete overhaul, as Microsoft blackboxed some of the more speed-critical objects such as Forms, and fleshed out a large dictionary of methods and attributes.

We didn't lose our ability to write embedded SQL, plus gained new powers to send SQL dialect down the ODBC pipeline, getting back cursors developed server-side, and now returned to our VFP client for further processing, and perhaps GUI display within some grid object.

Probably my admiration for VFP over say Microsoft Access, is the underlying superiority of xBase for database work (for which it was specifically designed), over anything derived from BASIC, a hodge-podge to begin with.