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.