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 VS.NET 2.0 the new databinding features can bind directly to objects and the designers let you look at the objects and pick what to bind to by way of the meta data. You can drill into objects and pick properties several levels down etc. Without strong typing this would not be possible!

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...

The Voices of Reason

Couldn't agree more! Long time VFP developer that 2+ years ago moved to .NET. Strong typing reduces errors and increases productivity for all the reasons you outlined. It also provides a performance benefit, as the runtime doesn't have to dynamicaly determine the type of object when using it.

I'd have to disagree somewhat. Dynamic typing makes possible all sorts of great OO capabilities without downcasting. Generics in .NET 2.0 is a laborious hack to offer some of the capabilities that dynamically typed languages get out of the box. And I still can't have an ArrayList of strongly typed mixed type objects (ie, string, int, decimal).

And Anders H. is already working on dynamic typing where the IDE uses type inferencing to figure out the type. Sign me up for that!

When I came out of school two years ago and started learning FoxPro after using
Java, my first impression was what! no strong typing? I thought "oh great, now I get to
spend half my time running my application to find out I made some dopey little typo". But I soon found that it wasn't a big deal. From time to time it would get me, but not frequently. I think you're right on the with the refactoring limitation though. I noticed I misspelled a constant the other day, and decided to change it. Using the handy Code References tool, I searched for all occurances of the name, and changed them all. Upon installing the app in my production environment - I received the
variable not found error... Not cool, and not much incentive to modify poor but working code.

Hi Brian, you're absolutely right when you say that it's not a huge deal to not have strong typing. Like I said I never thought anything of it while I was doing Fox development almost exclusively over the years. However, even doing Fox development I've always wished that it had much tighter type control at least an opt-in model where you turn it on on demand or where types declared would have to match. But when you go back and forth with another environment that does, you REALLY notice the differences and for me I like the advantages of strong typing considerably more than the advantages of loose typing.

Although I also have a story that plays right into the hands of the loose typing crowd <g>. I'll post that over the next few days.

Hi Brian, you're absolutely right when you say that it's not a huge deal to not have strong typing. Like I said I never thought anything of it while I was doing Fox development almost exclusively over the years. However, even doing Fox development I've always wished that it had much tighter type control at least an opt-in model where you turn it on on demand or where types declared would have to match. But when you go back and forth with another environment that does, you REALLY notice the differences and for me I like the advantages of strong typing considerably more than the advantages of loose typing.

Although I also have a story that plays right into the hands of the loose typing crowd <g>. I'll post that over the next few days.

Darrell mentioned some cool OOP things in dynamic typing and I've heard that before. I'm thinking about looking at Ruby which is a dynamically typed language (I think.) However, the question to me is whether the dynamic typing is necessary ALL THE TIME. My personal preferences is to use strongly typed programming for most things, and then use a lossely typed constructs WHEN NEEDED. Let's face it--there are just some things where you have to loosely or dynamically type to get what you want. I just don't think you need it all the time. Its a trade off:

Loosely Type = Flexibility
Strongly Type = Safety

Use the right tool for the right job. It would be nice to see a language that was strongly typed but allowed you to turn it off when you needed to in order to get the flexibility. In .NET we have reflection but its quite a bit more complex than say javascript or perhaps Ruby.

Totally agreed, but as you say .NET doesn't make this easy. You do get the option to some degree by using VB.NET with Option Strict off which allows dynamic typing. You could stick code into a separate VB.NET project and then call on that stuff as needed to do the loose typing functionality...

After I noticed that VFP will allow you to pass in values that aren't the type that you declared in the procedure's parameter interface, I started type checking all the parameters that I pass.

It's deceptive. Since VFP allows you to declare the parameter's type in the first place, why doesn't it type check? The parameter AS types are really just a glorified comments.I'm relatively new to VFP. Please tell me that there's a SET command to turn type checking on!

After answering three more questions today on how to ‘dynamically’ access a property or control on a form I thought I’d post my Reflection helpers again. I’ve put these into most articles I’ve published, but this way they are easily searchable and pointable for future reference.

Please refer to the many links along the right side of this page. You can search the categories to help you find exactly what you\'re looking for. The ten most recent postings are also easily viewed. And our evolving blogroll contains helpful links to msm (mainstream media), design, remodeling, and renovation websites. We\'ve also included some individual blogs to some great projects that are well documented and may help you with your own remodel or renovation.

She shares her name with the Austrian home of Mozart and Beethoven. And she herself studied classical piano from the age of five. But there’ s nothing old- world about the music of Vienna Teng, whose music brings to mind artists as diverse as Tori Amos, Simon & Garfunkel and Radiohead. A former Stanford computer science grad, and software engineer in Silicon Valley, she gave all that up to pursue her musical passions- a risky career move that has paid off. She has 3 critically acclaimed albums: 2002’ s...