Whither Visual FoxPro? (Part 2: Back to VFP's Future)

In Part 1: No Rush, I looked at why it makes sense (if one values productivity) to stay with VFP, making an orderly transition to the Next Something prior to 2015.  In this entry, I look at exciting developments that paint a bright future of that Next Something.

The .Net platform is built around the Common Language Infrastructure (CLI).  The CLI was built (initially) for languages that declare types prior to usage, and that check for type before compiling.  This pretty much ruled out VFP, which is a dynamic language.  (The distinction between static and dynamic languages is the subject of much discussion: but strong typing by the compiler is a major element in any discussion.)

In a marketing coup (which is to say, the developer community believed them for at least 3 years), Microsoft asserted that strong typing would make coding more efficient.  This was so obvious, no support for this assertion was given.  Under strong typing, everything was a given type, which had to be known by the compiler before compilation happened, or else an error would occur in compilation.  Never mind that with a dynamic language (VFP, Python, Ruby, for 3 examples), the unit testing one has to do in any language will reveal any typing issues; and never mind that strong typing creates a straight-jacket for coding (so MANY lines of code, so much more complexity, to handle so few instances where confusion might occur) and for testing (as we sing yet again, "off to work we go, compiling is so slow..."). 

Now, strong typing has been around for a while, so one has to wonder why there are any dynamic language users left (and in fact, more of them than strongly typed language users).  And one would have to wonder why some of the fastest growing organizations (Yahoo, Google) use dynamic languages where they can (one ordinarily doesn't want to develop operating systems using dynamic languages, Twisted aside).  But one doesn't get one's options in any large company for loudly asserting that "what we have right now is just great, don't change it!"  One makes one's bones by decrying the past in lofty conceptual tones, with the requisite sniff -- "poor chaps, stuck in last decade's technology" -- and a properly timed rise of the eyeballs -- "can you imagine not having access to the 4,000, oh, make that 8,000, classes we will be providing?"

So it was with great interest I have observed the rise of dynamic languages within .Net, beginning with the "research project," now grown into the Dynamic Language Runtime program,  in which Jim Hugunin ported Python into IronPython.  An historical aside: I was assured by a program manager at Microsoft that IronPython would always remain a research project.  This is a very smart someone who should have known better: they really drink the kool-aid in Redmond!

Which brings us back to VFP.  Two projects exist in which VFP is being ported to .Net by independent developers.  Each takes a different approach, and I for one am appreciative of this, for entirely pragmatic reasons.  The two projects are the VFP .Net Compiler of eTecnologia, and the Guineu .Net FoxPro Runtime.  The VFP .Net Compiler takes a VFP project and compiles it to .Net, while Guineu compiles already-compiled VFP code.  Neither project is done yet: expect 1-2 years for full compatibility for the VFP .Net Compiler (although it could be sooner), while the developer of Guineu (which is Catalan for Fox) says it will take several years.  You can try each of the products out (check their web sites), and a few of us old-timers have created a user support community for the VFP .Net Compiler.

Time to completion aside (and as Part 1 explained, there is No Rush), what is important is that it is being done.  The Guineu project, notice, provides political cover for the eTecnologia project: Guineu takes compiled VFP code, which is the full property of the person holding the rights to the product, not Microsoft.  So even if Microsoft objects to the VFP .Net compiler taking raw code files (which theoretically, but not practically, could be produced by other-than-VFP-IDE means), it could not prevent the Guineu project from going forward.  And if one project is going to go forward, there would be little point in blocking the other.  Even if they could: remember how Fox got its start?  Are you old enough to remember dBase?

Now, it would be nice to have access to the nice variety of .Net controls provided by Infragistics, DevExpress, Telerik and so forth, in these VFP .Net programs, wouldn't it?  The issue isn't getting them to run: it is already possible to run any .Net control in any VFP form using eTecnologia's VFP .Net Extender.  The issue really is the Integrated Development Environment, where one designs these little wonders.  Enter VFP Studio, being built by two other VFP developers on the Visual Studio isolated shell.   In case you don't follow VSX (Visual Studio eXtensibility) news,  Microsoft has made the shell of Visual Studio available for the development of 3rd-party products, at no cost.  How long before this gets integrated with the VFP .Net Compiler, do you think?  The projected delivery date for VFP Studio can be found here. (Notice the image: it is both the Phoenix rising and, as seen from above, a Fox face.  Very cool!)  In a current events aside: the evangelist for the VSX team is a former VFP program manager, himself responsible for some of the most important add-ons to the VFP IDE.

As I see it, VFP will be fully present on .Net in some form within 2 years, and perhaps as little as a year.  Even if the present developers were to disappear from the face of the earth, there is so much momentum that others would take their place.  My best guess is that it will be integrated into the Visual Studio IDE, taking advantage of the best of both worlds.  Our back up position (work with StrataFrame and MM.Net) is not a bad one at all.  I will be surprised, however, if we have to take it.

Whither Visual FoxPro? (Part 1: No Rush)

Although some folks might think I picked the wrong homonym (think: wither <s>), I have more optimism about the future of VFP now than I have had since the original announcement (before Visual Studio .Net was first released in 2002).  That might seem strange, given Microsoft's announcement on March 13, 2007, that Service Pack 2 of VFP9 (released October 11, 2007) would be the end of the line for VFP.

If you are asking why anyone would care whether VFP lived or died (and clearly, the powers-that-be in Microsoft cared only to kill it, having done their best in that regard for the 13 years they have owned the product), the answer is very simple: for those of us who produce complex, rapidly changing and expanding software products in the business arena for our livelihood, nothing approaches its power and elegance in getting the job done. 

I need to give you some idea what is being discussed here, because I am not talking about the little 20- or 40-table sample applications used to tout .Net, because those applications could be written in anything.  By way of contrast, and not to brag because we are far from perfect, we got a 200+ table to market in less than 2 years, with an average of 4 full-time developers.  That application now has 400+ tables, 600+ custom views, etc.  And we've never had more than 4 developers at a time working on the application, with each of us having other duties as well.  With a lot of groundwork, to be sure, we are converting the application to SQL Server, which has taken 1 full-time equivalent person about 3 months (it is now in final testing).

What has made all this possible is VFP.  Not any one thing, but all the little things that have been the result of fine-tuning a language and development environment for 20+ years.  And true, we use a very good VFP development framework, and we've built our own modifications to that framework, and have a tool to integrate the most efficient and extensible data modeling tool with that framework, etc.  But all of this was possible because VFP made it possible.  For example, the data modeling tool keeps its data in xBase tables, directly accessible from VFP.

So that, you see, is why we aren't in a rush to leave VFP for an environment that has still not (based on multiple sources of information including private discussions with product managers at Microsoft) reached its potential in the development, or data usage, arenas, and will not have reached it in VS2008, either.  There are in fact some folks at Microsoft who know what good is (because they came from the VFP team from back in the early Fox  years), and that knowledge is (slowly) making its way into the .Net environment.  I am told that the version after VS2008 will pretty much have everything that is able to be moved over.  One can hope.

In the meantime, there is no rush.  Support for VFP will be available until 1/13/2015.  Those development houses or ISV's extending past January 12, 2010, should purchase extended hotfix support: while security issues will be addressed until 2015, non-security issues will be addressed only if extended hotfix support has been purchased.  That said, the former VFP team members have indicated that they will make themselves available for critical issues as they arise.

So, there is no rush; there is time to plan.  In Part 2, I will look at exciting developments in the VFP .Net (yes, that's right) arena.  If you've read this blog before, you've read of our plans to port over to MM.Net and more recently, StataFrame, both being VFP-inspired .Net frameworks (based on subclassing rather than code generation).  And, in fact, these frameworks are only getting better: not just more mature, but also more sophisticated.  However, a change in focus within .Net, both the IDE and the language, has opened the doors to new and exciting possibilities, and that is what I'll look at in Part 2: Back to VFP's Future.

Getting Started: A Great Example To Follow

I came across this great example of how to introduce complex technology to someone who hasn't yet been there, and done that.  This is from the Intuit Developer Network page on integrating with the new Quickbooks Merchant Services.  I don't know if the Quickbooks Merchant Services are good or bad: I do know that developers have, courtesy of this Getting Started visual guide, a clear path to implementation. 

 

In addition, each of the containers leads to a tutorial of its own, with live interfaces such as an emulator presented directly within the tutorial.

A Network World columnist commented a couple of weeks ago on computing's "dirty little secret:" it's hard.  Doing something as simple as getting a firewall to protect your personal computer without disrupting what you want to do with the computer is hard for the average person.  To that I would add, introducing oneself as a developer to new technology is hard, for the average developer.  The bar has been raised, however, for those providing developer tools.  Good work, Intuit!