>>>Yesterday in a meeting with a new face at a Client's office he said "FoxPro is the software no one uses any more". Fortunately someone else remarked that the main purpose of the software was to get the job done and that it was doing the job very well.
>>>
>>>You all must have come across this situation. What answers have you given and what software have Clients suggested as being better than VFP and for what reasons?
>>
>>I usually tell them that Microsoft is simply not creating new versions anymore. Unfortunately they forgot to create a vaiable alternative to the strengths of VFP. Therefore we wait for the next wave of new technology (in regards to dynamic types languages) as we don't see the current strict type .NET languages as a viable alternative.
>>
>
>What do you have against strong typing? It catches many bugs early.

VFP is strong typed... just not strict typed.

I do not have anything against strict typing as long as it is optional. Ideally a dynamic language has the option of using strict typing in order to produce better code. And it should not be catched at compile time only, but at edit time or file save time. Compile is too late anyways IMO.

I do have an axe to grind with strict typed languages as you tend to write much more code and always seem to spend an awfull lot of time to deal with the implications of strict typed languages. Even look at very simple programs. How much of your code really is code that actually DOES anything and how much of your code is there to keep the compiler happy.

Simple stuff is easy, but it becomes a lot more difficult if you're going beyond that. For example, Implementing design patterns is a lot more work and more difficult than in dynamic languages. Even the GoF (Gang of Four) who did introduce design patterns to the mass is critisized ("palatives to C") that their book is dealing with a lot of stuff that deals with the implications of strict typing. Some design patterns do not even exist in dynamic typed languages as they are implemented in one or very few commands that come with the language.

There are a lot of problems that strict typed languages have to deal with and most of them require considerable amount of code (by casting into types) to deal with them or require additional components that are not neccesary with dynamic type languages. For example:

If your dealing with database access, you either have to tell the compiler what to expect as a result (type wise) or you have to cast everything into a type before you can access the values in the resultset. The first solution is a problem if you can't predict what the resultset is going to look like, the second is just plain more work and distracts you from the real meat.

If you're dealing with 3rd party COM components (for example MS office) you either have to bind to an explicit versions typelib or again have to cast everything if you don't know or do not care what version of the COM is present on the clients machine.

A question to ask yourself: Why are relational databases (Like SQL server and Oracle) dynamically typed? Why is SQL dynamically typed? Aside from having to declare variables explcitely, it does not require you to type the resultset in advance and most errors are catched at runtime rather than compile time.