i will tell you one thing about VFP future, you may surprised but it's TRUE
" VFP will be the MOST common language through the next 5 years " how ? i will answer you
until now we now three type of database applications (Desktop,Client-Server & Web applications), VFP is nice in Desktop applications and helpful in Client-Server beside SQL Server & Oracle and not bad in web applications( there are support for web service). but VFP not like .NET languages. the direction of VFP + VS.NET + SQL Server = "GREAT PROGRAMMING TOOLS" is common but for VFP Developers the others see VS.NET + SQL Server = "Great" , and they ignore VFP, because they don't know it. this is the present, but what about the future ? the future is not only "Web Applications" , there are
1 - Internet (2) & Grid Computing 2 - new programming paradigm replacement for Object Oriented
Visual FoxPro will be the best programming language that support the technology of the future, but this will not depend on VFP team in microsoft , this will be the job of open source programmers (using VFP)
Object Oriented which is the BASIC BLOCK of VS.NET is not so nice as we want from modern programming paradigm , OOP was very nice in the world of GUI and Information systems due to it's features (Encapsulation, Inheritance, Polymorphism, Composition, ...etc)
but now we need new programming paradigm which take in mind (Complex data structure, event-driven,client-server,distributed systems, embedded systems , Grid Computing)
there are now 3 new programming paradigms ( Agent Oriented, Language Oriented & DoubleS (Super Server) )
AOP & LOP are away from our discussion , SSP (DoubleS Paradigm) will target VFP SOON
and this new programming paradigm will add new power to VFP so it will be the better programming langauge
the new paradigm is based on a lot of new concepts (OOP Simulation , Networks, Servers, Chemial System, Electrical System, Human Interaction)
http://www.sourceforge.net/projects/doublesvsoop
this programming paradigm need contributes from professionals VFP Developers , it's BIG project
the advantages of the new programming paradigm
1 - OOP simulation but better than Pure OOP
1 - 100% OOP Power 2- Reduce need to inheritance by 50% 3- more encapsulation
4 - ***Dynamic classes*** which can be created and deleted like OBJECTS in runtime
2 - take complex data strucure in mind (Structue programming ignore data structure, OOP present only encapsulation for it, but SSP
present organisation, virtual database mangment system for it based on chemical system
3 - take event-driven in mind 4- take client-server in mind (veto system) - best than AOP in that point
5 - and more... THAN I CAN WRITE (THERE ARE 43 PAGES DESCRIBE ONLY WHAT IS DOUBLES ? )
DoubleS paradigm support now xBase languages like Clipper,xHarbour & xBase++ and will target VFP soon.
---
I agree about a bright future for VFP apart from MS in the form of Open Source developments. Look for VFP to be more like a PHP or PERL type language with many developers the world over making improvements and the whole community benefiting. Once this gets rolling enough, MS might even jump in and help out.
Tuesday, September 9, 2008
The most ambitious post I've found (Thread: MSDN Forum)
From here:
On the old line "Many old Fox apps still run." (Thread: Microsoft)
From here:
Financial Investment companies here in the US often use the phrase "past performance is not an indicator of future returns". The same holds true with software. Just because old applications continue to run fine does not mean they will continue to do so in the future. For example, there are currently issues with FoxPro and Visual FoxPro running on Vista. I doubt Microsoft will go back and fix these issues with Fox versions that are no longer supported.
---
As far as Vista is concern, there is still hope of SEDNA update which will make foxpro interface similar to vista. Beside VFP will work on Vista (as 32 bit). But still we dont know what will be there after Vista.
---
We have been a VFP shop for almost 10 years. It is a great environment for quick development and stable applications. That said, we're done with new development in VFP. Here's why:
-The won't be a 64-bit version. In my opinion, this is the biggest end-of-life indicator for this product--even more important than Microsoft's support until 2014. Sure Vista and server 2007 have 32-bit compabitility mode; but I expect by the next Windows OS releases (3-5 years down the road), running 32-bit software will be a dying trend. Some larger companies may even have initiatives to run 64-bit software whereever possible. Why process 1/2 the bits at a time when you don't have to? By 2014 VFP will be equivalent of modern day Cobol. There will be a bunch of legacy apps left that should have been converted years ago.
-Have you seen the new .NET 3.0 stuff? WPF offers extremely flexible anchoring capabilities--something that works okay in VFP, but not great. WCF Services offer new levels of sercurity and binding methods.
-DLINQ and XLINQ. These 2 language enhancements are going to save .NET developers lots of time. Simple tasks will be simple code. Plus there is a tool that will build business objects from a relational database.---
There are almost no new books...there isn't currently a plan for version 10...the publication we were getting for over 7 years became redundant and focused on specific uses with limited use...the newsgroups I watch have slowed down to a crawl--sometimes no messages for a several days...etc.
Another indicator--the Sedna code has to do with interaction between VFP and VS, but I haven't seen anything that gives VFP the ability to host managed code. We can access managed code, but we can't use the nice interfaces or benefit from the new controls. I think we're being quietly coerced away from VFP to VS. They're giving us tools that expose us to VS, but in truth they want us to see what we're missing. Maybe they're right. I haven't used VS enough yet to know for sure. I do know ClickOnce deployment is very nice. In 15 lines of code I can have my application automatically check for new versions upon load and update itself.
---
This has been almost a touchy subject for me. I started using foxpro about 3 years ago and as soon as I really got into it I was hooked. When I heard that VFP was being "phased out", I was, to say the least, somewhat devistated. I keep hoping to hear that Microsoft has changed their mind and will continue to release new versions, but I'm not as hopeful as I used to be. I haven't personally dived very much into the new .NET world yet, but I see that it is the way to start heading. Not only is there less support and less forums and what have you, there's also quite a lot less VFP jobs out there and most of them that you do find is usually converting legacy code as opposed to creating new innovative apps. I'm not really looking forward to it (yet) but I'm going to have to start really delving into .NET - gotta keep up with the times.---
Microsoft want everyone to believe that 64-bit is the way to go, but unfortunately this is a rosy-tinted view of the real business world. Companies simply do not upgrade hardware and software just because Microsoft release something new! Things like "Return on Investment" come into play and unless there is a good reason to spend money on new machines and operating systems it just wont happen! Imagine the cost of switching thousands of users over to 64-bit and then look at the benefit of spending that money....
---
Regarding 64-bit, I believe it's sort of over-rated and is being hyped pretty heavily. You know IBM AS/400s had 64 bit chips and OSs in the early 90s. Plus you just had to recompile existing apps to get them to run as 64-bit. While the AS/400 is popular with certain industries, I bet most people have never even heard of it or it's capabilities let alone beat a path to it to take advantage of the 64-bit capabilities. Some things I've heard about Intel/MS 64-bit - it will only have advantages for extremely large databases and may actually slow regular applications...
Rant & Responses on MS's "practice of killing markets" (Wiki: Fox.wikis.com)
From here:
The xbase market is gone. VFP's xbase roots are an irrelevancy or even possibly a negative in 2002. xbase was once the king/queen of development options and "FP vs dBase" the battle of the titans. Their demise was never on technical grounds, driven by politics and marketing until only MS has a mainstream tool in the area.
The "lay to waste" description isn't mine, but the once awesome xbase arena is certainly down to one. Sure MS continues to support this solitary player but it also does its best to promote the excitement in the theatre next door... and the audience (and we) respond to that. -- John Ryan
VFP represents the last bastion of the mid-range database/application development environment market. That's the category Microsoft is bent on destroying. This isn't about xBase, it's about the huge segment of the "database" market that once thrived with products like dBase, Clipper, Clarion, Delphi, FoxPro etc. I think you all know exactly what I'm talking about, and it's ridiculous to lump products like Access and SQL Server into this crowd, denying the existence of a very substantial and distinct category of which VFP is a part. It's also ridiculous to pretend that Microsoft is allowing this segment to thrive with its ongoing "commitment" to VFP. What a joke! Isn't it completely obvious what's going on here? They can't be too blatant about it, so they pretend to support VFP with one hand, while they hold it back with the other. Pretty soon the last vestiges of any competition wither and die, and then oops, well I guess this segment just happens to disappear altogether. Didn't everybody know we'd really be better off paying annual licence fees for SQL Server. So what if everyone loses, so long as Microsoft wins, right? Hey, this is business, so anything goes if it helps the bottom line, right? All's fair in love and war, but what about business? Say, isn't that what anti-trust laws are all about? Doesn't the notion of a competitive marketplace figure into this somewhere? Are the interests of society as a whole really being served by allowing Microsoft to kill off every category of software that doesn't fit into their plans for world domination? VFP isn't dying a natural death, it's getting a daily dose of arsenic from Microsoft, and if you guys are too dense to see that, you'll just have to wait for the autopsy report.---
Just because xBase used to be the "king" of data base apps it doesn't mean MS "killing" xBase is a bad thing. What langauges got left behind? The ones that didn't go OO. Thats not MS's fault, in fact, according to your logic you should be praising MS for making it OOP allowing it to stick around while its competition died. Also, as far as databases go, VFP's database is not the future. Sorry, thats the truth. The complete lack of security and maintainablility issues compred to MSDE or SQL Server make this xBase product a tough sell, especially in the middle of Microsoft's new "awakening" in security with "trustworthy computing"---
I just recently trained some public sector employees on SQL Server access from VFP. They were awestruck by the ease and simplicity of remote views AND the choice to use SQL dataset or xBase record oriented data manipulation from there. VFP database is an unsecure, weak and unreliable data store for anything but small apps, but the VFP cursor manipulation with SQL backend data can't be beat. If for nothing else, I sure hope VFP stays around for a long time for the middle tier. I see its benefits mainly in the middle tier data manipulation, secondarily as a way to create self contained and inexpensive database program solutions.
Friday, August 15, 2008
Les PInter on selling VFP apps (Post: Paalbalk Huissen)
From this thread:
Les Pinter has a nice strategy for selling VFP apps.
He first shows to his audience, most likely managers and budget-responsible people, the whole myriad of classes and possibilities of VB.Net of C# or whatever they can come up with.
He is driving them crazy with all the things you can do in .NET to a point where they ask him for a price to develop that must-have application XYZ.
He gives them the price and the time to deploy the app and tells them there is an alternative.... and then says, "nahhh, you probably won't be interested, it will cost you only 25% of the price I just mentioned but it won't be interesting of you". Well, those budget-responsible people ARE interested then, and then he shows them his "special framework, developed in C++, AKA VFP".
He drives their minds to a boiling point with another show-off from VFP and compares that with the things he just showed to his audience. And shows that it is indeed, remarkably quicker, and, what's more, cheaper!!
Poster disses YAG (Post: Spock of Vulcan)
From this thread:
Personally, I think it is a disservice to the Fox community that you are still around. Ever since you came to Microsoft, you have done nothing but try to kill the product and continuing your involvement will certainly ensure that happens. Please let someone with true interest in the product and community take over responsibility for Fox's future.
Win32 & the future (Posts: Mike Helland)
From this thread:
I recall Jim Alchin saying at a meeting "Nothing will happen to Win32."
If that's true, Microsoft ensures VFP being around and functional.
If that's not true, and Microsoft blatantly lied (or rather, failed to uphold Mr. Alchin's promise), then the computer industry will ensure the proper hardware and software technology exists to keep running Win32, and thus VFP keeps running for decades to come.
Anyone "worried" about the future of VFP can stop ragging on Microsoft, because someone is out there stockpiling Intel Pentiums and Windows 2000 licenses and if Microsoft does "kill" VFP, VFP will be around and our existing source code will be viable anyways.---
Microsoft cannot kill VFP.
In order to do that they would have to kill Win32, which I doubt they would do.
And even if they do, the technology industry has invested in it to the point where Microsoft would be ordered by the courts to maintain Win32 (given the number of Win32 applications our government runs I find this somewhat likely) or by that time the industry will offer something like WINE2000, meaning we maintain Win32 itself.
It is true that "VFP is dead!" in the sense that we won't see exciting new versions.
But, I really can't think of any new features that would make or break VFP as a solution for a decade to come.
Thursday, August 14, 2008
VFP with .NET (Post: Rick Strahl)
Link
If you use VFP with .Net you're diminishing that platform's performance and scalability significantly. Many of the benefits you gain by using .Net in the first place just go out of the window. Second, using VFP COM objects with .Net is painful if you do anything non-trivial because there's no direct connection to those objects. You have to use Reflection to get to lower level objects/properties etc. or VB and Option Strict off which also is not what I would call an option. Can you do it? Sure. Is it easy to do it? No, especially not in the face of native code.
If you use VFP with .Net you're diminishing that platform's performance and scalability significantly. Many of the benefits you gain by using .Net in the first place just go out of the window. Second, using VFP COM objects with .Net is painful if you do anything non-trivial because there's no direct connection to those objects. You have to use Reflection to get to lower level objects/properties etc. or VB and Option Strict off which also is not what I would call an option. Can you do it? Sure. Is it easy to do it? No, especially not in the face of native code.
I think COM interop with .Net is a nice stop gap choice, but not a permanent solution. If you want to go that route than classic ASP is actually a better choice IMHO.
A lesson from Lotus 1-2-3 (Post: Steven Black)
From 2003:
I spent several days with a guy with a PhD in Operations Reseach from Stanford, and a internationally recognized specialist in transportation modeling, who was putting together a proposal to write a scheduling system for Canada's entire railroad network. Using what, you may ask? Using Lotus 1-2-3 version 1.x for DOS.....
...Lotus, it turns out, is plenty powerful to do the job. A killer was several versions into the project, when both Lotus and Excel became so bloated on the Windows platform that they just couldn't grind the mega-models anymore. Who knew? I bet that, before you read this epilogue paragraph, you thought you knew what the failure modes were. It was bloat, Bob. Now replace "Lotus 1.x for DOS" with ".NET" and realize that you don't have any control whatsoever over your life going forward. That boat ride (bloat ride?) is a billion-dollar illusion by a bunch of hacks who peddle technology with little or no insight into applications. No more, no less...
...Today's cool deal is *always* tomorrow's legacy nightmare...
...I reckon 80% of all .NET developers are taking a product that they know fundamentally little about and creating applications based on snippets of code they find in books and on the web. All of which were written by near-rookies at best. Those chickens, your chickens, will someday come home to roost.
Wednesday, August 13, 2008
Rich or Thin? (Blog: ISV Blog)
Excerpt from "Tech Corner - Rich or Thin?"
Browser-based applications are not going away. Client/Server applications are not going away. The technology you choose for your product should be able to do BOTH and also be build on a platform that will be adaptable (in terms of platform and form-factor [e.g. mobile devices]) to handle it.
Otherwise, you may find yourself behind the technology curve and therefore vulnerable to other companies with similar offerings who are on the technology curve.
On the lack of alternatives (Blog: ISV Blog)
Entitled "Foxpro is dead: which 4GL is next?":
Microsoft recently announced that they will no longer develop new versions of Visual FoxPro, once one of the leading 4GL tools. Who's next? Oracle announced last year they will no longer develop new versions of Oracle Forms and also other 4GL vendors including Uniface, PowerBuilder, 4D, Omnis and Magic have not been really keeping up with the market in the past years.
What I find fascinating is that these vendors are not coming up with good alternatives for the products they are discontinuing or slowing down development on. I asked a couple of ISV's that have products in FoxPro what Microsoft is recommending them, I was guessing Microsoft would be suggesting (and helping!) them to move to .Net but guess what? Microsoft is recommending them to become a reseller of their confusing mix of Dynamics products.
Really! Microsoft essentially started to compete with ISV's when they started building up their Dynamics portfolio: it offers: CRM, ERP, Accounting, Warehousing and more. Exactly the products ISV's where building very successfully in FoxPro. Microsoft buys FoxPro, kills it and recommends you to rewrite your products as enhancements to their offerings. Sounds like a brilliant strategy! Perhaps it's time to switch to a tool-vendor that doesn't compete with your core business!
The Problem with "Legacy" (Blog: ISV Blog)
Part of Tech Corner - The Problem With "Legacy"
If you don't change, you stagnate. It's bad enough in the "real" world - and forget about the technology sector. There are new acronyms and new paradigms every other month. There are young, hungry companies with zero technology bias, starting from scratch, with nothing to lose, nothing to convert and zero installed base. In short, they have no legacy to support.
A lot of ISVs have a problem. The 4GL that they've based their entire system on is either hopelessly out of date (Delphi, Oracle Forms); not being supported anymore (FoxPro); have a proprietary, non-SQL database (FileMaker, Progress, Access, Alpha 5); and/or have no way to support modern, standards-based technologies (web services, XML, HTML, PDF, etc.).
There are only two ways to go if you find yourself in that position:Option 1 is attractive because it doesn't involve any change on your part or your customers. The danger is that a new competitor will emerge without the legacy and packed full of the technologies and standards that customers are demanding.
- Do nothing and continue doing what you're doing
- Completely re-write your application in another more modern tool/technology
Option 2 is painful. It involves a learning curve, re-training customers, data conversion and much more. The payoff is that you re-vitalize your existing customer base, gain new market share, and continue to have the ability to provide value to your shareholders, employees and end customers.
It's a tough business decision, and by not deciding, you've already made your choice.
Monday, August 11, 2008
Interesting thought on future 32-bit compatibility (Post: Ken Murphy)
From Foxite:
Personally, I plan to continue to use VFP until something better comes along. VFP works VERY well when used in conjunction with backends like SQL, SQL Express Oracle, MySQL, etc. Indeed, because of VFP's speed, many developers (myself included) prefer to use VFP for the middle tier, even when using a dot Net front end. The only real worry is if MS decides to create an operating system that will not support 32 bit apps. The lesson they are learning with Vista should prevent this. (Vista sales are in the basement - there is really no business case for anyone to go and buy the "upgrade" from XP.) If MS creates an operating system that does not support 32 bit apps, it is unlikely that anyone will buy it. It would simply break too many mission critical apps.
VFP runs well in a Windows Server environment, so you will probably find that people will continue to use VFP for middleware. I do not see MS changing Windows Server to the point where it would not run a 32 bit app. Again, this would break too many mission critical apps. Their customers would flee.
---
On a personal note, if you are a young developer (or even if, like me, you can no longer be called young) you need to learn new languages.
The cost of a rewrite (Post: Ars Technica)
Plicker7 said:
It's not even about the database side of VFP, so much as the ease of use of the tool-set. We use VFP for the UI development and SQL for the back-end within our applications. We currently have users who have SQL 2000 and some that are using SQL 2005 with the same VFP developed UI.
In Jan07, we started rewriting the our primary product in C#. In 3 months, we have 7 dialogs built, only 257 more to go. I'm sure it will get faster as we've spent much of our time building the data-access layer, and working the CSLA framework into the design for the Business Object side. But it takes a ton of C# (or VB.NET) code to call a stored procedure, vice the one line of VFP with SQLEXEC() command.
To date, it has cost us 10K in components and tools to support the .NET product, plus the MSDN subscription, and 85K for a dedicated programmer for the .NET product.
The new application will look more modern and be built on a development platform that people know is being supported.
"Retired!" (Article: Michael Desmond)
From MCP Magazine:
"There's another theme here that's consistent across VB6 and FoxPro and Visual Studio as well. It's not just the language, it's the application model that goes with it. The language is almost incidental at that point. What you're really betting on is the .NET Framework."
O'Kelly points out that Visual Basic 6, Visual FoxPro and to a lesser extent C++ are being replaced by tools tuned for the managed code environment of .NET. "It's not Microsoft picking on the VB6 and FoxPro guys, it's that the industry has really moved on for productivity and robustness reasons, and Microsoft isn't doing this alone," he says.
---
"It's become less about individual productivity and more about what platform are you producing on, and then standardizing on that platform," Allen says. "Ninety percent of the developers that I've known for the past 15 to 20 years, companies are hiring them to do something with data. We wanted something better, not something different and harder to work with.
"FoxPro got caught in the mix because it was kind of the dessert topping, floor cleaner product," Allen says. "It didn't clearly fit into the developer realm and it didn't clearly fit into the end-user realm.
Allen, at least, saw the writing on the wall. He switched over to coding in C# and VB.NET, though he continues to use FoxPro for certain projects and as a prototyping tool before casting code in .NET.
---
In the paper, Hammond urges development managers to "triage their applications" and then commit to migrating, rewriting or replacing each one, based on what the assessment finds.
Hammond breaks the process into a four-square box, which helps managers plot their decision making based on the relative business value and technical health of the affected code. As shown in Figure 1, business-critical code (in the upper two quadrants) must be updated, whether via migration or a wholesale rewrite. Commodity applications can often be replaced by packaged solutions or simply left in place, depending on the quality of the code.
According to the report, well-structured and designed applications lend themselves to an automated migration process, using tools like Fujitsu CoolCat and Infosys VB Migration Workbench. Many applications, however, require significant manual tuning or even a full rewrite.
In all cases, Hammond stresses a phased approach, where applications and application modules are assessed and re-assessed as the migration effort proceeds. A collection of code that earned a deferral in the early stages of the process might two months later be targeted for a rewrite. To avoid scope creep, he suggests stabilizing the code base first on .NET Framework 2.0, then extending functionality from that point.
The Future of Foxpro (Article: Chad Hower, April 2, 2007)
From CIO:
From the comments:
I vividly remember what it was like to be in that position and I understand many FoxPro devotees are understandably upset. But logically, not only did the end of life for FoxPro make sense, but everyone, including the FoxPro followers knew that this was coming, regardless of what Microsoft did or did not say. When I mentioned this fact to some colleagues, the near-universal response was "What?! You mean FoxPro was still around?"---In addition, many FoxPro to .NET conversion consultancies have been around for several years. Quite bluntly, the FoxPro developers who were surprised by this announcement have had their heads in the sand.Microsoft has not only been moving away from native development (C++ aside) and focusing on managed code, but centralizing all development tools around Visual Studio. Gone are the days of maintaining and supporting dozens of separate specialized development environments.
To bring FoxPro into this fold would require FoxPro to be brought to .NET properly and for it to become part of Visual Studio. Either step would have drastically changed FoxPro in ways that would make the VB to VB.NET change look small in comparison. The end result may have shared a name with FoxPro, but it certainly would not be a FoxPro the FoxPro developers would recognize, and it certainly would not run existing FoxPro applications without massive changes.
While FoxPro certainly has some unique features, most of them are now or soon available in .NET. Projects like LINQ continue to reduce the unique advantages of FoxPro, and taken in conjunction with the advantages of .NET, a move to .NET is the natural evolution.---There is no reason to panic if you are a FoxPro developer or if you have FoxPro applications. I would strongly recommend against new applications in FoxPro for obvious reasons, but existing applications are not going to expire tomorrow.---Some may blame Microsoft for dropping yet another product, but in reality it was the market and evolution that passed FoxPro by. Microsoft only did what was obvious and everyone but the devoted could see was coming.
From the comments:
Everything Old is New Again (Newsletter: Dan Covill)
I found this in the San Diego VFP User Group's newsletter, dated April 2007. I thought it was well written:
Reading the comments following YAG's announcement (half of which,
interestingly enough, were in Spanish) brought Chicken Little to
mind. It was either, "Oh, my God! We're all going to be out of
work!" or, "I'm leaving Microsoft and rewriting all my applications
in PYTHON/JAVA for Linux/OS-X".
Come on, folks! While this isn't exactly _good_ news, it's not
like we haven't seen it coming for about ten years now. And anyone
who's "lost faith in Microsoft" over this has been asleep for a
long, long time.
Yes, we have a problem in future direction. It's doubtful that we
will be programming in VFP in the year 2025. (Okay, I myself won't
be programming in _anything_ by then, but you know what I mean.
) But there's no need to rush out and buy a copy of Python,
either (actually, it's free). Here's how I see it:
1. This is not a surprise. There is absolutely nothing in the
announcement we haven't known about for six months to a year.
2. VFP (with its unique data structure) is the ideal platform for
building custom apps for small/medium businesses. Microsoft not
only isn't into small business, they don't know anything about it,
which is why they never pushed VFP and are only too happy to end
it. But in spite of MS marketing efforts, there is a huge
installed base of dBASE/FoxPro/VFP apps out there, all running and
needing occasional repair or upgrade. And most of the owners are
NOT interested in paying you what it would cost to rewrite their
apps in .NET. It's taken 20 years to build all those apps, and
they won't vanish overnight. I'd guess you'll be able to find VFP
work for another ten years at least, even if FoxPro finally stays
dead.
3. I think it's entirely possible that, with Microsoft having left
the field, more alternatives may appear. dBASE is still around,
for example - their website talks about running under VISTA. Ed
Leafe and Paul McNett are still working on DABO (which is a VFP
clone written in Python).
4. You can't just translate a good VFP app to some other language,
because the magic of VFP isn't in the syntax (not that different
from BASIC, really), but in the conceptual framework. There IS no
other language that treats database fields as linguistic
primitives, allowing us to write code that is truly data-centric.
So you have to re-design the app with a new set of concepts, and
then write it in the new language. That won't be cheap.
In January 2006 I ran an item reporting that Visual FoxPro was
ranked 20th in the worldwide index of programming languages put out
by TIOBE.com. Well, guess what? As of today, VFP has fallen all
the way to 22nd! It's selling like hotcakes in China and India.
OK, enough. Like Pogo Possum, I advocate creative inaction. Don't
panic. Keep on taking good care of your employer/client's VFP
systems. You've literally got years before you HAVE to do
anything, give it some time to see what pops up. Remember, the
first ones to jump ship have the farthest to swim.
Thursday, August 7, 2008
Interesting remarks on legacy tech (Posting: Hal Kaplan)
From this thread:
When I was a newbie, I worked for a company that kept two RCA Spectra 70
systems around way past their useful life because the systems hosted two
applications: Billing and Payroll. The programs were written in COBOL.
But it wasn't just COBOL or Spectra 70s. It was the disk drives, and
the printers. This company made several deals with the devil to keep
these machines going. It just could not bring itself to cutting the
cord. The vendor (Sperry) FEs would spend hours each week scouring the
nation for spare parts. We had printer ribbons up the kazoo stockpiled
because they were generally unavailable. Oh yes, they kept the
programmers around too (sweet job, I guess). And they postponed the
demolition of the old corporate headquarters to avoid having to move the
Spectras.
So I guess times are changing, but why do they have to change?
If you have an application running on a computer configuration today and
that running application is producing a meaningful product or service
for your company, why do you need to switch? When did the "upgrade or
lose support" gene become part of our collective DNA? Support is an
issue for immature products. When was the last time you actually got
support from M$ that was of any value? Probably shortly after you
upgraded (or updated) your system and the recent change was not yet
ready for distro.
The real problem here is not M$ but Intel. M$ stuff will only work as
long as Intel (or AMD, I suppose) produces a product that will bootstrap
the way it does today. Yes, one minor circuit change and everything,
including Linux, will fail. And that failure will be a lot harder to
overcome than if M$ changed one line of code.
VFP & its EULA (Thread: Leafe.com)
From this thread:
My feeling is that if your app is working, there is no need to panic
and abandon all that good, solid code because they finally made official
what many of us have sensed for quite some time. Given the number of really
smart people who use Fox, I'll bet that even if Microsoft doesn't do it,
someone will figure out a way to make VFP run on future OSs. Remember, the
fast CPU fix didn't come from Microsoft, but it enabled old Fox 2.x apps to
run on hardware well past the lives of the products.
---
If you look in the VFP EULA:
"Section 4.
You may not:
* work around technical limitations in the software"
I think you must admit that this is the equivalent of disabling your
software i.e you can't use it legally, and it covers a number of other
scenarios.
All Microsoft have to do is to place a "technical limitation" on the
software - whatever that means to them at the time.
Yes, I admit that this would be unlikely (I hope) but it shows what you
agree to when you accept the EULA. Just what is a "Technical Limitation"?
---
UK law (which overrides the EULA :0 ) says that you can reverse
engineer any software to resolve a bug.
The killer is that you dont own the tools just licence them and they
have the right to cancel your licence at any time for any reason. This
is the same for nearly all business software (in volume terms very
little is released outside this licencing model yet).
In the UK you can challenge this as being punitive but I dont know of a
case going to court.
---
Have you got big enough pockets to take a test case to court?
I guess not and that is where M$ will always win out - unfortunately.---
"It's great to see the brain-dead requirement of having to uninstall
previous versions has been removed. However, there are some really
bizarre new phrases added. Rush Strong points out the weirdest: "You
may not.. work around technical limitations in the software," Excuse
me? That's how I have made my living for the past fifteen years. VFP
doesn't include your inventory system, but that's a technical
limitation I can help you work around. Yes, it's true that DROP TAG
ALL will remove all relations, but I know of a product that works
around that technical limitation� VFP crashes when used with some HP
drivers, but there's a technical work-around on the Microsoft
KnowledgeBase that lets me work around this technical limitation."
"I find it hard to believe that such a silly requirement could be
enforced in court. On the one hand, OJ was found innocent and Sacco
and Vanzetti executed. On the other, Microsoft was found guilty,
guilty, guilty. I have neither the money nor the interest in finding
out what is and isn't enforceable in the EULA! But I think a lawyer at
Microsoft needs to be flogged for writing such nonsense."---Once MS started putting silly, meaningless phrases in their license,
it was obvious they were not interested in doing business with people
who wanted to use their product. Imagine your corporate attorney
asking you "Did you work around any technical limitations in the
software in the course of developing this application?"
Good advice for programmers re: languages (Posting: Larry Bradley)
Comes from this thread:
...If you can write apps in VFP, you can write apps in anything...Once you know HOW to write programs, learning a new language and applying it is easy.
VFP is actually a lousy programming language - it doesn't protect you from
yourself, like a lot of modern strongly-typed languages do. It is easy to
shoot yourself (and your client) in the foot, or other more tender parts.
If you are successful with VFP, you should have no problems with Python,
C#, Algol, ... (add language flavor of the month here).
The development environment is a lot more important than the language. ...
Don't get hung up on "I'm a VFP developer". You aren't. You are an
application developer. And you can develop apps in any language that meets
the client's needs. It might take you a while longer than if you did it in
VFP, which we all know like the back of our hands. There is going to be a
learning curve. But you can do it.
But if a client's needs might be best satisfied by using Delphi, why not?
You don't need to be a one-tool application developer. A carpenter would be
in deep doo-doo (sawdust?) if he only had one saw. Put several saws in your
toolbox, and get out there and build things.
Why not use some of your spare time taking a small VFP app that you have
written, and convert it to some other language? Python/DABO? VB and mySQL?
Make it a web-based app, using PHP and Apache and mySQL? C# and SQL Lite?
No need to despair. There will always be more work out there than people to
do it.
A VFP Guru's advice for the future (Posting: Whil Hentzen)
Come from this thread:
There are two schools of thought here. The first is to be an expert in a
language, and when the call comes for help in that language, you hold up
your hand and yell, "Pick me! Pick me!"
The other is to be a domain expert (auto parts, insurance, factory
automation, pet store inventory...) and develop 'solutions' for that
domain. The tool(s) you use are (mostly) irrelevant.
I've always been a door #1 kind of guy, fortunate that I can pick up
specific domain knowledge quickly and effectively. I like it because
it's really interesting; on the factory floor with the Archie Bunkers
and Homer Simpsons one day, in the bank's currency exchange back office
with the vapid young pretties the next. Lot of variety.
_MY_ plan (as I've stated in public many a time, although a few
disgruntled folks have chosen to selectively edit what I've said to suit
their own means) is to maintain VFP for years, but not to invest in it.
Rather, spend spare R&D time in a _growing_ market opportunity.
LAMP is the way to go as far as I'm concerned. I see MSFT's attitude and
approach being a losing game. They're nasty and don't offer good value
(anyone out there feel that a Vista upgrade is money well-spent?) The
reason they're still making money is because people don't have much of a
choice.
LAMP offers opportunity and freedom... oh, enough of that soapbox.
What's really compelling about the 'AMP' part is that it's cross
platform. MySQL, PHP and Python (and Apache, actually) all run on
multiple platforms, which is nice, since suddenly your skills are
xferrable.
I'm certain I'll be selling VFP books and doing VFP maintenance in 2020,
but I don't see a big benefit in becoming a Sedna expert. Maintenance
means remembering ON KEY LABEL, not MSFT's du-jour incarnation of COM,
some obscure hook between VFP and something else.
Thoughts from a young programmer (Posting: Derek Kalweit)
From this thread:
...if...you're young like me(20's). I've used
many languages over the past 10 years and primarily code in VFP and
VC++; VFP being the one I spend the most time with. I work at an
employer with VFP, and I work on the side and develop applications for
sale.
Personally, I have to think about the next 30 years or so of my
career(retiring right before January 2038 at the latest), unlike most
people here. I have to think of what I can write applications in for
my side business, ignoring any marketing hype(consumers rarely care),
but I also have to keep a pulse on the job market for software
engineers in my area.
With this dual requirement, I've decided to pursue .NET. If I look at
the software engineer positions being advertised around here, they're
JAVA, .NET, and C/C++ predominantly. Most of the JAVA stuff is high
level enterprise stuff which I've had some experience with in the past
and hated. .NET is my choice to learn more of right now and start
coding new applications in, as I think it makes the most sense for me,
financially/career-wise, going forward.
As much as I might like open-source stuff such as DABO and so on,
there are almost no jobs available in my area for such. Even Ed
himself doesn't have any paying Dabo work-- if one of the creators
can't get any, why would I think I can?
Think it through and try to make the best decision you can going
forward. At our age, the worst thing we could do is hide our heads in
the sand and think we can trek through with VFP alone for the rest of
our careers.
The Effects of MS's Actions (Posting: Robert Jennings)
A posting from this thread succinctly details the repercussions of MS's actions regarding VFP:
It may be fine for a programmer who goes from company to company to pick up lots of languages and write software in them (Which is fine) but my problem is that I have applications that I have out in the Market, we have over a thousand sites/ships using our software.
Prior to 2000 the company had software written in Clipper running in DOS.
VFP was the natural progression to provide the software on the Windows Platform. (yes a rewrite was required from the ground up) Saying that, it took 2 years to Migrate 1 application from Clipper to VFP.
We have had 9 years since the first VFP code was written. We have 6 Products that have progressed immensely since 1998. We have libraries of functions that work providing the meat of data manipulation and the interface presenting the data to the user. Many of the systems have been modified to meet user requirements.
Suffice to say, that I don't think that there has been a month gone by when the software hasn't been worked on to provide a customer modification or upgrades. There are 3 full time developers working on this software. I would say that 21 Man Years are invested into our software in VFP.
Granted, the software does need overhauling, made to be more oop, separate the Interface from the Data and make it work with a SQL server (any flavour) (we are still using VFP Tables!) Rewriting in VFP would be much faster as a lot of code can be copied over. We could have created the separate layers and we would have gone to version 2 of our software without a problem (well, I'm sure there would have been a couple but not too big!)
Now lets look at what Microsoft have done.
Driven the nail in the Coffin of VFP. They will not sell it, the will not Open Source it. The language, DBMS et al will go. At some point and they can't confirm when, their operating systems will not support the VFP runtime. Yes granted, it may be 2020 before that happens, but I'm astounded that there is not an upgrade path. If they rolled VFP into .NET then fantastic, I should imagine that we could have ported our applications.
Now lets look what I face.
Move all my applications over to another Language e.g. Dabo, .NET (any flavour), Python etc etc etc.
This is going to mean that I have to stop the Modifications and Upgrades to my applications while I (and the rest of the team) re-write the applications (6 of them) from the ground up. This is going to cost my company at least £200,000 ($400,000) for every Year it takes to re-write (Wages / Lost potential earnings in Modifications & Upgrades). I think it will take 3 of us at least 3 years to re-write all 6 modules. 9 MAN YEARS if we are flying.
The new software will not have all the modifications for clients who will one day have to move over to the New application, then there is going to be a backlash from them as I'm going to have to charge them to modify the software to do exactly what they want.
We are a small company, because of Microsoft actions our profitability is going to take a big hit. Our customers are going to see a slowdown in our reaction times (which at the moment is lightning) and they will face a bill to upgrade once we have re-coded. Companies are going to have less confidence in our products because they know that Microsoft is stopping support for VFP in 2015. If we had a rough date by which time VFP will no longer work on the VFP platform at least we could reassure customers slightly.
If we go over to .NET will Microsoft Kill that at some point?
Can Microsoft be more specific when they will pull the Plug on VFP running on Windows Operating Systems?
Wednesday, August 6, 2008
On Announcement (Thread: MSDN Forum)
Highlights from this thread:
They have invested a lot of money in VFP over the past 15 years and a lot of VFP technologies are used in other Microsoft tools - especially RushMore optimization and, I believe, also parts of the VFP ISAM and its CURSOR engine. So even if MS do not want to develop VFP any further, it is unlikely they would release it to a potential competitor.
As I said elsewhere:
Viewed objectively this is no surprise at all. About the only thing that would make any sense for a new "VFP 10" version would be a complete re-write from the ground up to make it a full 64-bit application. Given the revenue model for VFP (i.e. ZERO!!!), and the fact that Microsoft's preferred strategy is to sell SQL Server Licenses, that would make no financial sense whatsoever, and there really isn't (from Microsoft's perspective) a business case for a desktop database. Remember, Microsoft is NOT a software company, it is a primarily a Marketing company in the business of making money!
And before we start the "Sky is falling" chorus, just consider how many people are still using VFP 6.0 (never mind 7.0 or 8.0) - a version that was released 8 years ago and is no longer even supported. Now add in those who still use FP DOS, and FP 2.6W (products that died 12 years ago) and explain to me why this actually matters?
Just because Microsoft say they won't release a Version 10 doesn't mean any of the following:
- that VFP is going to stop working
- that its data handling and integration capabilities have gone away
- that the reasons that you chose VFP as your development tool to begin with have changed
- that you can no longer create and distribute royalty free EXE data-based applications
- that the capabilities and extensibility that make VFP the most powerful desktop database have changed
I have always tried to use the best tool for the job at hand. I will continue to do so, and as long as the best tool is VFP then that is what I will use!
---
...The sky is not falling, the sky is changing ... just that. And us as developers must adapt to the change. Now is a new ocassion to see what is out there, to think in new possibilities, to see the world from a new perspective. Since two days, now I'm considering cross platform products (Win, *nix and Mac OSX) thing I never planned before ... so this can be a good opportunity to see that live is out there.VFP will still be the best desktop database development environment. People will still develop in a good product like VFP. We will have time for see alternatives to Fox.
But now things are changing.
---
Access is not the answer. It is morphing into some kind of Sharepoint database.
FoxPro type queries are already coming in .Net. Look carefully at LINQ. It does VFP type queries and more.
Also, keep a close watch on the next two or three versions of VB.Net. You'll be very surprised by how much it looks like VFP.
---If microsoft are going to desert there long serving user base then I for one will be deserting Microsoft and will look at a non microsoft replacement.
---
That's a very unprofessional response. Many years ago, Ford discontinued producing the Escort, even though at the time, it was the best selling car in the world. Did that mean people should stop buying Ford?
You should use the current tool that is best for your customers.
---
I don't disagree that you should use the current tool that is best for your customers, but your customers are also sometimes other businesses with IT departments or someone on staff who will say "We don't want any FoxPro apps from a dead language" From the standpoint of being as marketable as possible FoxPro does me little good. It's actually a hinderance in some cases since so many people who really know little about FoxPro cringe when they here it's name mentioned. Whether I like it or not in order to continue my career as a programmer it's either .NET or Java.
---
You Guys are just wrong….
You do NOT use the best language for your client! You use the best language for your business. That entails the ability to resell and extend any code you write for YEARS to come. Foxpro was no longer that language as soon a MS announced it would never go 64 bit.
I cannot and will not build my business in such a way that I can only support my current clients and can’t take on new ones. I must plan for the future. By the time 2015 comes around Foxpro 32 bit will be what Foxpro 16 bit is to day.
Good luck selling a new client on any DOS app today, Good luck selling any client on a 32 App in 10 years, regardless if they heard of FoxPro or not.
Its time to move on……. In fact we’re VERY late.
Ps : Sedna is joke….. It’s just a scam to get FoxPro programmers to learn .NET.
---
That's why alot of VFP developers are now considering Open Source. It just doesn't seem right that a company can pull strings with a development language like VFP. Such a thing could not be done with PHP, Perl, Ruby-On-Rails,etc. because no one company controls them. Gee, it would be nice if VFP were like this too. And what if MS decides VB.Net is not "strategic" in 3 years and it would be sooo nice if they only had 1 language, C#?
---
We cant stop times... VFP it'snt the language of future... I know only vfp, but now i MUST learn not only another developer language but "how" developer... The future is programs that run in a browser but are quick as a stand-alone procedure. Programs that run on all platforms (OS and DB) and integrated with most distributed software... (Print in pdf format and in RTF, export in excel/openoffice, send email with mapi method and with HTML Mail) VFP is sufficient now for this, but the future needs another structure.
Tuesday, August 5, 2008
VFP & Linux (Blog: Ted Roche)
Link
Highlight:
Highlight:
With the recent VFP9 EULA (I still haven’t seen it online), someone asked if that meant that VFP is dead on Linux. Frankly, I’ve always thought of it as more of a parlor trick than a viable platform for development. I mean, if the vendor really doesn’t want to run on the many other operating systems out there, that is their choice, even if they are cutting off their nose to spite their face. The other answer is one that Paul points out in the white paper on his site: you don’t need to run VFP 9 or 8 or even 7 to get most of the benefits of VFP. If you are running (or at least distributing) VFP 6 level applications, the EULA had no noxious requirements about the operating system. As always, you should consult a lawyer about this, but it looks good to me…
On Announcement (Blog: Ted Roche)
Link
Highlights:
Highlights:
Unlike the Open Source world, when a vendor choses to discontinue a product, developers have little choice but to move along. While many folks point out the upside that the product will likely run for years to come, and a lack of Microsoft official support doesn’t instantly obsolete a product (DOS apps can still be found, after all), there is an immediate slowdown in the custom software market, and a longer-term turning away from the product by customers. Large-scale vertical products have to be operating with 5- and 10-year plans for reinvestment and changes in direction, to ensure they can fund “The Next Big Thing” while continuing to deliver good value to their customers today and tomorrow.
This is not a death knell for the product. The writing has been on the wall for years. But developers with large applications have to be looking around for a new platform.
VFP as a threat to SQL Server (Quote: Les Pinter)
Link
He quoted a senior Microsoft official [who claimed to be quoting Bill Gates] as saying that "every VFP license sold represents a loss of about $10,000 in SQL Server license fees"
Discussion
He quoted a senior Microsoft official [who claimed to be quoting Bill Gates] as saying that "every VFP license sold represents a loss of about $10,000 in SQL Server license fees"
Discussion
Hi Jim (and others on this thread). Please do not believe everything you
read as-is without any validation. I don't know who Les Pinter talked to
here, it probably wasn't an executive and without names, the quote is
really meaningless. I've never heard a quote or anything like this from
anyone at Microsoft at any level. -- Ken Levy
---
Actually, chances are that for every license of VFP, hundreds of SQL Server licenses may be sold!
---
The way I heard it, the "unnamed source" WAS another high level m$
executive...not from Redmond...
On Announcement (Blog: ISV)
Link
Highlight:
Highlight:
Microsoft buys FoxPro, kills it and recommends you to rewrite your products as enhancements to their offerings. Sounds like a brilliant strategy! Perhaps it's time to switch to a tool-vendor that doesn't compete with your core business!
Monday, August 4, 2008
Thursday, July 31, 2008
Converting from VFP to Access?! (Site)
These guys were advertising on Amazon. It's the first time I've ever heard of anyone doing such a thing. I wrote to them, and here's what they said:
We use the linked-tables and ODBC features in MS Access, and we have yet to come across a version of FoxPro to which we couldn't connect. So, all versions of FoxPro.We can convert to MS Access 2.0, '97, 2000, 2002/XP, 2003 and 2007.
Wednesday, July 30, 2008
Insight into VFP Studio (Posting: Matt Slay)
Link:
I think I know what this is going to be... Listen to the recent Ken Levy podcast on DotNETRocks.com show # 303. I bet Craig is using the Visual Studio IDE shell and the Visual Studio Extensibility (VSX) kit to somehow work with VFP code/forms/reports/ etc. The title of the show is "Ken Levy on Visual Studio Extensibility (VSX)" It's a great show, and really gets your mind to thinking about how cool it is that the Visual Studio 2008 IDE shell can be extended to many uses. They even mention Craig Boyd and Foxpro near the end of the show. DotNetRocks is usually hard (and clueless) on FoxPro, but it pops in there every now and then.
I think I know what this is going to be... Listen to the recent Ken Levy podcast on DotNETRocks.com show # 303. I bet Craig is using the Visual Studio IDE shell and the Visual Studio Extensibility (VSX) kit to somehow work with VFP code/forms/reports/ etc. The title of the show is "Ken Levy on Visual Studio Extensibility (VSX)" It's a great show, and really gets your mind to thinking about how cool it is that the Visual Studio 2008 IDE shell can be extended to many uses. They even mention Craig Boyd and Foxpro near the end of the show. DotNetRocks is usually hard (and clueless) on FoxPro, but it pops in there every now and then.
VFP Studio (Links)
The mysterious home page
and
what's sure to be a dead link once things are revamped: a mysterious login screen
and
what's sure to be a dead link once things are revamped: a mysterious login screen
VFP Studio Details (Posting: Craig Boyd)
Someone reposted a post by Craig Boyd:
"Using Microsoft's DLR it is absolutely possible to integrate .NET with VFP. Right now we are concentrating on getting it to work with native VFP code, however we are planning on implementing .NET into this as well so that the language/development tool ends up being very similar to VC++ where managed and unmanaged code can co-exist. So, those looking to do just pure VFP will end up with a greatly enhanced IDE and some additional language features that we are adding and will be able to compile to standard VFP executables/dlls/apps. And, those wishing to use VFP and .NET together will be able to do so as well. The latter will greatly extend the usefulness and future of VFP/VFP Studio and the applications created with it by allowing VFP devs to generate .NET assemblies. The overall goal is to marry the best of both worlds and allow VFP devs to access their beloved VFP runtimes providing applications with unrivaled data performance and access .NET to take advantage of all that is available there as Microsoft moves forward with the CLR and DLR.
We'll be revealing more as we move forward with this."
VFP Studio Code Editor (Blog: Craig Boyd)
From the posting:
Some of the mystery surrounding VFP Studio has been on purpose and some of it has been because we (Bo Durban and I) are not yet sure what all is possible working within the framework provided by Microsoft via the Visual Studio Isolated Shell.
---
VFP Studio's Code Editor, which is made possible via a Language Service Bo Durban and I created in Visual Studio 2008, provides some significant enhancements when compared to the editor included in VFP 9.0 including outlining, Quick Info, Intellisense for user-defined classes, line numbers, word wrap, VS-style navigation bar, improved Code Snippets and various other features we are implementing in to VFP Studio.
On VFP Studio (Blog: Alan Stevens)
Link
Our project is called VFP Studio. We are using the Visual Studio 2008 Isolated Shell to build an IDE for building Visual FoxPro projects inside Visual Studio. We have plans to include reg-free COM for enabling click-once deployment of Visual FoxPro applications. We are working on a VFP project type, so that we can add a new or existing VFP project to a Visual Studio solution. We keep coming up with exciting possibilities for this project, and we will be announcing more soon.
Tuesday, July 29, 2008
Windows 7 & VFP (Thread: MSsForum)
Users discuss compatibility:
As Win7 is being built on top of the Vista kernel and code base, my guess is
yes.
---
If there is going to be some support of the product until 2014 then I would
imagine that any MS OS that comes out prior to that should run VFP.
---
VFP on Linux (Thread: MSsForum)
Link
Finally, someone speaks out strongly against the MSBS regarding licensing:
Finally, someone speaks out strongly against the MSBS regarding licensing:
Some of those links are dead. The ones that live don't really settle the
matter, nor is this matter every likely to be setteled until someone
actually goes head to head with Microsoft (which is very unlikely to
happen). For fear of beating a dead dog - Ken Levy's "opinion" that the VFP
runtime files that a VFP app requires to run is considered a redistributable
file is not supported by the wording of the eula or the contents of
redist.txt. I've been saying this for a few years now, and the comments you
can find on the referenced website below say pretty much the same thing.
This is why we, and many others, have had this conversation over and over
again :-)
Debate over VFP's future (Thread: MSsForum)
Thread where a user asks about Foxpro's future.
Highlights:
Highlights:
Is there a future for VFP? In your larger shops and mainstream IT in
general, VFP is dead. Those still using it are migrating away from it as
fast as they can. Few if any IT managers are going to risk their career by
starting new development using VFP. VFP apps will be around for many years
to come, but they will continue to dwindle in numbers as they have been for
the last few years.
In the Mom and Pop shops, you will still see some VFP apps for a few years
to come, but even they are going to move away from it.
It's dead and just waiting for someone to come along and bury it :-)
---
The community is making VFP better. See the VFP projects on Codeplex etc.
The community always made vfp better anyway, not so much the microsofties.
PHP has not done so bad without a corporate sponsor and VFP is way better
than it...
---
The biggest problem VFP has
ever had is Microsoft. Get rid of them, and VFP could prosper. And it would
be cross-platform again. Think about it - VFP on Linux would become very
popular very fast.
---
But, as has been repeated often before, it is not an option to say 'get rid
of M$'. This implies that 'we' have any power over it. The product belongs
to them, and they decide what happens to it. They are not going to release
vfp in a million years because of the code within it they want to retain
control of.
---
IT managers that decide on technology because of the impact on their
career have switched in the 90ties. IT managers today are either younger
folks that replace VFP centric managers. Those usually switch to whatever
technology they learned during university/college. Older IT managers that
are still supporting VFP applications decide, in my experience, on technical
terms rather than career terms. Frequently this means to keep maintaining
existing projects in VFP and start new ones in .NET or Java.
If there's budget for a rewrite, it depends on several factors what they
choose. .NET/Java is typically choosen if the budget is sufficient for a
rewrite and managers expect to keep working for a longer period. Often it's
not a single project that is the reason not to go with VFP, rather the
possibility of having training being paid by this project. If the budget
isn't huge, the application is data bound and very inexpensive ($50-$500 a
year), the time to retirement isn't that long (10-15 years) or development
resources are expensive, managers tend to stay in FoxPro (VFP and FPD). That
seems to be the case the farther you go away from the US. My impression is
that the most active VFP communities are in Asian, Eastern European and
Spanish speaking countries.
There's alaways a problem with generalization or drawing a bigger picture
from individual incidents. However, one of my clients sold another license
of his DOS application a few weeks ago. Sometimes getting work done for a
low price is more important than a modern looking UI.
VB 6 is dead and see how VB developers refuse to accept that. ;-)
Friday, July 25, 2008
Any Future for FoxPro -- Do I switch? (Thread: MSS Forum)
Link
Highlights:
Highlights:
If you've written a lot of VFP
code that surely will be your
"funds".
Can you afford throwing that away?
Is there really a need to work with
another programming language?
and do your customers care if
your software is written with X
or Y?
---
Listen, don't start wiggin' out now. The VFP community cannot be canned and
tossed out - keep writting until the OS can't support it I say.
I currently don't see a reason to bail out of VFP and start from scratch
with a new language. And finally, because MS says they are not releasing a
new VFP doesn't mean it will die. You never know what will happen.
---
MS Stopped development on VFP cause IT IS CODE COMPLETE-
i.e. - ya don't need anything else in it, to use it as a development tool.
---
Even if they ultimately come out with a non-VFP friendly OS, it still may be
possible for someone to write a "compatibility" box that allows the legacy
application to run. That would seem to be an easier task then rewriting VFP
or switching to something else.
Thursday, July 24, 2008
Fox technology to be integrated into MS products (Blog: Craig Berntson)
Link
The article, Microsoft to Serve Up SQL Server 2005 Preview, includes this paragraph (emphasis my own):Sources said high-level Microsoft architects are focusing on how "Orcas," the follow-on version of Visual Studio, will more easily and efficiently handle data via future versions of both Visual Basic and Visual C#. In fact, Anders Hejlsberg, a top Microsoft software architect, is working on Visual C# 3.0 and has produced compiler technology that accelerates data integration. The Visual Basic team is working to deliver similar functionality, based on Microsoft's FoxPro technology base, sources said.So, Fox, while I believe won't be available as a separate product, will live on. It will be reincarnated as something different -- new data manipulation and access technologies in Orcas.
Fox is Dead, Long Live the Fox (Thread: TheMSSForum):
Link
Highlights:
Highlights:
This is a nail in the coffin. I don't read "will run on 64-bit Windows in
32-bit compatibility mode" as a statement of improving VFP. I see it as a
VFP-friendlier phrasing of what is more likely the case--that Longhorn was
planned so that you won't have to scrap your legacy systems, yet. I recall
getting beat up when Win95 had rolled out and we were still developing our
product in 16-bit FoxWin. It's just one more shortcoming for a competitor
to point out. A statement like that would make me VERY jittery about
starting any new development on a product that has stated no plan to make
use of the future of Windows architecture.
VFP is too good of a language to "deserve" this, but I don't have any reason
to believe that MS has any intention other than letting VFP slip into COBOL
status. :-(
---
Although they say there are no plans to merge, a de facto merge could be
coming, if only because dotnet copies Fox's features.
---
For those who find the work, it will
probably become more and more lucrative. And for that same reason, someone
will very likely continue to build add-ons or other ways to work with it.
But over time, very few new endeavors are likely to be undertaken by
companies that do not already have other VFP ties. And for those that do
decide to replace their legacy apps, VFP looks less likely to be the
language of choice. And, while I'm sure MS didn't build COM Interop into
.NET specifically to crush VFP, it provides at least some easing of such a
path, should a company decide to replace existing systems.
Wednesday, July 23, 2008
Vienna (Windows 7) to run 32-bit Apps (Blog: Andrew MacNeill)
Link here
In response to a ZDNet article which states:
Craig states:
In response to a ZDNet article which states:
Like Vista, Windows 7 will ship in consumer and business versions, and in 32-bit and 64-bit versions.
Craig states:
This suggested to me that realistically, 32-bit apps have a future life-span of 10, maybe 15, years.
Friday, June 6, 2008
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:
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:
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.
Thursday, June 5, 2008
"Are You More than Your Language?" (Article: David Stevenson)
by David Stevenson
Highlights:
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:
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.
Wednesday, June 4, 2008
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:
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.
Subscribe to:
Posts (Atom)
