>As I mentioned there's no requirement for typed languages for doing anything. Nothing about OO or any other language really requires the typings per se. But they let the compiler help you find trivial issues that are otherwise harder to track down. There's no reason that you should have to have code fail for a type in a var name, but if you don't have a typed language there's no compiler to help you with that for example.

First of all, lets get the terminology right.
Strong vs Weak typed languages: The requirement that when opering on variables they have to be of the same (super)type.
VFP is a mostly strong type language: You cannot add a string to a number. It will generate an error (Exception: add numbers to a date or datetime)
C is weakly typed as I could add or compare an number to a char, add ints to longs, etc.

Dynamic vs Static typed languages.
The neccesity to declare your variables to be of a certain type and compile time checking whether the variable does not operate outside of the boundaries of this type.
VB.NET/C++ are static typed language (appart for certain provisions of dynamic typing)
VFP is dynamically typed as VFP won't check the lifetime of a variable to check whether you're doing anything illegal with it

That does not have to be that way. There is nothing to prevent a dynamically typed language to check or otherways assist on such things. VFP is not a static typed language, but you still can declare your variables and you still get intellisense on that and if we would have seen a VFP 10, we might have seen such aid in VFP as well (John Kozoil, expressed that they were looking into this arena).

I do not want to go over the arguments of the ancient EDI again, but compile time checking, or even better, checking while you type, is not an exclusive property to strict typed languages.

My main gripes with static typed languages is that a significant amout of your code is about keeping the compiler happy and in some ways is making things hard.
For example if you look at certain design patterns, a significant number of them is about resolving typing issues, which do not exist in dynamically typed issues.
(before I get flames on that argument, which happened before, first read this http://www.norvig.com/design-patterns/)

Another problem is using COM objects where with static typing you're bound to a specific version of the COM object.
It takes me only a few lines of code to open and print a document from MS word, supporting from Word97 to Word2013.

Those languages are harder to learn, esspecially for people who are programming as a sidejob outside of their profession.

Note, that this is not about .NET vs VFP, this is about dynamic typing vs static typing.

>As I said - it's a choice.

Indeed.

>
>+++ Rick ---
>
>>>Whether you use a statically typed language or a dynamic is a choice. The best choices IMHO tend to be hybrid languages that support both.
>>>
>>>Personally, I prefer typed languages because they do offer better support for tooling - refactoring, Intellisense, rule based code validation are much easier to implement for tool vendors if you have a type system and language engine in place. There's nothing amateurish about this BTW. These are professional tools, that if you've only used VFP to compare against, you probably can't even imagine.
>>>
>>>If it's easier for tool vendors they will build those tools, otherwise - not so much. You often see that co-relation when you compare the tooling between statically typed languages and dynamic languages. It's possible to do similar tooling for dynamic languages but it's a heck of a lot harder and often inaccurate. A good case in point are the various JavaScript environments that existed in the pre-Typescript days that would often give iffy results because they had to guess where you had to manually provide hints to the system to do what a typed system can automatically figure out because of the typed metadata.
>>
>>I guess those tools do help a lot, but OTOH I'll keep a grain of doubt - some of these tools may be needed precisely because of the type restrictions and help resolve them. Since I don't really need any of that (my other languages are js and minimal bits of SQL), I declare myself a non-expert on the matter.
>>
>>What I had in mind is the situation where, for example, http://beginnersbook.com/2013/03/polymorphism-in-java/ defines overloading of methods just as something you have to do in a typed language - a different version of a method for each applicable set of parameter types. Or all the examples of class factories where you had to create a separate factory for each set of classes, because the class name has to be compiled and can't be ad-hoc taken from external code etc. So I guess many things are done differently because they have to, and I'm not convinced that each of those is better and makes for a more productive work.