VFP: How to make Visual FoxPro cool

V
VFP: How to make Visual FoxPro cool
In case you hadn’t noticed, Visual FoxPro (VFP) is not very ‘cool’. In this post my aim is to cover 3 areas:
1. Why VFP isn’t cool
2. Why it matters
3. How we can make VFP cool
1. Why VFP isn’t cool
OK, so the first thing we need to agree on is that VFP is not cool. I’ve been chatting with a few people in the .Net space lately (including Adam Cogan and Paul Stovell) about their thoughts on VFP. I’ve concentrated on developers who have never used VFP because they can offer the most useful opinions (as opposed to say VFP/.Net developers who are pretty well aware of what VFP can do).
Straight away we need to acknowledge that there is a general lack of knowledge in the .Net community on what VFP can do. For example, they are genuinely surprised to learn how easily VFP can talk to SQL Server. Countering this is not my agenda however – there have been plenty of discussions on the lack of marketing for VFP and I have no interest in repeating them here. I will come back to ‘spreading the message’ later in this post though.
Rather, I’m going to concentrate on non-technical areas. Here’s some of the reasons why people think VFP isn’t cool:
Reason 1: It is ‘over the hill’
The first thing that VFP has against it is the fact that it has been around for so long. You’d think this was good thing right? Stable. Optimised. Large community. Nup. Today’s new developers are most interested in working with the latest technology. And VFP aint new.
Think Cobol. When people laugh about someone being a Cobol programmer, its not because they are bringing to mind the languages shortcomings. No, primarily they are thinking of how antiquated the language is – ie it must be a bit of joke to be still using it.

 

And sadly, Visual FoxPro is creeping into that same area. This is in spite of the fact that Microsoft is currently working on the next update to VFP and has confirmed support of it until 2014. ‘But it is so old!’ – yes, it must be well past its used-by date… or so the theory goes. Disagree with this all you like, but its a fact – ask a new uni student what they think of VFP and they’ll look at you blankly. Ask an older developer (not a VFP developer) their thoughts and they’ll query whether it is still around. Inform them it is and watch their reaction – it must be on the scrap heap surely… and on it goes. We’ve all run into this thinking out there.
And I can relate to this myself. I love all the new stuff, so I totally understand where they are coming from.

 

Now, at this point you may be questioning if new developers are really that ‘superficial’ – I mean surely they’d have some interest in comparing the tools and choosing the best one to work with. Nup. I reckon the actual abilities of the tool comprise roughly 5% of the decision process.
Don’t believe me? Then consider this – why are there more developers going into C# than VB.Net? C# is cooler, that’s why. Both languages have roughly the same functionality, and yet C# is perceived as being the language the smarter ‘real developers’ choose. Yes, and VB is for the people who find C# too hard…
There are ofcourse some pretty major (and vocal) proponents of VB, but the fact that they have to ‘explain’ why VB is just as good is part of the proof that it is the ugly sister. [btw I expect this last paragraph will probably get the most reaction from readers, and if so, then its because you’ve missed my main point.]
Main point => Coolness isn’t about technical ability, it is about perception. Perception is everything.
Reason 2: It doesn’t do Managed code
The second thing against VFP is that it is not part of the .Net suite. VFP code isn’t managed code. And here’s the interesting part – ask a new .Net developer why managed code is better. You’ll get a few mumbles about better memory management, some will mention garbage collection, but by and large, developers can’t tell you what’s so good about managed code. It’s just better OK.
So, because VFP isn’t managed code then it must behind the times. Ofcourse, they all use Word, Outlook, Skype, Windows Media Player and a host of other applications that aren’t written in managed code but that’s beside the point. The point is that if you are writing managed code, then the perception is that you are writing better code. Managed code is cool, VFP isn’t.

And don’t get me wrong – I am not ridiculing this thinking, I actually think it has a lot of merit. My point is to simply list reasons for the perception VFP has.
Reason 3: The Developer User Experience
The third strike against VFP is the tired look and feel. Run up VFP and you are faced with the old Windows 2000 menus. No nice Whidby menus, not even Office 2003 style menus. Open a few dialogs, all the icons are ancient. Nothing is 3D (except some of the new reporting dialog icons) and the status bar is from the 90s. Yikes it doesn’t even have a tabbed interface (someone really needs to do something about that {g})
Ofcourse this doesn’t matter one iota to the quality of the applications it produces, but these days the user experience is core.
Reason 4: It has the word ‘Fox’ in it
Although the word Fox has actually benefitted somewhat from the FireFox browser, over all, the words Fox and FoxPro are largely outdated. VFP really needs some rebranding to overcome this.
For many people there is a big stigma attached to the word FoxPro. They can’t disassociate it from the crappy FoxPro for DOS application they used in a company 10 years ago (my attention has turned to older developers here).
But even more recent developers remember the FoxPro that came with Visual Studio 6. They saw it there, but can only really remember the bland 16 colour icon it had. Again, the perception is that it is old and irrelevant.
And don’t underestimate the need for branding. Take Microsoft FrontPage for example. The stigma attached to FrontPage from prior versions (where it used to bastardise your HTML) was so bad that Microsoft knew they had to rebrand it. And so what was originally going to be FrontPage 2007 has now become Microsoft Expression Web Designer Edition (check out the demos for it here and you’ll see what I mean). Same product, different perception.

 

2. Why it matters
So what if VFP isn’t cool – it still does what we VFP developers need right?
Wrong. The biggest problem VFP faces going forward is lack of developers. The VFP programmer pool is most likely reducing.
I am assuming most people will agree with this statement.
The challenge for a VFP devleopment shop is not the technology, its the people. If you want to grow your business and take on new developers you need to have a good supply of them to choose from. So why are there less VFP developers?
This is because all the new uni students are studying .Net or Java. There are exceptions ofcourse, but this is the general trend (and I suspect this is happening in India and Asia aswell, not just in Western countries).
And why aren’t uni students learning (or interested in atleast knowing about) VFP? Put aside the hype and huge marketing push from Microsoft for a minute and it all comes back to the coolness factor. If we could make VFP cool, we’d get more takers.
3. How to make Visual FoxPro cool
So, what can we do to make VFP cool? Here’s some ideas (some we can do, some are out of our hands):
Rebrand it (Requires Microsoft)
It is time to lose the word ‘Fox’.
Microsoft has not indicated what the next update/version will be called. For now it is simply code named Sedna. However, I have started referring to it as Microsoft VF.Net
The VF is short for Visual FoxPro, and the .Net refers to the strong integration it has with the .Net 2.0 framework. No, it doesn’t write .Net code, but it does use the .Net framework. It is a .Net aware language.
I’ve also changed the icon in the top left corner of the VFP IDE. So when people see me using VFP they see the caption as Microsoft VF.Net and the nice icon. You can also disable the splash screen using a config file, so, unless you look at Help > About there is not a Fox in sight.
I also use FoxTabs (even though it is still in beta and has a few known issues, and needs a name change {g}) which improves the design experience.
Revamp the interface (Requires Microsoft)
The interface needs an overhaul. Update the menus to be like Visual Studio 2005, spruce up the dialogs and splash screen. Note, we don’t need a single change in functionality, only the look and feel of the product.
Promote the .Net integration
In demos to a mixed audience (ie not confined to Fox devs) I will try to mention the new Sedna examples (and gee I hope there is a new CTP coming soon…). Developers don’t realise how easy it is to use VFP with .Net (both using Sedna and using .Net controls – check out Craig Boyd’s and Rick Strahl’s site for examples)
Promote the data binding
The stuff coming in LINQ for .Net is great. However, show people how much more they can do in VFP, and tell them they should campaigning the .Net teams to provide the same. .Net developers should be shouting about how badly they have been treated in the databinding stakes. Tell them they can use VFP as an example of how it is possible to do it.
Promote VFP as a helper tool
VFP is a great tool to use along side Visual Studio. I’m not trying to convince .Net developers to change over to VFP, but there are plenty of benefits they could derive by having VFP as a helper tool, including:
– Need to write some quick SQL Server unit tests? Use VFP to setup test data. Then use VFP to make SQL SP calls and check the data returned.
– Need to pull out some data into a spreadsheet – use VFP.
– Need to script some updates – VFP is great as a scripting tool, similar to a scripting language like VB script.
– Need to check if a COM object is installed – try a quick CREATEOBJECT call in VFP.
Promote VFP as a prototyping tool
VFP is a great tool for .Net developers to be building prototypes in. Whip up a form, throw on some controls, bind to some example data, deliver the app to the client in a tiny installer, etc
Spread the message
This is not a new appeal. Craig Boyd (and even myself) have called for action from the VFP community to help let other developer communities know some of the great stuff VFP has (if for no other reason than they can then put pressure on Microsoft to hurry up and get it into .Net {s}).
However, the message comes down to dispelling a few of the misconceptions about VFP. Here’s a few things we need to promote:
– VFP works great with .Net
– Sedna actually focusses on .Net interop
– VFP is an awesome connector to SQL Server
– VFP has inline SQL calls
– VFP is well supported and continues to improve
Wrap up
After reading my post I’d understand if you thought I was anti .Net. In fact, the opposite is true – for example I look after a team of 15, over half of which are .Net developers. We do a lot of ASP.Net, SQL Server and BizTalk development. But we also do a lot of Visual FoxPro development. My concern is over the perception VFP has and the longer term issue we will face getting more VFP developers. Hence my interest in improving the perception VFP has.
Your thoughts
If you are a .Net developer and can spare a minute to send me your thoughts on what you think of VFP and what it would take to convince you VFP is cool, I’d love to hear from you. You can email me (cb@talman.com.au) or leave a comment on this post.
Acknowledgements
Paul Stovell and Adam Cogan have given me heaps to think about, much of which has ended up in this post. Any biases, inaccuracies or perceived hostility is totally mine though.

 

49 comments

Leave a Reply to JVP Cancel reply

  • One of the best VFP related blog posts I have seen in some time. It is well laid out and sound arguments throughout. Great job Craig!

  • One of the best VFP related blog posts I have seen in some time. It is well laid out and sound arguments throughout. Great job Craig!

  • Just a correction to one thing you said here…

    VFP code IS MANAGED. VFP has been doing managed code since it was released. VFP has its own garbage collector too.

    The main difference is that the code doesn’t run in the .Net CLR but the VFP runtime which are essentially the same. Of course the .Net CLR does have many more features it is basically the same.

  • Just a correction to one thing you said here…VFP code IS MANAGED. VFP has been doing managed code since it was released. VFP has its own garbage collector too. The main difference is that the code doesn’t run in the .Net CLR but the VFP runtime which are essentially the same. Of course the .Net CLR does have many more features it is basically the same.

  • I was going to say exactly what Anonymous just said: VFP code is Managed Code. It just isn’t .NET code. Everything that can be said as reasons why “managed code” is good, can be said of Foxpro, and has been since day 1. A while back I tried to get MSFT to start calling the runtime the “FoxPro Virtual Machine” so that it would be placed in the proper perspective (“the java/.Net runtime is *how big*?” ) but in hindsight the term “virtual machine” seems to have lost its lustre so perhaps that was a good call after all.

  • I was going to say exactly what Anonymous just said: VFP code is Managed Code. It just isn’t .NET code. Everything that can be said as reasons why “managed code” is good, can be said of Foxpro, and has been since day 1. A while back I tried to get MSFT to start calling the runtime the “FoxPro Virtual Machine” so that it would be placed in the proper perspective (“the java/.Net runtime is *how big*?” ) but in hindsight the term “virtual machine” seems to have lost its lustre so perhaps that was a good call after all.

  • Hi Anonymous and Colin,
    Yes, you are absolutely correct, and I should have clarified that part in the post.
    However at CodeCamp and the like, whenever developers use the term ‘managed code’ the understanding is that it is ‘obviously’ {g} referring to .Net code…

  • Hi Anonymous and Colin,Yes, you are absolutely correct, and I should have clarified that part in the post. However at CodeCamp and the like, whenever developers use the term ‘managed code’ the understanding is that it is ‘obviously’ {g} referring to .Net code…

Archives