>>I think you missed the point. Typing anything just for the sake of keeping the compiler happy should be considered unproductive. Whether we are talking about datasets, com objects or whatever. It certainly has its place when seeking for performance and is a great benefit in certain debugging scenarios, but otoh its a pain if the tools ask the poor programmer something that the tool should be able to figure out itself.
>>
>
>Walter, there is no arguing with the fact that typing is a human, not an electronic, artifact.
>Way down deep, everything digital has only one type.. and has one of two possible values- zero or one.
>So, yes, you are right.. any other typing is an artificial concept whose value is open to question.
>Any language that I've seen that deals with anything other than zeroes or one is typed in one way or another.
>
>Consider this VFP code:
>

>a = "A"
>b = 1
>c= a+b
>

>which crashes.
>In the first language I learned, IBM 705III assembler, the answer in c would have been "B."
>When you think about it, there's no logical reason that the bits comprising the byte holding 1 can't be added to the bits comprising the byte holding "A."
>It's just binary math.
>With XBase and similar languages, however, the authors decided to protect us from ourselves by assuming that it's probably a mistake if a programmer is adding a number to a string. That annoyed me at first, but over time I benefitted a lot more from that restriction than it cost me because it uncovered some serious bugs that would have caused me a lot of grief had they gone undetected.
>So, in that respect, VFP is a lot more strongly typed than IBM705III assembler was.
>Should we go back to IBM705III assembler?
>I don't think so.

I think we need to get our definitions straight.
Strong typed: you cannot compute incompatable typed variables
Static/Strict typed: The compiler checks whether types are compatible at compile time

Weak typed is what you described above: adding numeric to a character variable.
Dynamic typed or duck typing: is when you do not have to declare variables and/or can change typed during the lifetime of such variable.

So, C and assembly are weakly typed, though C is strict typed as well. VFP is strong, but dynamically typed. C# and VB.NET are (mostly) strict typed.

Anyways, my clash is with languages that require scrict typing for keeping the compiler happy. That in itself does not have anything to do with intellisense. As you know VFP also has intellisense (though inferiour to .NET) and though it allows you type your variables, it won't object when you do not and does not give you headaches when you need to find a mechanism to bypass the strictness of the compiler.

A good example is the need of using the "visitors" design pattern to overcome the problems related to static typing. One would not use the visitors pattern in dynamically typed languages because there is not need to. The compiler does not object directly calling the neccesary object method, and it won't bump at runtime.

Another example is to support multiple versions of COM objects, suchs a MS office. With static typed languages you'll have to jump to hoops to implement that. In C# previous to version 4, you'd had use reflection. Now it has more support for dynamic typing. That is good.

In the end is about using types where it makes sense, and using dynamic types where it makes sense. But no-one should be forced to use strict typing for the sole purpose of keeping the compiler happy. That is the only reason that we ended up with more design patterns that actually needed.


>Here's another point to consider:
>Members of my generation came of age before PC's became ubiquitous, so we are generally lousy typists.
>Intellisense in VS saves me HOURS each day by auto-completing long operands that I'd surely have misspelt because of lousy typing skills, faulty memory or both.
>Intellisense can only do what it does because of strong typing.
>I LOVE IT!!!!