Disappointing blog entry
I'm not sure which of the developers at VFPConversion posted the following blog entry...

Custom Types in .NET

...so I will just refer to them as VFPConversion (though the entire staff may not feel the same way). Here are a few of the more telling quotes from the entry that pretty much sum up what the blog entry is trying to say:

"What could we do in VFP to ease the pain? Well, we could provide objects with methods that take away the implementation complexity. Conversion methods would be useful. The ability to parse a string such as "5m 6cm 13mm" might be useful. "

"In .NET, there really is no difference between types and classes. In VFP, things are different. The system provides a number of default data types that are used to store information, and classes are a bit of a different animal altogether. In .NET on the other hand, there is no difference between a String data type, and a custom class or object. The solution to this problem therefore is the creation of a custom data type (which is the same as creating a new class)..."

"...This is quite a different way of thinking about data than we find it in VFP. In VFP, if we were to store the coordinates of a point in 3D space, we would use 3 numbers. And everyone who used that piece of information would have to know how to handle those three numbers."

VFP is such a pain
So, basically VFPConversion is asserting that it is foreign (painful even) to use custom classes in Visual FoxPro to represent data and that somehow .NET makes this easier. That's where I start to think, "Huh?". The veracity of that premise is completely lacking, especially given the examples they've used. While .NET's data types are certainly implemented as classes, that doesn't make it a better fit for creating a custom 3D class or preclude a Visual FoxPro developer from creating a custom 3D class replete with PEMs. Visual FoxPro, the first language in MS's arsenal to offer Object-Oriented Programming (OOP), is quite capable of creating custom classes that represent data types.

On the contrary, VFP does OOP
If the project justified the additional overhead, classes for data types could easily be created in Visual FoxPro. That highlights one of the real difference between .NET and Visual FoxPro. (note the following is an over simplification to make a point) In Visual FoxPro, if it isn't available somewhere then you'll need to roll your own. With .NET it is already rolled for you in a lot of cases, which might justify the use of .NET (you don't want to spend all your client's time and money rolling your own). So, Visual FoxPro is inferior right? Wrong. That's just the kind of nonsense that comes from some .NET proponents. With so many good arguments and benefits that could be pointed out for .NET (especially when comparing it to VFP), they invariably pick the wrong arguments and harm their credibility in the process (.NET does classes the best, .NET does data the best, Visual FoxPro doesn't do OOP, etc., etc. ad nauseam).

Choice is not a bad thing
The fact is that Visual FoxPro allows you, as a developer, to choose. We could represent the 3D spacial information as 3 numeric values, as an array, as an object, as collection of points, as a cursor, as a string, etc. We aren't constrained to 3 numeric values, or somehow in pain if we have to create a 3D class to represent the data. Those assertions are simply not true. If it wasn't for the fact that I have an immense amount of respect for the abilities of those who are on the VFPConversion crew, I would accuse the author of either ignorance or an attempt to mislead.

The .NET framework recreated in VFP
Case in point... Bo Durban and I have been working on an implementation of the .NET Drawing namespace for Visual FoxPro. For those of you that are unfamiliar with that namespace in .NET it consists of 5 other namespaces and quite a few classes in Drawing and the other namespaces. In any event we're doing it in pure Visual FoxPro and we have been extremely hardpressed to find anything that we can't implement (recreate) in Visual FoxPro easily. Before long Visual FoxPro developers will be typing in System.Drawing.Graphics with the best of them (replete with Intellisense). In any event, there are plenty of complex data types and such... no problem, no pain, no wild machinations. It's just OOP and Visual FoxPro is a very capable OOP language. When Bo and I are done with it, not only will the VFP Community have a complete GDI+ implementation, but they'll also have the source code to it. (I'm also working on implementing LINQ in pure VFP... no problems encountered there either... in fact I would say that I am having a better go of it, because VFP is made for this sort of thing. I doubt MS is doing LINQ with a single developer.)

I love Visual Studio 8
Please don't misunderstand me, I'm not a .NET basher in any way shape or form. Nor an I trying to throw the gauntlet down with VFPConversion (I'm hoping to have an opportunity to see and talk to Rod Paddock on a semi-regular basis in Sioux Falls). VFPConversion has a very talented cast of developers on the payroll and I love Visual Studio 8. I also think that there are lots of projects that a .NET language should be considered for over Visual FoxPro. That's right, Visual FoxPro is not the panacea that some Visual FoxPro purists make it out to be.

.NET is a good framework, and the latest IDE from MS is pretty awesome (and I can't wait to see Cider when it is released). I've always loved data binding controls to more than just the value/text property (controlsource in Visual FoxPro). I love the UIs that can be created with it, the new controls that were added, the designers and its web capabilities can't be touched if you ask me. I could go on for pages about what I like better about .NET than VFP, or about what can be done in .NET that can't be done in VFP. But I could also do the same for VFP versus .NET.

They are different tools and have different strengths and weaknesses (and wouldn't even be compared so often if it wasn't for the bevy of VFP developers that have gone over to .NET - when was the last time you heard someone compare Access or SQL Server with Visual Studio? Perhaps the comparisons have more to do with the fact that Visual FoxPro is such a great frontend for SQL Server and Visual Studio can also create frontends for SQL Server?). If you are adept at both, then all the better. You have two wonderful tools to better implement your customers' visions and solutions.

You're better than that
I am all for a good language getting the good press that it deserves, whether it is .NET or VFP. But, how about a little love for the Fox? Or, at the very least put those keystrokes to good use on an honest, unbiased, straight-forward synopsis of Visual FoxPro's strengths and weaknesses, especially when you are comparing it to .NET. You'll at least sound like you know what you're talking about to your readers.