My wife calls me a pessimist, so I find it odd to be so optimistic about this, but here's my stream of consciousness thoughts on this:
-There are still Cobol applications running some fairly large companies (though I couldn't tell you what the numbers are nor who the companies are, but I've read about it many times).. -Because of this, my concern for lack of official MS support for VFP is not that high as clearly, "dead" languages can still survive and be useful long after they die, especially since many consider Fox dead already for several years. -VFP pretty much does everything I need it to, and it's amazing extensibility means I can add (myself or via the amazing VFP community) what few missing features are needed as they arise. -Clients will surely be concerned by this announcement until I explain what it would cost to re-do their applications in something else. -I'll probably manage 'ok' just on supporting the current numerous vfp related applications I've been supporting and improving over the last 10 years as so many resources have already been spent by the client that there's little justification to spend 5-10x more just to move to something "newer". My client's all value ROI over the latest 'technology fads', and it's why we get along so well, as I do to. -The only hitch in this concept is MS and their ability to force clients to run newer versions of Windows (by aligning with vendors to get it pre-installed), which could mean that eventually these existing VFP apps could eventually stop performing well, or at all, through no fault of mine or the clients, other than the fact they needed new computers. -To answer this however, virtualization can make this a moot point, and I think it could be possible through virtualization to have existing customers running Win2K or XP for the next 20 years for the purposes of running their VFP apps to which they've invested so much $ on. -Thus the question to me really is, what should "new applications" be developed with.. to which I ask the question as follows: a) What is gained by moving to a new platform? b) How robust are the development tools? c) How fast can the applications be written? d) How do the applications written compare to current VFP abilities e) How stable are these new tools and the environments they run? f) What's to prevent the new platform, or more importantly the current 'favorite' tools from being 'dead' in a few years? g) What features or reasons are so apparent that I simply cannot justify continuing to code in VFP? The bottom line, in my mind, to really summarize this is: Can I write an application as fast as and as good as anything I can do in VFP today? Well of course not, there's a learning curve, and of course, picking the toolset I will dedicate to achieving this 'benchmark'. So the follow up question is then, if I decide on a toolset, and I commit to learning it, and I loose $ in the short term while becoming proficient at this toolset, will it in the long run pay off? I cannot see the answer to be yes: too many variables, too many new toolsets, too many bugs in the toolsets, too many changes in technology keep occuring. Therefore for me, I think what makes the most sense is to continue to use the strengths of VFP and my proficiency with it, to provide "new applications" based on a browser interface hitting a 3rd party SQL database such as mysql or other equivalents. By eliminating the 'fat client' element, I am cutting ties to Microsoft (with the sole exception of having 1 windows box as the server which could be hosted virtually on a non-windows box), and by eliminating the DBF and MSSQL ties, I am virtually free of MS. Thus the client's can all be running linux boxes to run the app, and have almost eliminated MS from the mix. The downside to this is that the web interface still pales to a rich fat client experience like VFP, but with AJAX and other technologies that gap is closing fast, and in a few years should be a non-issue. Some may already say it's a non-issue. If / when the day comes, that the "new application" written in VFP providing a web based experience can be written 'better & faster' in a different tool, I can then migrate that application and be free of MS all together, *if* that's something my clients demand, and something that we can justify financially, ie, what's the benefit? Some may argue those tools already exist, and perhaps they do, but choosing the right one, and spending years to become as proficient in them as I am in VFP, just doesn't make sense to me, and I can't see my clients paying for me to do this, just so they can get rid of their 1 MS box running IIS in cases where they've already migrated to the Web based app. To clients who are still in a fat client setup (most of mine still), the harder question becomes, is it worth the move at all, and that's something I can't really answer, because 'today' the application suits their needs, and they've already invested the $ for it. To charge them more to move to the web needs to have a clear and well defined cost benefit to them for the future, and I've yet to really see that in the short term. By limiting myself to VFP, I realize that I am closing myself to potential 'new customers' whose sole concern is the toolset I use to deliver their solution, but I maintain that going with newer technology is probably just as risky, perhaps more so, and in many cases, probably costs just as much if not more to implement. This area of course, is the hardest to quantify.. I am of course, always looking and evaluating new toolsets and technologies to find that killer replacement for VFP, and if I see it, I will surely devote all my resources to replacing VFP with it, but I've been watching for 5 years now, and have not really seen it yet.. Could it be Dabo? I'll keep watching and evaluating it and others as they mature. Dabo's strength IMO, is that the guy writing it, knows how great VFP is and is most likely using that as a benchmark. Well, those are my thoughts as they apply to my situation, but everyone's situation is surely unique... -Steve _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
