====================================== FoxPro Developers Network of San Diego ====================================== FoxDev TipsLetter #99-2 FEBRUARY 24, 1999 Website: Editor: ---------------------------------------------------------------------- CONTENTS: * Calendar * Steve Settimi in the Vale of Tiers Review * Tech Tips: (none this month) * Other Stuff: More on VFP Timing Barbara Peisch More on VFP Timing Dan Covill Programming - MOL to SOL? The Old Curmudgeon Why Don't We? Steve Settimi * Administrivia ====================================================================== CALENDAR: March 3 "The FoxSolutions Application Framework" by Bill Heitstuman 7 pm at Solutions Consulting Group This is our new regular location, at 6540 Lusk Blvd. (across from Qualcomm). April 9 Note-This is a Friday. Peter Butterfield will return to show us his latest framework. May 5 Tim Daly, one of our new members will show us a Network Management System which he developed. ====================================================================== STEVE SETTIMI IN THE VALE OF TIERS by Dan Covill At our February 3rd meeting Steve Settimi once more braved the critics (easier when Eric's out of town!) to demonstrate how he handled a large conversion project, converting from FPW26 while simultaneously laying the groundwork for the 3-tier approach. The problem Steve had to deal with was striking a reasonable balance between conversion and improvement. On one hand, he had about 70 forms and programs to convert, so he couldn't very well do a lot of tweaking, but on the other hand he wanted to clean up the structure to set the stage for future enhancement in VFP. What he settled on, and demonstrated, was a simple customization of Convert.app The code for Convert.app ships with VFP 6.0. Steve modified it to prefix every procedure in the output with the name of the module, and insert comment lines in a specific format. He then wrote a parser that separated the (large number of) output procedures into four functional programs: a Visual UI (tier 1), a Rule Server (tier 2), an Ancillary Server (tier 2), and a Data Server (tier 3). The trick to making all this work was to define a standard way of communicating between the tiers. Steve's standard naming rules allowed him to write communication code that calculates the name of the corresponding module in the other tier, then calls it. At first, I had trouble understanding why Steve was doing what he was doing. Then it dawned on me that he wasn't designing a new application - he was trying to convert one (and a fairly large one) that was already running. So he couldn't just invent his ideal way of communicating between the tiers, or he'd never get it all to work. In my view, 80 percent of what he did was automated conversion, customizing Convert.app to establish control over method/procedure names. The rest was simply a first cut at separating the code into the tier you'd like it to be in. The weakness is that these converted procedures, no matter which tier they're in, are still calling whoever they used to, no matter which tier that's in. So encapsulation is breached all over the place, not by Steve but by the design of the original application. But you can't do everything, and Steve got his conversion done while introducing the tiered concept. [Note: The title of this review is due to Art Bergquist, who noted at the meeting that "Simplifying an application could mean shedding a lot of tiers"! He was also heard to mutter "Much ADO about nothing".] ====================================================================== MORE ON VFP TIMING by Barbara Peisch When I read Dan's results comparing a REPLACE command in 2.6 with VFP, I was amazed, and decided to verify those results myself. One of the things I suspected, is that Dan had used a 2.x table in VFP, and for that reason, VFP was slower. When I ran my own tests, I confirmed that VFP was using a VFP table and not a 2.x table. I still got the same results as Dan. This bothered me, so I posted a message on Compuserve asking why this should be. I got the following response from Christof Lange: "First of all, VFP behaves more co-operatively, which causes a general slow down compared to FPD (even in a DOS box). Especially, in my testing years ago I found that VFP sends smaller, but more packages across the network, which slowed things down quite a bit. Second, in VFP there's more involved: You have an additional buffer layer, there's a transaction layer, a table might possibly be part of a database, etc. All this requires more checking even with a free table." [Editor's note: I think Cristof is probably correct, but I don't consider a reason to be an excuse. The fact is that VFP took 15 times as long (!), and that's pretty hard to justify.] ---------------------------------------------------------------------- MORE ON VFP TIMING by Dan Covill Steve Settimi sent me the following e-mail: "Dan-- Attached is a sample program showing differences with delete set on or off and the affect of a DELETED() index, with order set on or off. Time results are in the comments." Of course (and like an idiot), I double-clicked on the attachment to read it. But it's a .PRG, so it executed instead. But it didn't display anything, so I put it aside to look at later. Later, I discovered a 10 Megabyte file I didn't know I had. Seems Steve's program starts by generating a 2-million record DBF! Thanks, Steve! When I figure out what it all means, or when Steve tells me, I'll put it in the e-letter. Should have it by next month. And all jokes aside, I do appreciate Steve's taking the time to contribute. ---------------------------------------------------------------------- PROGRAMMING - MOL TO SOL? When I started programming, back in the Pleistocene era, we wrote CPU instructions which we turned into programs with an assembler. This was called a "Machine Oriented Language", or an MOL, by later epistemologists (at the time we were too busy trying to make it work to worry about what we were supposed to call it). Then came FORTRAN and COBOL, which were called "Procedure Oriented Languages" (POL), again in retrospect. They were joined by such nearly-forgotten luminaries as JOVIAL, SNOBOL, ALGOL, BASIC, PL/I, and ADA. Procedure-Oriented one and all; you said it, they did it. The Big Shift (probably a Paradigm Shift, but of course we didn't know we were supposed to call it that) came in the late 70s, with the "Problem Oriented Languages", including such household words as FOCUS. Not coincidentally, the computational epistemologists appeared at the same time, inventing the retroactive labels to better describe just what it was that the new snake oil was better than. So there we were, evolved from the primordial soup of MOL to the POL pinnacle. I guess we don't use Problem Oriented Languages any more, at least I haven't seen anything called that for a long time. (We do, however, use FORTRAN, COBOL, and (God help us) BASIC!) Gazing at the entrails of various Visual FoxPro programs, however (and what a wonderful maze of entrails there are to gaze at!), I am tempted to divine that we have in fact entered, albeit unwittingly, an entire new class of programming languages, the "Structure Oriented Language", or SOL. Given the multitudinous and ubiquitous PEMs (you don't even have to create them, you get more than you can use for free), it seems to me that most VFP code is devoted to talking about its own implementation. The favorite VFP reserved word, hands down, is "this", followed closely by "thisform". Talk about narcissism! Next time you look at a VFP method/procedure, including your own, just check to see how many (if any) statements are concerned with the data or the problem, rather than with the mechanics of VFP. You won't find very many. While I do enjoy the irony (or absurdity) in this latest illustration of Microsoftian "progress", I am also trying to make a serious point. The purpose of a program is to accomplish something for the user, which sooner or later involves saving, retrieving, or manipulating some data to that end. It seems to me that the typical VFP "object method" is more involved in (figuratively) peering up its own anus than in dealing with the problem the program is being written to solve. That's why I call it a Structure Oriented Language (SOL); its primary concern is its own structure. Colloquial American English assigns another, non-computer meaning to the three letters "SOL"; I fear that one may apply to us also. The Old Curmudgeon ---------------------------------------------------------------------- WHY DON'T WE? * Why don't we ask members to contribute to a DBF of "Reported and Purported Companies known to be using VFP"; this to build a member-accessible DBF of potential employers/contracts? * How about some FPDN (pro-vfp) advertising in San Diego Business Journal? Steve Settimi (Board Member) --------------------------Administrivia------------------------------- This newsletter is a service to members of the FoxPro Developers Network of San Diego (FPDN). The editor (Dan Covill) is solely responsible for the content, Barbara Peisch does the distribution. E-mail the editor YOUR tips, comments, complaints, and rebuttals. Editor: Dan Covill 619-272-2448 Board of Directors: Eric Lendvai - President 760-439-6617 Art Bergquist - Vice Pres Claude Nikula - Secretary 619-615-6318 Barbara Peisch - Treasurer 760-729-9607 Randy Barber - Director 619-670-7542 Steve Settimi - Director 619-262-5883 ----------------------------------------------------------------------