Thomas,

Those are all real good points and I agree 100% with the sentiment of existing code value. In most situations I've worked, rewrites have been a tough sell and took a long time to provide any return on investment. OTOH, the companies involved in the process did feel they eventually got their value from these migrations and are now much better positioned to move forward in the future.

But there comes a time when hard choices have to be made. We should be thankful that we actually have a number of choices that can be reasonably made that don't totally obsolete existing FoxPro code. From continuing on with VFP 9 as is to using COM Interop.


The implication I resent (sorry) from many in the VFP community that they were abandoned and don't have choices. There are plenty of choices out there. Frankly I think a number of folks here are plain old lazy and do not have the motivation to learn ANYTHING new (and it doesn't have to be .NET for that matter, but could be Python, Java, PHP or whatever). A lot of wasted energy has gone into the 'hand wringing' that brought up this topic in the first place.

I can relate to that, believe me as can many others that are now doing other things besides VFP - I've spent a long time struggling with getting a grip on .NET as I would have trying to go with anything else. But ultimately that effort paid off in becoming familiar with new technology (whatever it is) and making it do the things that *I need it to do*, not the other way around.

Some people seem to forget that it's not the technology that's driving development, but ingenuity, experience and skill of *people*. Let's not forget that crucial aspect of the 'developer' before we cling with the claw of death to a development tool that is after all only a tool...


+++ Rick ---





>Hi Rick
>>But again if you look at your existing investment of code that code isn't dead. It can continue to run and it can be accessed externally.
>
>>And if it really comes down to leveraging existing FoxPro code - you can also still do that via COM. Just about from anywhere is your FoxPro code accessible if you really can't live without it although I'll be the first to admit that this is suboptimal...
>
>Code often gets reworked, sometimes with regular budgets well into 6 or lower 7 digit sums - and I am definatly more often arguing against a complete rewrite. Working code has *much* more worth than coding costs alone - the cost of pure development ranges between .15 and .25 on seven digit projects. But planning to rework applications where it is *uncertain* how well their runtime works in the post-Vista windows versions is definatly getting more complicated. While I do believe vfp will run as a 32 bit app even a purely technical risk assesment is difficult, and most of these discussions are not entirely<g> based on technical arguements.
>
>Even if factoring maintainance cost to be higher on "legacy" systems I almost always can deliver much more bang for the buck by working off the existing codebase: something like 2/3 of the intended functionality at 10% of the cost and at least half of the increase in maintainance cost due to "legacy weakness" eliminated. Variations can be expected due to existing code quality as well as number and level of coworkers on the project<bg>.
>
>As the ETec compiler is currently not finished and I have not tested tools for automatic conversion from vfp to .net this is hypothetical, but I would prefer a vfp/.Net compiler to an automatic conversion given they had similar levels of robustness, language coverage and so on.
>
>The elimination of J# and Delphi's uncertain future definitely gives more weight to the arguments against "JAL". But a hungry small company might produce something making business sense to use - even including bleeding edges we are currently better protected against as MS *is* well established.
>
>Creating single layer apps in a vfp alone is not best practice in my book, and doing so again in a new vfp/.net compiler by a small company would be even less. But such a compiler could give interesting and worthwhile refactoring options - even if the bulk of the app is still kept in the vfp-syntax.
>
>And yes, much much hinges for me on the implementation of the table layer *and* the possibility to work from the command window - even down to having Ironpython as noted fallback option. But that also is partly influenced by my current main gig and a large dose of personal preference.
>
>I guess there is more than even chance that ETec can produce some biz value for me and also more than even chance any conversion tool does the same for a large conversion task. In my personal opinion the chances of resurrecting MS-vfp/open sourcing the runtimes and all the other currently very active topics are practically zero: why not put at least the "flame energy" into something more constructive ?
>
>my 0.02 EUR
>
>thomas