On the Universal Thread there has been a raging debate going on about the virtues of Typed vs. Untyped languages. Having worked and still working with both in C# and Visual FoxPro almost on a daily basis I can tell you that my preference is by far using a typed language!

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 a couple of days ago.

I've been working extensively on Help Builder (a Fox app) over the last couple of days and I made a few architectural changes in this framework. The app is getting a bit old since the original HB was originally created almost 10 years ago. So it's not uncommon to try and refactor some of the old framework code. So I removed some dead code - a few properties and few other things.

Finding all the places where this potentially breaks code without a strongly typed compiler is very difficult (you can use CodeReferences but i 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 ass 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. 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 FoxPro 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.

Downsides to Strong Typing

The counter arguments raised on the UT against Strong Typing on the UT focused on two major points:

• Tough to do ‘dynamic typing’ for things like COM Interop
• Strong Typing isn’t necessary because editors ‘could’ potential do type checking for you
• Too much work to declare everything

COM with Strongly typed languages

I will easily concede the first point. COM Interop from a typed language is a lot more difficult than it is with an untyped language. In .NET the right way to do this is to import a typelibrary and hope that the type library accurately describes all the types inside of the application. The latter is not guaranteed. For example, in VFP I often create COM objects that return dynamic records of data (a SCATTER NAME Object for example) that can’t be described by any typelibrary. Accessing code like this from .NET requires messy Reflection code (which with the proper wrappers is not terribly unintuitive).

Overall I don’t think this is a big deal, because:

• COM Interop is not nearly as much required with .NET at least
• The things you really use – Office specifically – have tools that facilitate the process
  (Visual Studio Tools For Office)

Editors for loosely typed languages

I haven’t seen such an editor and I doubt that there will be one. It’s damn tough to parse untyped code and get meaningful metadata from just the source code alone especially if that source code doesn’t tell you type information. Without strong typing, how does the editor know what’s an object, what’s a property and whether it subobjects? How could it? It can take you some of the way as the Visual FoxPro editor does, but it will always stop short of providing a complete implementation.

The second problem with editor implementations is that it relies on an editor. The editor doesn’t compile the code. If you don’t use the fancy schmanzy editor that does this supposed syntax parsing then you’re back to having no type safety checking at all.

Too much work?

This point I don't really get. Yeah sure you have to declare every variable, but I've been doing that in Fox for years - or rather I should say 'trying' to do that everyday <g>. The problem is that it's optional, so it's easy to slip. And because it's optional it's even easier to make a typo in a variable declaration and accidentally fail to set scope for a variable  when you thought you had. How do you find that error? When your code fails at runtime under really odd conditions. Bugs like this take hours to find at a time especially if it's a typo in the declaration where a click browse of the code may look right when it's actually not.

Meta Data is important 

I find the strong typing features coupled with Intellisense 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 doesn't directly have to do with strong typing, but is related to an advanced type system that actually provides your code and the environment tools useful information about your classes.

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 for a Fox class, we have to parse source code files ourselves 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? I’ve done this in Help Builder and the code to do this is a serious mess and what’s worse it doesn’t provide all the information that would be useful.

You may say that that this doesn't affect because you don't use features like this, 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.

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.

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