Hi thomas,

>even if I am with you on more than a few of your single arguments, I arrive at different conclusions <g>.

I've read the things below and could not figure out in what way your conclusions differ from mine ....

>>When doing high level development (Which database application development tends to be) the game is much different. Ultimate control and (non specific)Performance is not such high requirement up here.
>>
>>What is the reason that early database product like dBase, Clipper, VFP were so successfull ?
>
>Besides the ease of high level development the speed in the intended target area is quite important. If you look at the differences in the various scripting languages (to define dynamically typed languages in another way) you see the IMHO abhorrent PHP to be nearly everywhere at the bottom but excelling at the string concatenation necessary for HTML-building. Python running quite good everywhere but excelling at list/tupel working [one of the reasons I guess python might be even better than vfp to integrate into .Net: the programming paradigm is nearer to the .Net way of things] and vfp excelling at data handling by virtue of the integrated data engine and being not too shabby in the string department as well.
>
>Or to characterize vfp performance from a more negative point of view: the performance of vfp compared to other languages [especially non-scripting/statically typed languages] is mostly lousy. But since the bottleneck of data access is less tight in vfp, the sub par performance of object creation, function call overhead and so on has virtually no consequence to the perceived performance of the user [in the typical datahandling business app] done in vfp. And security [IMHO the worst drawback of using dbf-tables as persistant data store in most LAN situations] was not an issue in the early nineties.
>
>Having a well rounded development package with easy databinding and interpreted testing ability still can give us an edge in many scenarios.
>
>>Anyways, I feel that the advantages of static and dynamic typed languages should be combined.

>You haven't exactly specified your idea "combined"

Just read a few messages back, I've tried to explain more than once what I mean by that: In short: bring some of the advantages of static typed languages into dynamically typed language, by enahncing the IDE to aid the develloper to identify typing mistakes or mistakes in types, without lossing the flexibility of the nature of dynamic typing.

>, but to be honest, I think a dynamically typed language with a good interface to a statically typed language and a good developer going "native" in very few necessary routines will run rings around "halfbreed" languages even with a developer of similar class. Which happens to be the combination of fox with c/c++ which drew me to it in 2.0 (machines were less capable by far those days...) and is true for most scripting languages as well. I'ld rather have a race horse and a jumping horse instead of using a farming horse for both occasions ;-)

Sure, each language has its merits. And for performance reasons, static typed languages will be the way to go for a long time IMO. And you're right, I've used C/C++ on more than one occasion to do something that is not possible or terribly slow.

However, advancing dynamically typed languages to gain some of the advantages of static typed, you technically don't lose any power at all, because a lot of that is only playing a part at design time (intellisense, online type checking, etc) and has no effect on runtime.

Walter,