>Mike, I mostly agree with you, but I'd like to disagree here.
>
>Developing software is about using your brains. There is a lot more to it than the usual arguments pro or con a certain development tool:
>
>1. The platform. Is the client expecting the software to run on WIndows, Mac, Linux, Unix etc.
>2. Your proficiency in a certain development tool. It does not make sense to spend writing your software in a tool only because its ' more modern' (for whatever that means) than other programming languages. Many VFP programmers can program a piece of software much quicker than in any other tool. What then is the valid reason not to develop in that tool? Because its gui is not that sexy? Well if that is important to your client, then you might have a point, but if its not, who cares?
>3. Can you think of a software development tool that has as much power and flexibility as VFP in data munging/handling? If not, why could this not be a good choice in developing the data objects and bizobject layer?
>4. If it comes to the GUI, yes its outdated, but there is a lot you can do yourself. The usage of the command bars library (from ARG) is an excellent starting point to have modern menus, the ribbon, nice looking color schemes. With a bit of creativity you can create a GUI that is 'modern' looking.
>5. If you still decide that your front end GUI needs to be written in something else, what is stopping you to use a n-tier solution where all the data and biz objects are written in VFP? Its a whole lot to easier write a complex and flexible data object tier in VFP than you would have to do in many static type languages where ORM generally is still a PITA.
>6. VFP plays very well with SQL server and other backends, but in some cases, even for new projects I revert to DBFs. Why? Because the software has to run on a single windows machine with a simple installation procedure. SQL server, even the free versions complicates things and will lead to much more support calls than plain old DBFS. I've developed several applications for the WHO which became the world standard in their class, but run on single machines on 5 continents with hundreds if not thousand of installations. Do you really want to enforce something SQL server here? Not me, far less headaches with plain old DBFs.
>7. Creativity. The success of you application is far more determined by factors that lay outside the choice of the development tool. You can develop it with the tool with the nicest GUI, but that not by any means a guarantee that you develop a good and efficient GUI. Alan Cooper has written a good book about this ("About face"). You can screw up a GUI in any development tool. Its a whole area of expertise on itself.
>8. Durability. If the application is going to be a long lived application with lots of maintenance it needs a different approach than
>a write once and forget about it style of application. You need to think about the future, documentation, readability, source control, etc. There are a lot of languages where readability is compromised. Certain languages are more verbose than others.
>
>Overated arguments against VFP (my personal opinion)
>
>- The GUI is outdated: Well, as stated before, you can do a lot yourself to create an attractive GUI. Though, yes, its is a bit of a pain sometimes to get what you want, the success of the GUI has far more to do with creativity than with the limitations a tool draws upon you.
>
>- 32 bit limitation. Well, I don't see that as something that is a big problem. 32 bit applications IMO will be supported for a very, very long time in the future. There simply is too much heritage.
>
>- No longer being supported by MS. I've never needed any support from MS and I do not expect that to happen in the future. The only thing that I see as a potential danger is that will cause problems on future OSs (As we have seen with some Vista display issues, and the performance issue in FPW2.6) but usually those problems can get bypassed without the involvement of the VFP team (The bugfix for fpw2.6 was developed by a non-MS person)
>
>-DBFs. You'll have to use them where they make sense. Don't try to develop an enterprise solution on DBFs. Use SQL server then.
>
>
>But perhaps the best argument pro or against using VFP as a development tool is whether you are a consultant hopping from one gig to another, or you're a developer developing software with a lot of domain knowledge working in a niche. If you're a consultant looking for a job, you'll have to offer what the market is asking for. If you're a domain expert in a niche with a reasonable stable outlook, its far more important to use the best resources, including knowledge and experience in a tool, to enhance and continue the development of your software to stay ahead of the competition. Decisions to switch development platforms is a tremendous difficult and risky one, especially if there is a tens of thousands of hours investment in the product. Aside for the tremendous effort to convert the existing codebase into a new development platform, whats your guarantee that this new development platform will still be up-to-date and sufficient in the future? With the current state of development tools I would not bet on any new development tool having the same lifespan as VFP has.

Excellent points delivered in a professional manner. Thanks, very refreshing.