Are you saying you would recommend COBOL or Fortran development today?

>Two words: COBOL and Fortran. Both are older than dirt, yet both do exactly what they were designed to do better than anything that's been brought in to 'replace' it.
>
>I'd give parts of my body that I'm right fond of to be able to keep the applications I'm working on in VFP, especially since it looks like we're going to be adding some serious statistical calculations to it. I don't know of anything out there that can do the heavy data and computation lifting with the speed of Foxpro.
>
>And as far as the 'non-sexy' GUI, that's a moot argument since VFP would probably have it, had there been ongoing development in it for the last few years.
>
>
>
>>Good analysis.
>>
>>Here's a thought:
>>
>>>>With the current state of development tools I would not bet on any new development tool having the same lifespan as VFP has.
>>
>>Yes, VFP has had a great ride, but do you think that going forward it will have a greater lifespan than languages like C# or Java, or that DBF's will be around longer than SQL tables?
>>
>>One of the hardest concepts for investors is the notion that keeping a share of stock is the same as buying that share of stock every day, since by keeping it, every day you are making the decision that that share of stock is more valuable than what the proceeds of selling it can purchase, which. except for the transaction cost, is exactly what you do when you buy it.
>>
>>Similarly, staying with a language, except for the transaction cost of the learning curve, is the same as choosing it as a new language every day.
>>If you were starting with a blank slate today, would you choose VFP?
>>
>>
>>
>>
>>
>>>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 Graphic user interface, 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 Graphic user interface that is 'modern' looking.
>>>5. If you still decide that your front end Graphic user interface 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 Graphic user interface, but that not by any means a guarantee that you develop a good and efficient Graphic user interface. Alan Cooper has written a good book about this ("About face"). You can screw up a Graphic user interface 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 Graphic user interface is outdated: Well, as stated before, you can do a lot yourself to create an attractive Graphic user interface. Though, yes, its is a bit of a pain sometimes to get what you want, the success of the Graphic user interface 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 In my opinion 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.
>>-