Hi Walter,

>This might be the biggest mistake in history. Strong typing as you mean here (there is much to say about the definitions) is going to lose popularity in the near future. Modern languages like Python show you why. Strong typing was a good idea in the old days where ultimate speed by efficient use of datatype mappings were essential and compile time checking was most welcome, but today this rule does not apply to most applications anymore. In fact I'd call strong typing one of the most stupid arguments in decision making of software development tools.

Strong typing is arguably one of the features I like best about .NET and I'll tell you why with an example I had to deal with just yesterday.

I've been working extensively on Help Builder (a Fox app) over the last couple of days and I made a few architectual changes in this framework that is getting a bit old since HB was originally created almost 10 years ago. So I removed some dead code - a few properties.

Finding all the places where this potentially breaks code without a strongly typed compiler is very difficult (you can use CodeReferences but it rarely finds every occasion especially if you use dynamic invokation of code in places). I ended up finding little places where these changes were causing RUNTIME bugs. The only way to truly know that you've fixed everything is to completely re-test the application in hopes you find all the spots where this changed codebase affects the application. Or truly remembering where all the code references exist - I don't know my Memory isn't that good on code that's nearly 10 years old <g>.

The end result is that many times when I would like to refactor things, I don't because it's just too much of a pain in the a*s to deal with the repercussions and ripple effect of an essentially minor change.

In a strongly typed language, make a change to a property name, or remove and the compiler will tell you where it's missing or mistyped or used incorrectly. It's that simple. The same is true if you're in full on heads down code mode and you write a large chunk of code at one time without immediately testing to keep the flow going. In Fox I have to write my code and test right away to make sure I didn't accidentally mistype or format something improperly. There are bound to be typos etc. again, in Fox the only way I will find any of these sort of problems is to run the code.

In .NET the compiler catches all of that and it takes a few clicks to fix it because the compiler tells me a) that there is a problem, b) where it is and c) takes me there so I can change it. Compare that to VFP: Run the application to the code you changed, bomb, look at the code, make the change and re-run. And you better hope you excercise all the code paths.

In a strongly typed language I can worry about logic errors and forget about syntax and typos - the compiler does that for me. Maybe I'm a sloppy coder, but I find that experience of writing code, having to run it and fail only to find that I left out a letter in a variable name very frustrating especially if that code is buried in the UI that often can be tested only within the application. (I try to avoid that but yesterday at least it wasn't possible because of IDE dependencies).

Compare the time to fix this sort of a bug. ST: Compile see the error, click on the error, fix the code, recompile. Total time: Maybe 30 seconds. Fox: Start the application, click to the place you have to go, fail, pop up the editor, fix the code, shut down the application, clear memory etc. restart the app and try again. Time: 2-3 minutes at least. In my work (especially the last couple of days) that's a typical scenario...

I've worked this way for many years in Fox and I've never really thought much about it, but after having spent a significant amount of time in .NET, now when I go back to VFP code I sorely miss strong typing and the true Intellisense that VS.NET offers in the editor.

It's a huge time saver, and while there are things that are bit more complicated because of strong typing (dealing with 'dynamic' typing like incoming generic COM objects) it's not the norm and there are ways around those situations by creating wrappers or using Interfaces. Or you can opt to use VB and turn off strong typing for those particular instances where it is difficult which is rare.

In addition, strong typing in this respect has the distinct advantage of providing meta data information which is another big advantage of .NET that is often ignored. It provides information at designtime (Intellisense that actually works), and for tools that can look at a DLL and tell exactly what types live within it and what functionality is available for it.

This is immensely useful for building code generators, testing tools, documentation tools (like Help Builder) and are all things that a non-ST language can't easily do. For example, Help Builder imports classes from .NET and VFP for documentation. In .NET I can get all the information about an object, type info, methods, properties, parameters with a simple interface (Reflection). The documentation that HB can create from a .NET component is very complete.

In FoxPro to do the same I have to parse source code files and given the somewhat convoluted formats of the designer files. And even then there's not enough information in there. How do you figure out a return type in a VCX method for example? And if I want complete information I'd have to parse through the relationships for parents, find files etc.

You may say that that this doesn't affect because you don't use features like this in your everyday work - but it does indirectly. In terms of what tools are provided for you and what functionalities are not available easily in Fox. For example, lack of proper meta data is one reason there aren't any decent Web Service tools for VFP (and COM) because neither can generate type information on the fly just by looking at the objects. This is why it's so damn difficult to Interop with a Web service that exposes objects or even worse create one that publishes objects from your VFP code. It can be done but it ain't pretty and most of this is lots of manual work.

And you can get that same FULL information about an object instance, or type at RUNTIME. VFP sort of lets you do some of this, but it's very half hearted. The proof of this half-hearted design is Fox Intellisense which doesn't work properly most of the time because VFP doesn't have enough information to give you full information about a type. That's why when you type "THIS." in a PRG file while in a class and you get no useful information about the current class.

Personally I'm not looking at another untyped language unless it is for scripting and there is no other choice. The gains in productivity are too major...