Hi, Walter.

>First of all. Thanks for your interesting in depth analisys....

Thank you also. Forgive me if I'm shortening my responses, but I have some time constrains.

>I don't mean that. I mean that a routine can be used by more than one unrelated (object) types, like for example:

I understand what you mean, but for me, that violates OOD principles. Indeed, typing is one of its tenets, and that's why strong typing is so important to me. Types convey a lot of information, and provide for the necesary abstraction. In your example, you're being explicit instead of polymorphic.

>>For example, when you write unit tests (if you do Test-Driven Development, you do this ALL the time) in VFP you have to take i consideration to add some tests for type safety, while you don't need to do that in Java or C#. In fact, if you have the good practice of asserting the parameters you receive, in VFP you usually write a lot of assertions to check for the proper types, while in the other cases you just assert ranges.
>
>See argument above. I don't believe for dynamic typed language this is much of an issue. Typing issues will be detected whether or not you add typing checks.

In a strongly typed language you don't need to write tests to check for argument types or return types. In VFP proper Unit Tests requires you to check for parameters (indeed, you should check that the code reacts properly to invalid parameters passing) and return values.

>>Absolutely agree. This is something that you really miss when you start using other languages. Being jumping from side to side, I allways "tried" to shield myself to stick to much to some very specific mechanisms. I know dynamic code is nice to have, but when you don't have it, you always find other ways to get the same result.
>
>I've seen this argument a lot, esspecially from .NET-ers. However I object to that one. If you'll have to jump through hoops to reach the same as in another language, this is clearly a disadvantages of that language.

Well, for you is jumping through hoops, for people who never had that features it is just normal code. Anyway, it doesn't have to do with typing, so we can leave this out of the debate.

>>Well, if you make your compiler smart enough to tell you that you have the wrong type, you made it strong typed! 8-D
>
>No. Static typed languages will prevent you from compiling at all. It also has only very limited means of doing runtime typechecking. The two are fundementally different in implementation.

I don't like warnings very much. Even when working in C++, my take is that you have to have a clean compilation. No warnings at all. If you have a warning, theres is something that "can" go wrong.

>No, I'm trying to tell you that a dynamic typed language does not neccesarly have a performance disadvantage to static typed languages as long as the dynamic typed language is specialized on the task.

I don't have performance concerns. I agree in that performance is not something that should govern development. Performance is something that you have to take care first from an architectural stand-point, and then from an optimizing stand-point, not all the time in the middle. My main concerns are clear design and safety.

>>Well, this is a problem of impedance that trascends -IMHO- this debate. Once again, I'm and OO developer, and form me data access and domain logic are different problems, and mixing them produce a lot of troubles that I don't want to have, no matter if this is VFP or Java.
>
>Sorry I can't see this. Applications are about algortithm AND data, so you'll have to deal with both. This is still the area we (as developers) are strugling with. This is why the OO database was invented. However the OO database never made it because of inherent problems. There is not something universal as a OO SQL or even, on a lower level, an OO alternative integrating to the relational model.

Well, for me, application is about domain logic. How your domain model persists is another question. So you see, we have quite different basics.

>>>As one having no programming experience in .NET, it seems that when retrieving and assigning values to fields in the table static typing is not looking at the type which is bound to a particular field at all (again I might be mistaken here).
>>
>>You can mix both things in .NET, the same as in VFP, but I won't recommend to do it in neither case.
>
>??? what do you mean ???

I mean you can have data access scattered and tangled with your domain logic, or you can have it properly isolated, in VFP, Java, .NET, and any other decent platform. For me, again, the domain model is what I care about, and the back-end is something I have to take in consideration from an architectural standpoint, but not while I go ahead in the development. I think we are more data-centric.

>Why not?? If dynamic typed languages do not enforce type checking at compile time, it could be a solution interconnection systems. The compiler might not know what types get returned, but the developer might know.

Again, except if you're developing middleware, I don't care so much about all that interoperation, except where I define those interfaces. Once I did, I put them behind an internal interface and then I don't care much about the details. I don't want my main logic to be dealing with different system intrincancies everywhere.

>>And of course I see any good debate as useful. I guess this is one of the higher values of these forums.
>
>As long as we don't take up the guns :) ....

Bang, bang! ;-)

I guess our arguments have all been exposed enough. No one of us could (or need to) win this debate. I guess we have different approaches and concerns about application development, and both sides are valid.

Best regards,