Hi Al,
while I think I can almost agree totally
>
>1. A "compatible" product is created.
>1a. Commercial product. etecnologia's offerings, and guineu from Christof.
>
>1b. Open-source product... BDFL ... there are clearly some "firsts among equals" but I'm not sure the community would be willing or able to appoint a BDFL.
I'ld probably formulate that more cynical.
>2. VFP users migrate to other products. ... Sometimes, that isn't VFP in its current form.
>
>Finally, as a corollary to 2 above, I'd argue that it actually isn't imperative that the core product evolve. It can be left as a niche product in its current (if possibly shrinking) market, while new projects move on to something else. An interesting, and timely parallel is the current conflict between Microsoft and Mozilla over JavaScript:
http://developers.slashdot.org/article.pl?sid=07/11/02/1748244Here I follow the argument of the corollary, but for me that translates as: I am hard pressed to argue for any new *commercial app* dev in vfp. There are special cases (vfp based shops drawing on their accumulated expirience, enhancements/new modules to existing apps reusing other parts) but even for connecting vfp to other software I now sometimes create a large part of the wrapping in the other language. Much of that might change if either commercial approach of running vfp in .Net was really painless. Simple truth: using Etec's approach I'ld probably code in vfp and if really needed translate the compile back into another language. After 2 or 3 cycles I'ld KNOW what to watch out for and would adapt my writing style. Using cursors as *part* of an array of local data structures instead of the swiss army knife used for hash tables also would feel better<bg>. Breaking the *dependancy* on vfp as the language is accomplished to a greater degree by that approach IMHO, but I'll watch Christoph's session in a few days on german DEVCON very carefully<g>.
Also much of my hesitation stems from the non-evolution of the base table layer. When I started with the dBase file format, 2 Gig HD's were SF. During the heydays of FoxPro each part of the table (dbf, cdx, fpt) could be as large as the largest [Fat16, not counting Foxpro for Unix] partition. Then came Fat32: ok, tables could only be half the size of the maximum table size - not really a show stopper. Then I moved to 64-Bit file system in NTFS with NT4 and vfp's table layer (even as intermediate cursor between C/S databases) suddenly morphed into a very gifted half-toy (consciously left half crippled<g>) - you can get real work done with "toys", but for some tasks you are just not fit or have to add at least more effort. Remember arguing that Access might be good enough for a record collection, but even there Foxpro might be better, as nearly the same effort gives you relatively unlimited data sizes ? We switched from having Oktoberfest bier steins for drinking tiny tequila shots to drinking tiny sips with tequila tumblers from a very large beer tank.
Disclaimer: I get called sometimes when "normal" vfp cannot continue, so I might have a distorted view of current problems, as I see more special cases. I might be off to a degree, but not in the trend.
regards
thomas
