The
Data EngineDoes Your Development Platform Do This?
I use Microsoft's Visual FoxPro as my development platform. I've programmed in a number of languages and development interfaces. All things being equal, I like FORTH the best. It never quite made the leap to a database programming platform. Second best, and there isn't any third, I like Visual FoxPro. This is not a theoretical or conceptual choice: it's purely practical. Here is a list of the practical reasons I prefer using Visual FoxPro. They may not be important to you, and I am not saying they should be. Take the development platform you like the most, and, pretending you were me, see how happy I would be in your favorite platform.
My important reasons (and they don't have to be yours):
The Openness of the Development Environment
Frameworks, frameworks, frameworks
Do you have a reaction? Send it along, and I'll publish those that do the best job of shooting me down. <s>
FoxPro's data engine is fast. It is also large: each table can be 2Gig. Contrast that with the Jet max database size of 2Gig. Those who have done the testing report that VFP is twice as fast as SQL Server except when the number of users becomes seriously large (> 50 - 75). It's not that I can't program against client-server backends: I've used VFP with client-server since the VFP3 beta. But I do love speed. <s>
From the Command Window I can, while in the debugger at a breakpoint, or when I am just doing nothing, execute any FoxPro command. I can obtain an object reference for an object at design time, and interactively build and test a builder. That's partly what I liked about FORTH: I could toss stuff on the stack and test my "words" interactively. I can only imagine the loss of productivity if I worked in a development platform which didn't have this ability.
FoxPro's debugger got better with VFP5. It is a pretty standard debugger with breakpoints, logging, etc. And of course when it breaks, I can hit the Command Window and work in the program environment as it exists at the time of the break. This is serious debugging ability. The only capability I miss is on-the-fly corrections, as SuperCede has. Heck, maybe Tahoe (VFP6, due ca. 7/1/98) will have it.
I look at newsgroups of other languages, such as Clarion or SuperCede, now and then. I see discussions on "how do I turn the mouse off" and "how do I know if there a disk in the drive?" In VFP5 the answers are SET MOUSE OFF and DISKSPACE(<drive>) = -1. I have to program a little thingy in VB, or now VBA, and the DO CASE in VB drives me nuts: it is the old Basic version where the object of comparison stays the same. In VFP each branch of the DO CASE is independent. I don't like straightjackets (which is of course why I liked FORTH: you make your own language <g>). Sure, you get to shoot yourself in the foot (if you're lucky it's the foot <s>): I guess that's some of the difference between having a hobby and a profession, being able to use complex features wisely.
Openness of Development Environment
All Classes, Forms, and Menus in VFP are stored in the basic currency of xBase languages, the .DBF table. In fact, the Database Container itself is stored in a .DBF. The Almighty certainly meant for data to be stored in .DBF's. And Classes, Forms, Menus, and DataBase containers are simply different forms of information. Need to change the parent class for a class? It can be done in the Class Browser (itself written in VFP). But if you moved a Class Library and things are really messed up, you can open the Class Library as a .DBF and fix things yourself. Ever have a GUID of an ActiveX control changed on you? It doesn't happen much anymore, but it's happened to me. In most languages this would require going into every project and changing the GUID (unless you had it in a global #include file). I copied the new Ole memofield from a form I dropped the new control on, into the Ole memofield of the general subclass of the OleControl, and all was fixed. Did I tell you I hate straightjackets? Well, I love this kind of openness with equal intensity.
I don't know who the genius was who figured out that the same format used to store forms in FoxPro could be used for Class Libraries. I've always figured it was Dr. Dave (Fulton, who is responsible for the genesis of FoxPro, and many of its features). Anyway, somehow "they" managed to give FoxPro real Object Oriented Programming in 1995. VB and Access still do not have Object-Oriented Programming. My son the IT major, who generally knows more about these things than I, got this one wrong. Yes, I can write an ActiveX class in VB. But I can't sub-class in the language itself. What does this mean practically? Take a really neat control like dbi-tech's new ctList control. I have it sub-classed to read an .INI file, save it's information in a MemoField (a single command in VFP: did I mention that this language has range? <s>), restore its information, etc. I wouldn't dream of using an ActiveX control I haven't subclassed. But if I used VB or Access I'd have to dream, because neither language can do what I do almost daily in VFP. In addition to ActiveX controls, the application frameworks on which real VFP applications are built are themselves classes and sub-classes. There's a reason Booch's Object-oriented Design and Analysis with Applications (Benjamin/Cummings, 1994) is a popular book: this is how you get solid programs out the door.
Other languages have adopted them since; but it's still nice to have VFP's reasonably seamless Local Views, Remote Views, and Offline Views. VFP is sparing of backend connections, in addition. I include in this topic Datasessions, which allow each instantiation of a form to have a separate, buffered copy of a given set of tables and/or views. Like ADO? The cursorset code came from VFP, courtesy of the same programming team that first wrote the VFP code.
When I work in VFP5, I have a choice of 6 applications frameworks. Six! What do I mean by an application framework? I mean, minimally, a set of classes which create an API against which I program, instead of programming against the language. This is how one builds stable product without 6 months of beta testing: by using a framework used by hundreds or thousands of other developers. These frameworks differ in their extent: some have builders, wizards, their own data dictionary or extensions to the VFP data dictionary, their own referential integrity engine, or extensions to the VFP RI engine. These products are all written in VFP by the way. Product written directly against code better be written by one of about 20 real wiz VFP developers. The alternative is for it to be written on a stable framework. I'm not among the 20, so… I've seen "code generators" for other languages. But that's not the same, is it? All the VFP frameworks are written in VFP classes and come with source code.
Microsoft has been called the "Evil Empire." Gosh knows I'm ticked at them for not realizing the quality of VFP contrasted with their other products. I understand that product managers have to fight for budget and that number of boxes is pretty much the Gold Standard, so I guess there isn't much place for quality. That said, VFP has the virtue of adhering to, or at least moving in the direction of adhering to, Microsoft standards with regard to how it interacts with the Operating System, most importantly, and with regard to how it looks, less importantly. The OS compatibility includes COM and DCOM, which is to say, how VFP gets along with other objects. You think all the languages do? Tell that to Access developers who have gone through 3 versions of ActiveX controls (and are finally on the real thing). Tell that to Delphi developers who have to hope that the visual ActiveX control they want to use will have a workaround to deal with Delphi's not registering child objects of containers at instantiation (hey -- makes it quicker if you don't have to do that, and Delphi chooses quickness over compatibility). Getting along with other programs/objects if really important. VFP5 could be better; presumably, VFP6 will be better.
In December of 1990 I started monitoring FoxForum on Compuserve (when I began, it had not yet spun off to its own forum). What I noticed was developers helping developers. And I mean the top developers, the ones whose books and articles I read. Cool. Serious cool. And that continues to today. On the MS newsgroup (nntp://MSNews.Microsoft.com/public/FoxProgrammersExchange); on Compuserve's VFOX; and on the Universal Thread (http://www.universalthread.com). Each of the 3 has its own personality, and is worth using as a source of information. There are other user communities on newsgroups now, and so this is not quite the issue it once was.
In Summary
I wonder, at times like this when I am focusing on VFP from outside, rather than using it, how it came to possess such quality. Some of it certainly is that xBase has been around for a while, and has always been pragmatic rather than theoretical: it was designed to solve problems. The early user community made a difference: brilliant people like Russ Freeland and Tom Rettig. Every language has had its brilliant stars, but somehow the presence of a community transformed this brilliance into changes in the product. In the times before Microsoft bought FoxPro, changes would be made in the product itself right through the beta process. We, on the hidden Compuserve forum used for the beta, would argue for changes, in order to make the product significantly better, and many times change would occur. There was an emphasis on quality, starting at the top, and that emphasis was infectious. Now, of course, it is more important to be a good corporate Team Player than to insist on quality; but that's OK, because the die was cast for FoxPro during its childhood and adolescence, and the adult VFP carries within it the fruit of that beneficent upbringing. Will I ever switch? Absolutely: the moment there is a better development platform.
Back to Hank's Programming Page
