Hey Malcolm, There are many people on this list (including me) that plan to do the same thing you are doing.
It would be nice if there was a translator. I probably would not use it for production code because translators are always (my experience) sloppy code, but I would like to see the Python code that does a function similar to vfp. I think a re-write is important, painful, but important. When I re-wrote all my old fpd code into vfp, it was painful and took a year, but now I have a much cleaner program. I think the same will happen when moving to Python. That was 10 years ago - time for a new re-write. Like you, I think almost everything could be done in python instead of using dll/ocx components with the stupid requirement to 'register' them. I wonder what idiot at Microsoft thought up that nonsense? ----- Original Message ----- From: "Malcolm Greene" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Sunday, April 20, 2008 9:32 AM Subject: Porting VFP apps to other languages - how big a deal? (was RE: VFPmarketing) Hi Bill, Like you, I sell a suite of proprietary products built on a huge code base of FPD, FPW, and VFP code. At the moment I'm aggressively studying Python as an alternative to VFP. While I haven't started to port any of my code yet, I'm beginning to think that porting my code base may not be the huge effort I originally feared. Why? Because what makes my products unique is their design and algorithms, not the actual plumbing. And I don't need to re-invent my design or algorithms - just the plumbing. One of the things I noticed when I moved my FPD/FPW applications to VFP was how much my code base began to shrink. Partially because I was cleaning up (refactoring) poorly designed code and partially because VFP simplified a lot of functionality that I had previously built by hand. I'm confident that I'm going to see the same type of reduction if I port to Python - especially in the fringe areas of my application that took me outside VFP's 'comfort zone', eg. web interfaces, regular expressions, os interfaces, etc. After studying Python and then reviewing my VFP code with a fresh perspective, I'm surprised about how much VFP 'cruft' is buried in my code. Cruft that is directly tied to the VFP language or workarounds for the VFP language vs. code fundamental to my application's logic. Bottom line: At this point, without having gotten my hands dirty yet<g>, I'm a lot more optimistic about the feasibility of porting apps from VFP to Python than I was several months ago. [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
