The Future of FoxQuill

Version: 1.11.01 - last update: Saturday, April 30, 2011, 02:10:00

 

---

FoxQuill will become FoxQuill.NET

VFP’s Future

Visual FoxPro will not die abruptly – neither tomorrow, nor next week! There is enough work left to be done for smart and experienced VFP developers – okay, maybe with additional programming language skills. I am sure, migrating VFP/XBase based legacy-systems to C# or any other language will become a pretty remarkable line of business in the future.

The Future of FoxQuill

Microsoft’s initial release of the NET framework was on 13. February 2002. During the past decade countless books were written touching almost every NET-related aspect. Why should one think about doing another one? Well, first of all, I think this is a universal question, which also is true for other businesses: “Why should we build another new type of car? Don’t we have enough to choose from?” I believe, one possible answer is: “As long as we can make something better, we should go for it!” Another good answer: “As long as we can re-sharpen something to become more precise, we should do that, too!”

But there is more to mediate on! Lately, I read Jeff Jarvis’ book What would Google Do? I do recommend reading it! Amongst many other things, I learned that the Internet brought a big change in the global market: Yesterday we had some (few) big companies; earning big bucks was only possible for these mainstream players. Today, with the help of the internet, there are much more small-sized companies. Specialization is the buss word today! Do not try to capture all potential customers in your country, but only a small group that you’ve tailored your perfect fitting offer for. With the help of the internet, your customer base will be multiplied for sure. Now, the whole world has become your country!
My strategy is to niche a market with FoxQuill.Net in a special way. The experience I’ve made learning C# on the .NET platform, I will publish as an open-source book. In addition, I will publish parts of FoxQuill also as an open-source project. I just started to add and refactor some of my old FoxQuill classes. My intention is to make them “look and feel” more like their counterparts in my C#-based FoxQuill.Net version. An effort that will pay back when finally migrating to the .Net platform one fine day. Finally, FoxQuill.Net will be an open-source project as well! I would never presume to create a 100% compatible VFP.NET clone (see below). When Microsoft buried VB6 and published VB.NET they must have had good reasons not to recreate a 100% backwards compatible VB.Net version!

Good Starting Points

Most VFP developers seriously interested in the .NET platform know about the Visual FoxPro Toolkit for .NET. I believe, a closer look at it gives you a good starting point. But, it is not my intention to trample down that trail again. I believe, that most of the authors of .NET books first learned C#, or VB.NET thoroughly and gained experience while working with Visual Studio. They all started writing after they have been there, done it, got the T-shirts :-) I will start now, immediately writing about what I am learning. Even better, writing about what I am missing and what is hard to understand, because there is counterpart within VFP. The best way to learn C#/VB.NET seen from my VFP-biased point of view surely differs from the mainstream. Voilà: there the niche is :-) 

VFP.NET the Unborn ‘Flatliner’

Lately I followed a thread on Google groups  VFP.Net Compiler Community Support Group. In a nutshell: There is (or was?) a company named  eTecnologia. They sell (or sold?)  a Net Extender for VFP. This tool was intended to be a VFP wrapper that lets us access all the cool .NET functionality flawlessly. But the wrapper was very instable and thus, almost good for nothing! Next they told us, that pretty soon they would come up with a VFP Developer Studio – a complete VFP 9 port to the .NET platform! Still it is not much more than an alpha version, even today (April 2011). 
IMOH: Today, no small (even no mid-sized) company is able to allow itself the luxury of doing a full-featured (100% compatible) VFP 9 to VFP.NET port! Maybe they might be able to implement 95% of VFP’s overall functionality in the first half of their “migration-game”. But, for the remaining 5% of VFP’s functionality ( – believe me –) they will need much more than a second half!

FoxQuill.Net Another Unborn Successor

The future of Visual FoxPro, better the spirit of VFP, must no longer be controlled by bigger brothers. Today, it is possible to form developer teams loosely coupled worldwide from small herds to large swarms :-) Today, we are able to create a new VFP.NET implementation by our joint efforts from scratch. The outcome may not be the real thing compared to VFP 9, but it will definitely be an enhanced development environment that re-enables us to write bullet-proof, stable running, paramount apps for modern operation systems in the shortest possible time! We must not waist our money on compatibility issues! Let’s learn from the past, but do not lose time to repeat it unsuccessfully! Of course, backward compatibility is a “nice to have”-feature, especially if one owes a lot of old sources written in VFP, or even in FPW (or even better in FoxPro for DOS/MAC/UNIX :-) 
Most cardinal errors made in the past stem from how program logic was implemented! The logic (the coded behavior) of a program was bound to the programming language much too tight. Every time you have to rewrite parts (or all) of your code during migration, you encounter this flaw. Look at good old macro substitution for example which is a very VFP/XBase - specific feature. Doing an automated port of a PRG that is heavily using macro substitution to C#  is next to impossible!

Revert Backward Compatibility to Forward Compatibility!

Let us face some of the troubles a Tomorrow VFP Developer may ran into:

• Microsoft stopped supporting and maintaining VFP.
• VFP will no longer be compatible with Win 8, 9 or 10.
• No raising generation of VFP developers any more.
• Tons of NET programmers with neither XBase knowledge, nor any sympathy.
• Many companies wish to upsize/migrate their legacy VFP systems to .NET (but only for little fees, please!)
• Missing migration tools will hinder you, because you are to expensive!

The business landscape described above is closer than one might think! A .NET developer always advises any CEO during an in-depth consultation to migrate to the .NET language that meet his skills! No .NET developer would phone you up and ask for you assistance because of your prominent VFP skills – never ever! At the utmost, they may need your expertise during migration of their VFP tables. Upsizing dbf content to any kind of SQL Server instance might spawn subtle errors, as we know! The rest of the plot is very simple: all legacy VFP source code gets dropped. A complete rewrite will be done, because with some very clever NET tools this can be realized very fast and very cheap by someone with less .NET-skills than yours!
Now, how could we revert compatibility to always point forward to our latest, most powerful implementations? The answer is astonishingly simple: We have to GENERATE all of our source code by using a program and not by hacking in each line manually! Code that was generated by a machine can be maintained by a machine as well. Automatic maintenance finally leads to computer-based upgrading, upsizing and, if necessary, migration. All we have to do is decouple user interface design and program logic definition from the process of creating the corresponding source code. Look at Microsoft’s WPF and you know what I mean when I’m taking about decoupling the user interface design. This technology is already there! Decoupling program logic (the entire application behavior) from generating the corresponding source code can be realized in almost the same way. Believe me!
Using my (future:-) FoxQuill.Net development system, resembles the way we create internet pages in an WYSIWYG editor, today. Yes, it still will be possible to manually write and add source code, but that’s generally not necessary in 95% of all business cases. Even my so called ‘micro-workflows’ can easily be assembled by selecting the appropriate building blocks from context sensitive lists. Dropping them on a design form afterwards and finally arrange/configure them is all that has to be done. I like to point you to Google’s App Inventor for Android where you can watch some short YouTube demos and tutorials. Especially the blocks editor user interface looks very promising (see below)!

Google still is some development-miles away from having the perfect App generator, but we all know that they will have one in the near future :-)
GUI layout, workflows, messaging, data-storage, -manipulation and -transport, as well as event-handling and system configuration; all these things are aspects that can be configured using universal XML-based schemas. Any FoxQuill.NET editor (just like Google’s Block-Editor shown above partially) emits XML-based data which belongs to the additional abstraction/separation layer I mentioned earlier in this post. Thus, what we are creating during our future development with FoxQuill.NET is neither .NET’s IL code, nor C#/VB.NET source code, but XML files representing a concrete DESIGN; e.g. some GUI layout, or a process workflow, maybe an inter-object messaging specification, or some storage structure definition, or a details system configuration definition, to name only a few possibilities.

Pros & Cons

At the beginning, as long as adequate tools are rare, there is less interactivity compared to VFP. VFP’s command window is a very unique and useful feature, for example. Such pervasive interactivity normally requires an interpretative language driving the system like Python.  Luckily, there are much more Pros than Cons!
Every XML output generated by a designer can be preprocessed and/or redirected before the target generator starts it’s code generation. This enables dynamic workflows: we will be able to enhance/add, modify or delete parts of the XML data on the fly based on external conditions. Another big plus is, that the designer tools themselves will be able to pre-check the user-input. With these client-site validations enabled (available only in a local workstation mode) it is possible to catch potential errors at a very early state (still in the designer), which helps to eliminate unnecessary development round-trips.
The XML files generated by the different designers can be interchanged over the internet. The generation site can be a remote one. Thus, someone may build some very specialized  generator, or a much better version than the original one provided by FoxQuill.NET. The developer of such a super-generator tool then may publish the availability of her advanced functionality so that the community knows about it. After that, she can offer access to the (remote) service for free, or associated with a certain pricing plan. Because a generation service outputs text files only (e.g. C# source code), such a distributed remote source code generation is secure and can be packed and encrypted in addition.

<to be continued…>

---