Resistance is futile. You will be assimilated. (31-July-1998)
In March of 1992, Microsoft Corporation and Fox Holdings, Inc. announced a merger. Thousands, if not millions of Fox developers knew this was the end. A “merger” of Fox with the Evil Empire was like a merger of the Everglades with a ValueJet airliner: when the smoke cleared, the Everglades were still there. But this is not what happened with FoxPro. Why? Why did great big Microsoft decide to consume this little, private-held corporation from Perrysberg, Ohio. And what happened?
Microsoft bought Fox for three reasons. First, they eliminated a strong competitor in the desktop database market. Second, they purchased the opportunity to bring some of the best developers into the Microsoft fold. And finally, they purchased key technologies (and the development personnel who made them) that would prove to be key to Microsoft’s future database plans.
Why purchase a little company? Microsoft does it all the time. Many of their key products can trace their roots to development outside of Microsoft. SQL Server was originally a joint development effort with Sybase. One of the progenitors of Microsoft Word was Electric Pencil, a product from none other than the renowned FoxPro developer Les Pinter. Nearly all of the technologies in Microsoft products have come from the purchase, or “strategic partnerships” of other companies.
Why buy the opportunity to “upgrade” the Fox developers into the Microsoft fold?
“Resistance is futile. You will be assimilated.”
Five years after the merger, the Fox product line still exists as a distinct product within Microsoft. The same cannot be said of Electric Pencil. Why? Brand loyalty. Stubborn Fox developers. Overwhelmingly better technology. Innovation: Wizards and Builders. Third-party extensions: the GenX series, DBCX. The best development environment available. The ability to execute any single line of code interactively speeds development. Bottom line: no other tool will do all that FoxPro will do.
Where is Rushmore?
Rushmore is a technology for rapid retrieval of records. While the exact mechanisms underlying the technology are a trade secret of Microsoft, speculation centers on the idea that it is a highly optimized method of using binary tree (B+) indexes to perform queries, using a bitmap method to identify the records in the final record set. Where is Rushmore today?
Parts of Rushmore have been integrated into the ODBC technology.
Access claims to use some Rushmore technology.
Visual Basic, which lacks an internal data engine, and relies on Access’ Jet engine, also claims some “Rushmorization.”
Plans for SQL Server included an announcement that certain “bitmap optimization” techniques would be used to speed queries and joins. Sounds like Rushmore, doesn’t it?
Rumors abound that many of the developers who built the Rushmore engine are also responsible for the data technologies used in “Active Data Objects” or ADO.
Microsoft’s recent announcements of DNA and COM+ hinge on the use of ADO and RDO (new name?) to pass data between the layers of an n-tier model. Recordsets can be created, passed between layers, made to work as remote sets, and then re-integrated into the main tables. The techniques used sound an awful lot like the promises of offline views and remote views.
dBloat
Fox developers have been bemoaning the bloat of their language for years. Despite an effort years ago to create a standard xBase language (one that may have been doomed from the start as a political delaying tactic by some of the key players), the Fox language has expanded and expanded, with compatibility for dBASE commands, new commands and functions for object syntax, and new commands for work with views. The language is so bloated that one pundit quipped “There are three ways to do anything in FoxPro, or no way at all.” With the expansion of the language and the laudable efforts to maintain backward compatibility, many Fox developers have advocated a break with the past – dropping the “legacy” portions of the language, breaking old code in favor of a new, cleaner, more efficient FoxPro. Many have even gone as far as suggesting that the new language should get a new name as well, perhaps “Visual Data,” to let it get a clean start in an industry where many associate the xBase moniker with outdated technology.
Many problems exist with this idea. First, try to get two developers to agree on what comprises the “legacy” portion of the language. While agreement on dropping commands such as INPUT and UPDATE can be reached easily, getting any significant group to agree in total on where to place the thousands of commands and functions is a daunting task. These decisions also need to be made on the simplification of the language, especially in the area of data manipulation. Currently, data may be manipulated from the command line with LIST, DISPLAY, BROWSE, REPLACE, CALCULATE and other commands. Data can be “buffered” to memory variables with SCATTER and GATHER. Tables can be accessed directly with no buffering and “implicit” record locking, or with “explicit” record locking. Finally, the view technology introduced in Visual FoxPro introduces the use of temporary table images, cursors, where data may be sent to the data store in either record- or table-buffered modes. Support for remote views using ODBC data sources and off-line views are also added.
There are just too many options to support one clean, reliable data access method. In order to simplify the engine, compromises in flexibility need to be introduced to simplify mastery of the language and the efficiencies of the engine. Finally, support for an object-view of the data would make data manipulation consistent with the object-oriented language itself.
On the other hand, having worked with a product that allows manipulation at the table level of forms, classes and much of the internals of the language itself, Fox developers may find themselves at an advantage in master new technologies created by Microsoft. Having spent years working with metadata, manipulating data in complex patterns and working with complex programming paradigms, Fox developers are resourceful and clever at getting the machine to do what is needed. The introduction of object oriented programming in Visual FoxPro, and the exciting education in design patterns have allowed Fox programmers to work at a higher level, abstracting concepts and paradigms while still delivering state of the art applications. No other group is as well prepared to master the exciting new world that Microsoft is mapping out with DNA and COM+.
Resistance is futile. We will be assimilated. But assimilation is a two-way street. The Everglades may never be the same again. Soon we will hear:
Assimilation complete. Microsoft is ours.
Ted Roche has worked as an independent consultant, a drone in IS shops of Fortune 100 companies, and as a college professor. When he grows up, he hopes to be making an honest living, instead.
dBASE is a trademark of Borland International. Microsoft, SQL Server, Visual FoxPro, Rushmore, Access, Word are trademarks or registered trademarks of Microsoft Corporation. Microsoft is a registered trademark of Microsoft Corporation. Soon, “trademark” might be a registered trademark of Microsoft Corporation. “Resistance is futile. You will be assimilated.” © Paramount Pictures.