FoxPro is Dead -- Now What? (Session Notes: Steven Black)

This was a session given by Steven Black. I've only been able to find peoples' recollections of the talk. Highlights listed here:

German Visual FoxPro Developer Conference 2007:

Always be happy about what you do, about the fact that you are using Visual FoxPro to develop your applications. You do not need to apologize to anybody for using VFP. If you yourself do not believe in what you are selling, neither will your customer.

Is the recent announcement from Microsoft, that there will be no VFP 10 of such a grave importance to us? Well, what is it that you are missing in the VFP? Steve can't think of anything more that would really be that hard to live without. If anything he would wish for even better stability. You know this – a new version comes out and it has a new base class. What it does is something you have implemented a long time ago in your framework. So, do you really need this? You have everything you need already.

It is always important to focus on customers, not the technology. The task is to get the job done in the given time frame, budget, given quality and with a minimum of risk. Always use VFP if it fits the job and since you know it, there will be no unpleasant surprise. This comes once you start using a new technology. Only the uncertainty of how much time a given task is actually going to take to implement using the new technology is really big problem.

Do you plan on rewriting your current application to a "more preferred" platform? Don't. The time it is going to take will most likely be incomparable to the time it took you to create the original application years ago. The business needs grow all the time and in the application you would have to care for everything the old system does not as well as the new stuff from business needs that have arose over the time.

On migrating from VFP to .NET (Site: Les Pinter)

Link here

Excerpts:

However, back in March of 2007, Microsoft officially announced that they would no longer enhance FoxPro. This means, among other things, that it may not work with future operating system releases. It already conflicts with some Vista features. If you haven't installed Service Pack 2, don't. Enough said.

---

As tables grow, multiuser installations on Local Area Networks experience performance degradation. Logging users off to reindex files is a major struggle, and the fact that it has to be done pretty regularly is a real problem. And anyone who has access to the network share where your tables are located has the ability to copy the data or change it, bypassing your excellent efforts to keep the raw data clean.

---

In addition, it's increasingly difficult to find skilled FoxPro developers. Some are retiring, and new ones are few and far between. I don't know of a single university that teaches FoxPro; most of them teach .NET languages. The handwriting is on the wall.

---

Rewriting an application sounds daunting, but in the case of a rewrite, you've already done 70% of the work; the systems analysis that defined your business rules.

---

You never know what Microsoft's going to do in the future; but you can be ready for it.

"Are You More than Your Language?" (Article: David Stevenson)

by David Stevenson

Highlights:

The Visual FoxPro Toolkit for .NET, released recently on the GotDotNet website, is a collection of over 200 commands and functions that are effectively added to your .NET language of choice just by referencing the VFPToolkitNET.dll, which is written in managed .NET code and does not require a VFP runtime.

"Why would I want any Visual FoxPro code in my .NET application?" you might ask. The answer is simple: productivity.

The Toolkit contains some incredibly useful functions from VFP that are not native to .NET, such as STREXTRACT, which can save you lines and lines of code when you need to pull text out from between two user-defined delimiter strings, such as you might face in a screen-scraping scenario. Another example is STRTOFILE, which converts a string into a file in just one line of code. You can find the toolkit freely available for download at www.gotdotnet.com/team/vfp.

"Visual FoxPro 9.0: Still Here, Still Relevant" (Article: David T. Anderson):

by David T. Anderson

Highlights from the article:

While it may be true that managed code and strict compilers can result in "safer," less buggy, and more durable code, a single FoxPro developer can write a full-blown desktop or Web application in a comparatively short amount of time. The effort required to deal with complexity is left primarily to implementing application and business logic, not trying to understand a massive framework or wrestle with data binding.

So why should you care about a product that receives only the occasional nod from its maker? Because, Visual FoxPro is still here and it is still relevant. It serves a need that is underserved by any other single product in its category. Further, because of its ability to run on cheaper, older hardware, run legacy code, and still do everything a modern programming language is expected to do, it will remain the product of choice for renegade workgroups, small resource-constrained offices, independent software developers, and many governments and government-run agencies.

---

For FoxPro developers, Fox has simply been a safe application development path; your investment in the technology was not compromised by innovations made by the vendor. Unfortunately, the same can no longer be said with regard to marketing or other products made by the same vendor. This has lead to today's misconceptions about FoxPro and its place in the developer's world.

VFP will not become a .NET language. This was considered heavily during the VFP7 timeframe, but the changes would have resulted in a language that, at best, could not maintain its backward-compatibility and at worse, lose its powerful data manipulation capabilities. And the areas that were redundant between the .NET framework and VFP's extensive language and classes would have created more confusion and very well may have lead to an untimely death for the product.

---

I asked him if he thought he could have done what he's done in .NET. His response was "I have three .NET developers here that I run rings around."

---

It's Still the Choice of Developers with a Significant Investment in Existing Code

"... there are, by my guess, billions of data records stored in FoxPro worldwide and the FoxPro DML is the best way to manage those records. The language is the most approachable language in the programming world and is easily understood by those with minimal skill."

---

It's Still the Choice of Managers with Constrained Resources

Garrett Fitzgerald, a VFP MVP says it this way:

"FoxPro has long been the bread and butter for companies that don't want to (or can't) spend the money to chase the latest technology. Mom and Pop stores don't tend to need a .NET/SQL Server solution to run their businesses, and can't justify spending the money to do it correctly. FoxPro is peppy, even on lesser hardware—compare the requirements for both. However, when properly written, Fox apps can (and have) handled data sets up into the 100s of gigs."

It's the Swiss Army Knife of Data-centric Applications

I find that having delivered applications in VFP, I have a grasp of the entire software development process. I understand issues from design to development to maintenance and migration. I understand the ins and outs of database design, object-oriented design, user interface design, business object design, data access layers, COM and Web services, and enterprise design patterns.

"The Product That Won't Die" (Article: VFP Wiki)

Jerry Kreps had a good eye for the future. From the wiki:

It won't die the way DOS doesn't die.... people will go in using the last standard release for years, but useage will tail off exponentially until only a few are using it. My predicition is that Visual FoxPro development will cease sometime between 5 and 10 years from now, if not sooner, probably about the time the next WinOS comes out. Longhorn, isn't it? The new OS will be so different that Visual FoxPro won't fit in at all. To use Visual FoxPro folks will have to stay with XP or Win 2 K or Win9X, something that MS is forcing people NOT to do by means of 'security' patches. data format changes, etc..., or update to .NET compatible languages and interfaces. By then all the 3rd party links to .NET will have gone beyond the embrace and extend mode, and into the extinquish mode, leaving .NET developers totally in a pay per use licensing scheme.

---

From my POV their efforts with the Visual FoxPro community are such that they are treating the Visual FoxPro community as geriatrics and the Universal Thread forum as a 'nursing home', attended by some big name nurses, where some patients will die and others will move to .NET & C# (get well). That is what CoDe is all about too.

"Why We Use Fox" (Article: VPF Wiki)

A Place To List Why We Use Fox

Productivity Issues
Notable Development Capabilities
Licensing Issues
Stability Issues
Developer Community Issues
Other Issues

Dev Choices (Comment: VFP Wiki)

VFP Wiki:

I would ask the very same customer: "How would you feel if I start telling YOU what to use for your product..." I feel too much emphasis is often put on the tool we use.
If a problem is solved for the customer why would he/she care with what the problem is solved? -- Boudewijn Lutgerink

"Choose the right Microsoft database for your development needs" (Article: Tech Republic)

Decision Support: Choose the right Microsoft database for your development needs by Lark Group Inc.
From the VFP portion:

Sometimes it seems like Visual FoxPro is the database that Microsoft forgets it owns. Microsoft bought FoxPro in the mid-1990s, rolled some of its performance features into the Jet engine, and then continued developing FoxPro as an independent product. But FoxPro has never benefited from the sort of full-press marketing that the company has applied to Access and SQL Server. That's a shame, because Visual FoxPro has grown into an amazingly powerful system for building database applications.

Although originally a dBASE clone, FoxPro has evolved far beyond its xBASE roots. The latest version, released in early 2003, sports a number of high-end features, including:

• Deep and consistent object orientation.
• The ability to use SQL Server, OLE DB, and ODBC data sources on a par with native FoxPro tables.
• Advanced user interface controls.
• XML support, including Web Service compatibility via the Microsoft SOAP Toolkit.
• A redistributable runtime library.

The FoxPro engine has a well-deserved reputation for speed. Coupled with the true object-orientation of the language, FoxPro is an excellent choice for dedicated desktop database developers who have performance and rapid development as their goals. But FoxPro remains a desktop, file-server database, not suited for high-volume transactional applications. (FoxPro can use SQL Server as a database, but in that case, you're using the SQL Server engine, not the FoxPro one.)

FoxPro is also the only one of the Microsoft database products to run well on Linux, using the WINE libraries—although there has been some question as to whether this is legal under the FoxPro license.

Perhaps the largest drawback of Visual FoxPro is its niche status within Microsoft. The FoxPro IDE doesn't look or work like the other Microsoft IDEs and the FoxPro language is unique. And although FoxPro does interoperate with other Microsoft products, sometimes the implementation of this interoperability lags.

If you can stake your entire career on a single database product, Visual FoxPro will fit the bill. But if you move back and forth frequently between multiple products, you may find that switching to and from FoxPro is somewhat jarring.

---

If databases are your bread and butter and you pride yourself on performance and craftsmanship, invest the time to learn Visual FoxPro. You may not be able to do everything with this tool, but the things that you can do will be done superbly well.

On Sedna (Thread: West Wind Forum)

SEDNA - March 2006 CTP

One post:

This kind of stuff should of been wrapped up yonks ago. People don't want to learn all the MS API's for networking etc just to do some basic tasks...I was hoping that the VFP guys would let VFP go out with a bang. I suppose this kind of thing just doesn't happen with software.

Another:

Sorry to say I wouldn't expect too much out of SEDNA since MS has pretty much let it be known that they will add nothing new or strategically better in Sedna to make VFP competitive with .NET in any way. I gave up on MS doing this a while back. However, I thought some of the supposedly Open Source movements in the community would be better, but, at least one seems to be just as bad (if not worse!). SourceForge is probably the best hope to create Open Source VFP projects now since they have some sort of track record for doing these things right...

On Announcement (Blog: Kevin Cully)

I wish they hadn’t said that. - No VFP10

From the blog:

I wished they didn’t say that there wouldn’t be a VFP 10 even though I always knew there wouldn’t be another version. I just don’t want to scare my customers. VFP is going to around for a LONG time.

On VFP's Future (Blog: Vinod Prasad)

Future of Visual FoxPro

Author poses the question and disappointingly only gets one response: a list of links to blogs. Anything of relevance will be posted on Eye on VFP.

"The House that Fox Built" (Article: Rod Paddock)

by Rod Paddock

Nothing informative here. Just a list of developers who worked with Fox and own houses.