I was once called on to consider rewriting a POS application for a major fast-food chain (years ago now). After I wrote up the design and showed them samples they were happy and asked me as an afterthought what language I was going to use. Immediately upon replying VFP they stated "NO WAY!" They had a 'DEVELOPER' (I'll call him a super-user MAYBE) that a wrote a program for them that was nothing but a grid for the users to key data into. They showed it to me and it was pretty embarassing. I informed them that IMHO whoever wrote that app was no developer but possibly an experienced user that knew how to create one control on a form (and then do nothing with it). I still giggle when I remember their response: "Go ahead because we love your sample app, but use the tool you used in your sample app and not VFP." My sample app was written entirely in VFP!


>>Terry,
>>
>>I agree fully. However, it may be that the programmer who delivers faster code is aware of speed differences between newer and older functions, and uses those differences to his advantage. That's what we're trying to find out in this thread.
>
>I don't think it's just knowing which syntax is faster. The integration of the the data (the design, structure and methods to access the data) with the syntax is crucial.
>
>One of my first employers sent me a school for nine months where the primary focus was good old fashion flowcharting. I cut my teeth on xBase II and old out of date computers (I was a humble guy then:-). Making those old computers seem like they were running fast was a second career.
>
>Many VFP developers refrain from using ActiveX because data cannot be bound to it. IE - one cannot simply SELECT into the a cursor and bind it to the control. The philosophy of those developers that do implement ActiveX and still rely on normalized data structures and optimized practices with syntax like SEEK and INDEXMATCH (etc) may be the ones dedicated to speedy applications. The others may be looking to the future as a manager or feel better [about themseleves] receiving a programmers check instead of a clerks.
>
>VFP is partially to blame - it makes it soooo easy to slap together a GUI and connect it to data - that anybody, with a few months of practice - can go out and call themselves a developer/consultant.
>
>In the states - during the late 80's and early 90's, individuals, calling themseleves software consultants, were out in the market slapping together grid and browse solutions. This hurt the market's perception of xBase (and VFP). The market had mistakenly concluded that the problem was the development platform and not the guy with the 80$ tie and crisp starched shirt that was billing them a 100$/hr. for software that smelled like last month's fish:-).
>
>Another issue is the OEM - wanting to sell high end backends (with low-end frontends), and trying to hide the fact that a product that can do it all (VFP) was even available.
>
>When I was younger - I believed that dedication, work ethic and long hours were all an individual needed to deliver value. As I age - it seems that experience [also] plays a big role:-).
>
>>
>>BTW, what's the meaning of SET RANT OFF?
>US Cable TV has a smart mouthed wise guy commedian (Dennis Miller), who would open his act by complaining intensly - he would start each diatribe with: "Now, I don't want to go into a RANT ..."
>
>Its equivalent to getting on a soapbox in a public area and espousing your position even if others do not want to hear it:-) The opposite of an "Auther McKensie" Beatles Elanor Rigsby, who was always "writing words to a sermon no one would hear".
>
>I lot of people I know wish I would be an Author McKensie:-). SO RANT OFF is a way of saying "Okay, now I will shut up" (err - set rant off)
>
>
>>
>>
>>>A software solution is an integration of programming engine functions, the architecture of those functions and user requirements.
>>>
>>>Two programmers, solving the same problem, can deliver different performances. I have been involved in projects where xBase was used to replace a C+ solution. The xBase system blew the C+ system away.
>>>
>>>Two programmers writing VFP solutions can deliver night and day performance. The macro VFP functions combined with exclusive use of SELECT statements on tables with every field indexed - and macro bindings - will run (maybe on the order of hundreds) slower that a VFP app that uses low (or core) functions.
>>>
>>>Most of the time - it's not what language or platform a developer uses to solve a problem - but the design and architecture of the system.
>>>
>>>It's like the pool hall story - where a guy comes in - and blows away the local talent with a broom handle instead of a queue.
>>>
>>>A solution that benchmarks well in string functions, tells us little about how fast the integration will perform - unless all the solution does is 'reverse' a string.
>>>
>>>Good holistic design practices + plus well positioned core functions = speed.
>>>
>>>SET RANT OFF
>>>
>>>
>>>>Hi to all who are interested in this topic.
>>>>
>>>>We have had an interesting discussion, including some research, under the topic 'VFP versus C++'. This new topic is kind of a continuation, but it has a slightly different focus. Al Doman postulates the hypothesis that the newer functions are faster than the older functions. See also his post: Re: VFP versus C++ Thread #842594 Message #843390.
>>>>
>>>>Several thoughts come to my mind:
>>>>- Is 32-bit versus 16-bit indeed a factor?
>>>>- Functions are unique, that is, no two functions do exactly the same thing. So, how can they be
>>>> compared with respect to speed?
>>>>- What is the hierarchy of the functions with regard to speed?
>>>>- Can we say that the newest functions compete well with the C++ equivalents?