Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFPConversion Seminar - May 9-10 - Dallas, TX
Message
From
13/04/2005 01:14:13
Walter Meester
HoogkarspelNetherlands
 
 
General information
Forum:
Visual FoxPro
Category:
Conferences & events
Miscellaneous
Thread ID:
01002513
Message ID:
01004047
Views:
43
Hi Martin,

>Even more, have anyone tried to write a refactoring tool for VFP? I did, but having no strong typing, it is close to impossible (not to mention marco substitution).

Can you give an example ?

>In general, any kind of tools that needs to build proper parse trees is defeated by the absence of strong typing (and I'm not talking about basic -or value- types, but to custom types, where the real power of strong tyiping shines). Any kind of static analysis is almost impossible to do in such conditions. If you used ReSharper for C#, you know the power of having a tool than can really understand what you're coding. This is not possible without strong typing.

There is always a tradeoff. But don't forget that though a weakly type language compiler does not care about its type it does not neccesarely mean that you're not allowed to specify the type of a variable or property to aid development, just like vfp does for intellisense. Also, don't forget that many of VFPs native object properties types are static. A controlsource is always character. Some however are dynamic ones like the value property. However would you not agree that the power of databinding of VFP has something to do with the dynamic typing of the value property ?

The problem with static typing is that some constructs are way more complex to realize with static typing than with dynamic typing. In dynamic typed languages I could far more easily build up and iterate through relation of object of different types. In static typed languages you always have to workarround the consequences of strong typing (like overloading, virtual functions/classes (in C/C++)) to keep the compile happy. This adds more complexity to those environments where you're dealing with complex object types. A good example in this is smalltalk. It is far more proficient to deal with complex systems in smalltalk than in any other static typed language. I suggest you google a bit on "static typing" "Dynamic typing" and you'll get some interesting reading food.


>Finally, I don't think there is any tendency to go against strong typing at all. Python doesn't seem like a good example to me. The main researchers in programming languages (see Robert Harper, Frank Pfenning, Derek Dreyer, Umut Acar, Adam Chlipala, et al) are even pushing type systems for low-level languages, as the compilers intermmediate languages before going to machine code). So I can't agree that strong typing is neither an error nor a fad.

In low level languages you have more of an argument to use static typing, just because of performance reasons (why else are you programming in a low level environment??). 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 ?

Anyways, I feel that the advantages of static and dynamic typed languages should be combined. This inherently means that static typed language should have a runtime type checker and there would be EASY way to tell the compile that he has to skip type checking when specified.

Walter,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform