Hi kevin,

Thank you for your post, and truly I think it makes sense. OTOH, it does not answer the question "Why convert".

While .NET has a far wider application (I don't think anyone would imply otherwise), I yet have to see very good reason to migrate NOW! for the most VFP developers.

As we all know, .NET is not as data centric as VFP. Though VS 2005 is going to be an improvement, you still have to ask yourself the question, is this the language that can be seen as the successor of VFP ? Currently I say no.

.NET forces you into a certain way of working in regards that often is not the most optimal one. One that is very obvious is doing DML on the client side. Working with ADO.NET is not as flexible as with VFP cursors. I'm sure (reading KenL's message) that this will be improved in future versions of .NET.

The force behind VFP IMO is that you have so many different ways to skin the cat. In .NET you have way more limited options to process your data. The main answer is, send it off to the database server and let that do your task, while ignoring the question if that kind of procedures really belong there.


>>I wish someone would start a seminar/website called "Why Convert?"!


>I know it can be very frustrating to be at the top of your game in a particular language/toolset and then have a brand new technology like .NET come along. When Rick Strahl and I first began to learn .NET we felt like we went from gurus to complete idiots in two seconds flat--that can be completely demoralizing. But I remember feeling very much the same way when Visual FoxPro was released. I had to ask myself whether it was worth it to stay in FoxPro 2.6 or make the leap to VFP knowing that I would have to rewrite applications to do so.

I think you're drawing the wrong comparison here. Though the difference between VFP and FP was huge, still the commands and database engine were about 100% upwards compatible. There were not a lot of features lost when converting from FP 2.6 to VFP.

Converting from VFP to .NET is a total different game. Not only you have to learn a total different development platform, which is difficult enough, but also you need to forget the design aspects in VFP that we so highly appreciate, and start learning to overcome limitations in design in .NET.

>

• I think one of the biggest advantages of .NET is the reward you get for your learning curve. Although the .NET curve may be steep at first, once you've "arrived" you can create Windows applications, Web applications, Web Services, and Smart Device (PocketPC/Windows CE) applications. In the next version of SQL Server you'll even be able to write stored procedures in C# or VB .NET. In contrast, with Visual Studio 6 you have to learn one language / toolset for Windows, another language / toolset for Web, and yet another language / toolset for smart devices.
  
  Sure, a good reason to learn .NET. However good enough to just port and force every application into it ?? BTW, I find the integration of .NET into SQL server a dangerous one. It will tempt people to write whole chunks of applications that really belong somewhere else (middle tier or client).
  
  >
• Strongly typed languages! Because Visual FoxPro is weakly typed, you must run your code to find most of your bugs. In contrast, C# and VB .NET are strongly typed languages, which means you specify the data type (integer, string, DateTime) of variables, method parameters, method return values, etc, which allows you to find most of your errors at compile time. If you've never worked with strongly typed laneguages I recommend checking out this feature. It's phenomenal.
  
  To be honest, I don't have much experience with .NET in practise, but from the past when I programmed C/C++ and pascall, I must say that I don't miss strong or srtic typed lanugages a bit. Most of the errors during compilation had to do with type cast errors that VFP would not have been a problem in VFP. BTW, I did not know VFP before I did those other languages.
  
  To be honest, I think every code that has been written has to be tested, so the errors about typos in variablenames will be filtered out of the application before going into production. Whether they become apparant during compile time or run time is not a real issue to me. With the very fast VFP compiler (Compiles my 9 MB application within seconds) recompiling is not an issue also. IOW Personally I do not attach much value to the strict type/ strong type/ weak type dicussion. It is very marginal IMO.
  
  >
• Advanced Object Orientation - It used to be that we Fox developers looked down on VB because it wasn't truly object-oriented. At this point, VB .NET (along with C#) has leap-frogged VFP's OOP capabilities with important advancements such as interface inheritance, the ability to create custom events, true abstract classes and methods, overloaded methods, enumerations, and so on.
  
  You have to keep things into perspective. .NET can't do multiple inheritance like C++ does, but developers don't find that an important feature. I'm not sure what you mean with interface inheritance as oposed to the IMPLEMENTS clause into the DEFINE CLASS structure. I do use 'VFP's version of interface inheritance in for exmaple extending Crystal Reports. Overloaded methods are mainly a consequence of using strict type languages rather than a feature of such language. IOW, the need for overloading methods is not so high in VFP at all
  
  OTOH, for the ones that have done C/C++, .NET its OO model is more cleanly, but lower level (3GL as oposed to 4GL) implementation.
  
  >
• Targeting Multiple Platforms - Microsoft submitted C# to the ECMA standards committee and C# has been adopted as a universal language. This paved the way for the Mono Project (http://www.mono-project.com). You can write C# code today that can be compiled for either the Windows or the Linux platform

Sure, but what does this mean for folks that have their project running in VFP ??

>I've literally taught hundreds of VFP developers .NET, and although the learning curve can be tough at first, I have yet to find someone who was sorry they arrived on the other side. Most VFP developers who are using .NET love it (well for the most part, love it and sometimes hate it as is the case with most MS products <s>).

I know a guy who used to say "The right tool for the right job". This rule seem to be shifted into "The most fancy, newest, modern tool for every job". Hence the question "Why convert ?"

>I know there's a lot of heat behind the VFP/.NET discussions, but I highly recommend VFP developers take a serious look at .NET when getting ready to rewrite or create brand new applications.

We will be watching .NET, sure and draw our own pragmatic conclusions. However I get more the impression that certain "visionaries" who appearantly are blind to "Differences" rather than "Advantages" are blindly spread their thoughts "VFP is dead" and you're stupid not to dive into .NET.

My 2 cents
Walter,