While I also disagree with Mr. Nelson's assessment of the announcement (though I respect his right to an opinion that differs from my own), I take issue with your comparison/analogy below. From what I can gather, your different "generations" of applications are progressive versions of the same software suite. I am guessing that each successive version can do everything the previous one can plus added functionality and less bugs. This is not even close to the situation with VFP and .NET. .NET cannot fill the voids that VFP leaves behind. Please open up Visual Studio and create a report like you can in VFP natively... obviously you can't and you'll need to purchase Crystal or some other Report Engine for that. OK, so open up Visual Studio and create a database natively... obviously you can't and you'll need to purchase a Third Party Product for that. And as for bugs? .NET is way less stable than VFP, though this is no slight on MS or its developers -- VS.NET is still in its infancy and has a ways to go before it can be considered a mature development environment. I am sorry but your reasoning via analogy just doesn't hold up under careful scrutiny Martin.
So let's say Microsoft calls me up and says, "Hey Craig, we really recommend that you move all your development to .NET". My answer is, and would be, "I love you guys, but I've moved as much of my development over to .NET that I can. .NET simply cannot reproduce some of the basic functionality I get with VFP. I would also lose a significant portion of my client base that doesn't have really deep pockets (but help keep the lights on here). The added cost of purchasing Third Party Products and Per Seat Licenses that are needed currently to augment Visual Studio and make it a viable solution for a number of my production apps is just prohibitive. I'm afraid I will have to decline your recommendation for the obvious reasons I've just stated." This statement doesn't even begin to touch on the many reasons why .NET is not the cure all to development whoas. It is, just like VFP, another tool to be used when appropriate. VFP is not the DOS version and .NET the latest and greatest version. .NET and it's languages are completely new (relatively speaking) and not comparible with VFP on a variety of fronts.
It's as insane to recommend .NET for most of my VFP data-centric production apps as it is to recommend VFP for my ASP.NET web projects. It is just not going to happen. Martin, if you recommended to a customer to upgrade to the latest suite you offer, and they explained to you that your DOS version had many features they rely on that your new version doesn't have, and then politely explained to you that they couldn't afford to purchase a bunch of Third Party Applications and new OS's in order to successfully switch to your newest version, would you still recommend that they switch anyways in order to make an extra buck and reduce your support overhead? I doubt it, cause any company knows that its ultimate success is contingent on its customers' success. If you're not offering solutions to your customers and are instead offering them problems, then you become a liability. Ceasing to have justfiable value, you will soon find that you're running really short on customers. And what about those customers that are using your DOS based programs? How many times have you used them for references for a new sale and their word-of-mouth lead you to prospects you wouldn't have otherwise had? The value of a satisified customer can not so easily be figured on a balance sheet and discounted Martin.
What I'm saying is that we're talking apples and oranges, two different tools with different abilities that overlap in certain areas. I do what is best for my customers and my company, and right now there are many projects that are best served by being developed and maintained in VFP, just as there are many projects that are best served by being developed and maintained in .NET. Make it easier for me to use both on a project and I'll be in heaven... VFP data with no per seat licensing, VFP Report engine, .NET UI design, .NET web features, VFP speed, VFP Data Manipulation, .NET Compact, etc. etc. etc. I can use each tool for what it is best at and deliver superior products in a fraction of the time while holding down costs and provide a massive amount of scalability for my customers.
Interop/Extensibility is the way of the future... .NET is but a part of that dream. It's running over into all kinds of other areas at Microsoft right now. Look at the XML format that Word will use in the future... that's a monumental step forward and not at all the kind of thing one would expect from Microsoft. It gives the customer power and freedom and increases the usefulness of Word documents by a hundred times easy. The same is, I believe, true with Sedna. It's a monumental leap forward for VFP, and for .NET too truth be told. .NET will be 100 times more useful to VFP developers once Sedna is released. And VFP might just find itself being really useful to more than a few .NET developers that wouldn't have given it a second look before. So, I'm a .NET only developer, and I find out that I can purchase VFP for under $500 and have reports and data and speed, and it does classes so I can create data-centric objects and middle-tier components for my applications... I think VFP just got itself a new customer.
OPEN IT ALL UP! I say and let each MS developer tool and application stand or fall on it's own, based on it's ability to do something better and more useful than any other tool there is. I don't have any fear whatsoever that VFP can stand on it's own merits. There are already plenty of VFP gurus trying to show developers how they can leverage VFP in their solutions that are written in .NET and/or have SQL Server backends. Just wait until we have Sedna, we'll be able to do a little evangelizing of our own... couple that with VFP developers exxperience and intrinsic knowledge of Object Oriented Programming and Data-Centric Design and we'll be a force to be reckoned with! <bg> (ok, I got a little crazy at the end there, but I'm better now.)
>Hi, Jim.
>
>>Virtually everything about this announcement says 'get your *ss over to .NET as soon as you can'. In return you will get extensibility of your VFP investment in .NET.
>
>I beg to differ. If Microsoft were trying to force you badly to go to .NET, they could just cut any further development, and maybe let all us wait for years for another version. If they are spending at least 10 bucks to let us make better interop with .NET, it is because they are willing to let you and any other VFP developer to keep woking with FoxPro and support your customers while using their new technology.
>
>That said, I think it is obvious to anyone that Microsoft would prefer that ANYNONE uses .NET.
>
>Don't know about you, but my own company has three main different "generations" of our applications still running: a very old DOS suite that about 4 mid-sized customers are using (not surprisingly from goverment), then a Windows, DBF-based suite, and finally a Windows, SQL-server based, n-tiered suite. 90% of or customers, and 98% of our revenue comes from the latter version. Do you guess who are most cost-intensive for us from a support perspective?
>
>But we keep supporting those customers, even while the older versions don't get any update, because they are our customers after all. However, of course, we don't let any chance go without recommending them to upgrade for our latest version. Maybe the solution they have is good enough for them, and maybe some old features anre not in the new versions anymore, but for us it is a matter of strategy. Can we blame us for trying to move them on? do you think tht they wont have some important benefits just from embracing our main product strategy?
>
>Best regards,
