Your point on DP and strict typing: right on. I came across this quote used by Alex Martelli (anyone for whom Korzybski is a favorite author has my attention) in a DP class given at Google (and available in video):

many "classic" DP (for C++ or Java) are
"workarounds against static typing" (cfr:
Alpert, Brown, Woolf, "The DPs Smalltalk
Companion", Addison-Wesley DP Series)

Hank

>>>>>>>>>You know I respect your opinion and expertise. But I honestly don't get the distaste for strong typing (not limited to you). IMO it protects me from bugs before they happen.
>>>>>>>>
>>>>>>>>Yeah, but at the same time you end about half the code for keeping the compiler happy. You also have to buy into all kinds of techniques that are not neccesary in dynamic languages (take ORM, or early binding com interfaces), reflection etc.
>>>>>>>>
>>>>>>>>I just don't want to keep telling irrelevant stuff (for me) about the type of variables I'm going to use. If I want to do a SELECT * FROM WhatEverTable, I just wan't to use thaw result without going through casting, typed resultsets etc.
>>>>>>>>
>>>>>>>>I want to concentrate on solving a business problem, not concentrate on telling the compiler what it could figure out at runtime.
>>>>>>>
>>>>>>>But that's the point. The runtime can't necessarily figure it out.
>>>>>>
>>>>>>A dynamic language can. A static typed language cannot.
>>>>>>
>>>>>>>The compiler already had its chance and may have let some glaring errors through.
>>>>>>
>>>>>>Yeah.... but there technically is not anything that prevents dynamic languages to have type checking at compile time. I think VFP.Net was about that too. If you wish to use static typing for the purpose of catching errors at compile time and performance, you could, but it does not force you into having to use it where it just makes more sense to trust the developer on getting the types right and only raise an error at runtime if its not.
>>>>>
>>>>>No, nothing prevents it. Some languages do that kind of error checking, some don't.
>>>>>
>>>>>I don't always get the types right. Maybe you are a better developer than me.
>>>>
>>>>Thats exactly my point, After having programmed in C/C++, Pascal, all strict typed languages, FoxPro and VFP were such a relief.... no silly error messages anymore because I got the type wrong. No jumping through hoops like using virtual classed to keep the compiler happy. And more recently a lot less needing certain design patterns to work arround type checking.
>>>>
>>>>I've got a question for you, maybe you can answer it for me.
>>>>How do you handle late binding to COM objects? for example: If you want to open any version (> version office 96) of MS word to do a mailmerge, do you still have to work extensively with casting?
>>>>
>>>>How would you compare using late bound COM objects in strict typed languages compared to dynamic typed languages.
>>>>
>>>
>>>I have no expertise with late bound COM objects. Sorry.
>>>
>>>This phrase intrigued me in your reply: "no silly error messages anymore because I got the type wrong." Uh, would you rather not know? Or you really, really enjoy debugging runtime errors? <g>
>>
>>No I do not, but not every type issue results in an error.
>>the problem is not so much with basic types like integers and characters, but more with class types.
>>
>>Since the compiler insists on knowing the class types, you always have to make sure that you declare or cast it to the right class type or its parentclass. And this is a PITA in many cases. I'm sure you used to have a factory in VFP, that can be written in code with lets say 30 lines of code and a metadata table, very straightforward. In strict typed language this can become awfully complicated as at every step you need to tell the compiler the type of object you are creating. In VFP you just do a
>>

oObject = CREATEOBJECT(cMyClass)

>>and really be done with it. Further in your code you can access each and every property and method YOU know should be there without having to go through hoops of giving the compiler means of checking it will always be there.
>
>I'm not really following your logic on this. In .NET you could equally do:

>object oObject = new cMyClass();

and, since you postulate later knowing what methods are available that implies that you know the actual class so what's wrong with something like:

int i = ((cMyClass)oObject).MyInt;

? But more to the point - what have you gained by casting it as object in the first place ?
>
>This is the reason that design patterns in strict typed languages are more extensive than in dynamic languages. Some designpatterns do not even exist in dynamic languages because they are all about resolving issues that have to do with strict typing. Others are an order of magnitude easier to implement in dynamic languages.