VFP is what you make it :)

Goed gesproken.

Marc


>Hi jess,
>
>>>The future of VFP doesn't depend on whether or not it partipates in the CLR. From my POV, it would be a gross mistake to make VFP a CLR compliant language. The mindset of some people is that "everyting belongs on the Internet/Intranet".
>
>>Who said it is? .NET CLR is not only internet/intranet thing because there is WINFORMS.
>
>What are the most heard arguments to make VFP CLR compliant ? I think that is the .NET framework with the mindset of applications on the internet, or at least thin client software. Winforms on itself IMO is not any reason to move to CLR in any case.
>
>>>In truth this sort of thinking returns us to the days of "Big Iron". The fundamental reason that PCs rose to such popularity is the fact that they put power into the hands of the users.
>
>>In think the case of software development is way way different in the case of PCs. How can users will continously using VFP when it is not futuristic:
>
>George means that .NET is great for applications that live on the internet or are at least thin client. I agree that this is a mistake for a lot of applications, because you're making the client more dependent on the back-end. In case of many services on the back-end, you'll end up a gigantic backend with bad performance if there are many users attached to it. With fat clients the application requires more resources from the client PC, but potentially with far more power because each client has its own CPU and resources to forfill the tasks.
>
>In any way, I don't think users 'choose' for VFP. 'Users' choose for
>applications that are written in VFP. Most of my clients don't even know their application is written in VFP. In many cases, VFP is the most suitable solution for building these applications.
>
>>technology wise? It can still compete today but how about tomorrow or in the near future? Not to underestimate the role of users here but I think it is the totality of the product itself (its competitiveness) plus marketing that make it successful.
>
>Marketing aside, which is aimed at developers, not the users (clients) of the endproduct, Users (clients) always will have certain demands. VFP has to evolve to be able to forfill these demands. As long as it will be capable of doing this, I see no problem or whatsoever. From the point we stand now (with VFP 7), I don't see a problem for the next few years. The weakest point maybe its GUI, not the language itself. As longs as the front-end GUI looks modern, you can hide an awfull lot of outdated internal technology.
>
>To be honest, In these respect I don't see the CLR giving us any advantage. As you'll have heard a dosen times before I guess, it will turn VFP into some VB variant. When this happens, VFP loses its advantages over the other .NET languages, which will lead to a quick dead of VFP.
>
>
>Walter,