VFP: Craig Boyd and FoxPro Visibility

Posted on March 14, 2006. Filed under: Visual FoxPro |

Yet another ‘right on brother’ moment with Craig Boyd’s clear outline of why FoxPro is getting noticed more and more these days.
 
Read it here:
http://www.sweetpotatosoftware.com/SPSBlog/PermaLink,guid,16751b44-0edb-4946-875c-1e7b5b7d65a6.aspx
 
There’s a stack to like in this post but a few key points for me are:
 
1. Craig is essentially talking about ‘the right tool for the job’ as his cry for the Fox – I think it is great to play to the strengths of each development tool we use. So, in those small dev team projects, or heavily data centric apps, we use the product that serves us the best. VFP continues to fill an otherwise big gap in the development tool spectrum.
 
2. Know your product – I am a little disappointed that more people in Australia aren’t taking advantage of the great SQL Server integration in Visual FoxPro. As Craig points out: VFP knows data. But that doesn’t mean you have to always store the data in a VFP backend (as good as it might be). Once you free your self up to use VFP with other data stores you basically open yourself up to a huge world of opportunity.
 
3. It’s still here – and whilst we can’t have complete confidence that the roadmap won’t all change tomorrow, we can be confident that it will be supported for a long time yet. I’m still confused when people complain about how Microsoft doesn’t support VFP and we should all be petitioning Microsoft etc. If the tens of millions of VB6 developers complaining about lack of support for their product didn’t change Microsoft’s attitude, then if anything we should be jumping with excitement about how the VFP team still has plans for enhancements over the coming years.
 
4. It’s about community – the growth and strength in VFP this year and next will come primarily from the awesome community the product has backing it. Sure, there are a whole bunch of things I’d love to see in VFP (multi-threading is my top choice btw) but it is a pretty safe bet that that is never going to happen. So, as a community we will work out the tools and techniques for getting around those hurdles (it might even mean using a different language for some parts of our projects).
 
Craig’s final list is spot on, but the pick for me is always the built in reporting engine.
In this day and age I think it is amazing that we have the only real tool for building super fast, database intensive, easily deployed royalty free, report slick, applications that are so stable. And since we’ve been using the tool for so long we can build them pretty quickly too.
 
Seems like a completely unfair advantage to me.
 
Advertisements

Make a Comment

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Liked it here?
Why not try sites on the blogroll...

%d bloggers like this: