aiko@cs.odu.edu (John K Hayes) (07/11/89)
The following is a reply to Kieth Broussard who responded in defense of Ashton
Tate to a previous posting of mine about the flaws of dBASE IV.
To: Keith Broussard <keithb@hpindda.hp.com>
Subject: Re: Re^2: dBASE IV - is this for real?
I think you're a little confused. I am not some person who has just started
using dBASE last week, decided it was garbage and then went on a WARNING
SPREE. I have been been using dBASE since '85. I started with dBASE II. This
was a very annoying thing to program in because of its severe limitations as
far as programming go. It did take care of a whole lot of things to do with
database file management, however, that I then did not have to concern
myself with. So I put up with the limitations. Then came dBASE III+. This
was a vast improvement over dBASE II. Most of the limitations of dBASE II
were eliminated or at least expanded upon. I was very pleased with the
upgrade from dBASE II to III+. Then I began using Clipper which expands a bit
on III+ and speeds things up immensely (plus I'm actually using a bonafide
REAL compiler - you see, I spent 5 years in school getting a degree which is
mostly concerned with programming using compilers).
Then, not too long ago, along comes dBASE IV. After seeing the vast i
improvements III+ made over II, I was excited about it. Someone upstairs had
a copy of it so I went up and had a look. It LOOKED very nice. As it is
very hard to get a complete feel for a new package until you actually start
using it for a while, all I saw was this superficial improvements to the way
it LOOKED and I did not notice that it was actually a slowed down heap of
garbage - so I went ahead and bought it.
Instead of making vast improvements over III+, it seems that with IV Ashton-Tate
has taken a package that ran very well, reasonably efficient for an
interpreted system but one that left a little to be desired as far as
asthetics, and totally transformed it into a package that IS more asthetically
pleasing to the eye but is NOT EFFICIENT. This is clearly MIND-BOGGLING.
How could they be serious????? I am not saying that there are bugs in the
system (although there may be few - I have seen none). I am saying that the
system itself is flawed and they knew this when they released it. It is
flawed in that it is a step BACKWARD from III+, not in that it does not
work. That is why for me, already having III+, IV is totally worthless. The
screens are very pretty, but waiting SO LONG for EVERY LITTLE THING makes me
want to smash the thing to little bits and burn the documentation. And that
logo screen and license agreement is just too much. I go into and out of dBASE
all day long - I really don't have time to look at that idiotic crap. This may
sound trivial to you - but I do not have 20-30 seconds to stare at that BS
every time I want to go into dBASE. It makes me lose my train of thought and
it's just goddamned irritating.
Can you tell me this - can you name ONE IMPROVEMENT IV made over III+????
--
---{john hayes} Old Dominion University; Norfolk, Virginia USA
internet: aiko@cs.odu.edu
Home: (804) 622-8348 Work: (804) 460-2241 ext 134
<++++++++++++++++++++++++++++++++++>
Are you a Have or a Have_Not? Because if you're a Have_Not, you've probably
had it; whereas, if you're a Have, you've probably got it and are going to
give it away at some point in the future! --- The Clash
<++++++++++++++++++++++++++++++++++>awd@dbase.UUCP (Alastair Dallas) (07/13/89)
I should learn to IGNORE people who capitalize words rather than provide SPECIFIC CRITICISMS that can be refuted or confirmed, and who conveniently ignore tips on how to avoid annoying screen animation... But I can't resist: In article <9467@xanth.cs.odu.edu>, aiko@cs.odu.edu (John K Hayes) writes: > Can you tell me this - can you name ONE IMPROVEMENT IV made over III+???? > ---{john hayes} Old Dominion University; Norfolk, Virginia USA > internet: aiko@cs.odu.edu > Home: (804) 622-8348 Work: (804) 460-2241 ext 134 A file that dBASE III PLUS takes 55 seconds to LIST takes only 22 seconds in dBASE IV. That's ONE IMPROVEMENT. I could go on, of course. /alastair/
aiko@cs.odu.edu (John K Hayes) (07/17/89)
In article <154@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >I should learn to IGNORE people who capitalize words rather than provide >SPECIFIC CRITICISMS that can be refuted or confirmed, and who conveniently >ignore tips on how to avoid annoying screen animation... But I can't >resist: > >In article <9467@xanth.cs.odu.edu>, aiko@cs.odu.edu (John K Hayes) writes: >> Can you tell me this - can you name ONE IMPROVEMENT IV made over III+???? >> ---{john hayes} Old Dominion University; Norfolk, Virginia USA >> internet: aiko@cs.odu.edu >> Home: (804) 622-8348 Work: (804) 460-2241 ext 134 > >A file that dBASE III PLUS takes 55 seconds to LIST takes only 22 seconds >in dBASE IV. That's ONE IMPROVEMENT. I could go on, of course. > >/alastair/ BIG DEAL. Who wants to list files to the screen so they fly past without being read? If you look at useful processing tasks - such as simple BROWSE operations - IV takes about TWICE AS LONG as III+. -- ---{john hayes} Old Dominion University; Norfolk, Virginia USA internet: aiko@cs.odu.edu Home: (804) 622-8348 Work: (804) 460-2241 ext 134 <++++++++++++++++++++++++++++++++++> Are you a Have or a Have_Not? Because if you're a Have_Not, you've probably had it; whereas, if you're a Have, you've probably got it and are going to give it away at some point in the future! --- The Clash <++++++++++++++++++++++++++++++++++>
keithb@hpindda.HP.COM (Keith Broussard) (07/17/89)
DBase IV's addition of the VALID clause to the @ SAY...GET command combined with a user-defined function makes my life WORLDS easier! Try emulating that with other commands... Keith
awd@dbase.UUCP (Alastair Dallas) (07/18/89)
In article <9520@xanth.cs.odu.edu>, aiko@cs.odu.edu (John K Hayes) writes: > Can you tell me this - can you name ONE IMPROVEMENT IV made over III+???? In article <154@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: > A file that dBASE III PLUS takes 55 seconds to LIST takes only 22 seconds > in dBASE IV. That's ONE IMPROVEMENT. I could go on, of course. In article <9520@xanth.cs.odu.edu>, aiko@cs.odu.edu (John K Hayes) writes: > BIG DEAL. Who wants to list files to the screen so they fly past without > being read? If you look at useful processing tasks - such as simple BROWSE > operations - IV takes about TWICE AS LONG as III+. BROWSE on an indexed 25,000 record file takes less than a second to Page Down, and approximately a second to Page Up (scroll backward). dBASE IV is slightly slower than III+ at this because IV's BROWSE is much more powerful and flexible. IV's BROWSE has pull-down menus which support file navigation without leaving BROWSE; you can BROWSE in one window while you do other things in other windows, and so forth. How important is 77/100th of a second versus 93/100ths in an operation that is user-bound anyway? LIST is a more useful measure of a data engine's performance because it involves indexed record retrieval without much screen I/O overhead. In contrast, BROWSE has line-drawing overhead but also pre-fetches while waiting for keyboard input. If you don't think that LIST is BIG DEAL, how about SORT? A 1,000-record file takes 5:77 seconds to SORT in III+, but only 4:90 seconds in IV. Ashton-Tate is very concerned about the performance of dBASE--we may be conceding "the fastest" to others for now, but we are committed to being the fastest with the most-est. That is, there may be other vendors offerring a subset of dBASE IV that runs faster, but no one offers you a faster IV. We have run hundreds of benchmarks on dBASE IV and when I tell you that IV is considerably faster than III+, I know what I'm talking about. By the way, these timings (and the previous numbers cited) were done by me--ad hoc--on the Compaq 386 next to my VT100. I'm not releasing Ashton-Tate numbers, I'm performing research that John Hayes could do almost as easily. All I ask is that attacks on Ashton-Tate or dBASE employ at least a modicum of scientific method. If you say that FoxBASE+ sorts faster than dBASE, you won't get an argument from me. If you maintain that III+'s data engine is slower than IV's without providing a shred of evidence, that's something different. /alastair/ Disclaimer: Comments about what "Ashton-Tate" is concerned about and committed to notwithstanding, these are my opinions only and should not reflect upon my employer in any way. When I say performance is important to A-T, it is from the standpoint of a day-by-day observer of the company, nothing more.
emuleomo@yes.rutgers.edu (Emuleomo) (07/19/89)
In article <3520004@hpindda.HP.COM> Keith Broussard writes, >DBase IV's addition of the VALID clause to the @ SAY...GET command >combined with a user-defined function makes my life WORLDS easier! BIG DEAL!! That was __Stolen__ from CLIPPER and FOXBASE+.!!! --Emuleomo O.O. (emuleomo@yes.rutgers.edu) -- ** Research is what I'm doing when I dont know what I'm doing! **
emuleomo@yes.rutgers.edu (Emuleomo) (07/23/89)
In article <349@rls.UUCP> you (Randall Smith) write.. >Uh, who stole what from whom? Althouh I use Foxbase, it seems turnabout is >fair play. While I'm on the subject, doesn't it seem glorious that the >various litigants in numerous "look and feel" suits have only benifited by etc..etc.. Hear, HEAR. Since UDF's and Array processing came from Clipper, does it now seem very reasonable for A-T to be suing left,right and center? I have hope for A-T though. Alastair Dallas (An A-T GURU) wrote that A-T is committed to being the fastest dBASE-language vendor!! That's great. However I wish them luck. >Another for the Foxbase people. Has anyone heard of a case where >procedures execute and return nicely in small filtered sets, but large >filtered sets hang in the same procedure? That is, they do not return to >their calling module. Although I don't know why you are experiencing that problem, I DO KNOW that Filters are a VERY BAD IDEA. They are performance HOGS. If you remove the filter statement and simulate it, you will be SURPRISED how much FASTER your application will run!!! >Emuleomo O.O. (emuleomo@yes.rutgers.edu) -- ** Research is what I'm doing when I dont know what I'm doing! **
jbrown@herron.uucp (Jordan Brown) (07/25/89)
emuleomo@yes.rutgers.edu (Emuleomo) writes: > Although I don't know why you are experiencing that problem, > I DO KNOW that Filters are a VERY BAD IDEA. They are performance HOGS. > If you remove the filter statement and simulate it, you will be SURPRISED > how much FASTER your application will run!!! People keep saying this, and it just isn't true. Filters are stupid, yes, but they aren't any slower than doing the SAME STUPID THING that they do. If you truly simulate a filter, you'll get the same speed (only slower). Sure, if you use indexes you'll win big. If you "know" that after a certain point you can stop examining records you'll win big. But for a general-purpose function with no knowlege of the behavior of the query, filters don't do anything particularily horrible. With some clever query optimization they could be a lot better. They'd probably be buggy and require more memory too. SET FILTER TO <cond> LIST should be *exactly* as fast as LIST FOR <cond> Similarly, SET FILTER TO <cond> GO TOP DO WHILE .NOT.EOF() ... process ... SKIP ENDDO should be *exactly* as fast as LOCATE FOR <cond> DO WHILE .NOT.EOF() ... process ... CONTINUE ENDDO and faster than "simulating" it by GO TOP DO WHILE .NOT.EOF() IF <cond> ... process ... ENDIF SKIP ENDDO (Which, by the way, is nothing like a full simulation as it doesn't handle backing up, seeking, etc.) A filter is an absolutely abysmal way to pick out a particular invoice from a line items table. It's not a bad way, however, to pick out all the people in California in name order using an existing "last+first" index. Filters are no stupider or slower than FOR clauses or LOCATE commands. I guess people just think that because they look like they happen at a lower level they should be magical. (Disclaimer, sort of... I don't have anything to do with AT any more, other than having some friends there. I'm even a competitor in some senses. However, I had a fair amount to do with the initial implementation of filters in dBASE III, and I'm tired of people griping that filters are slow when they are certainly NO WORSE than any of the other equivalent things in the language. They aren't the magical solution to all your searching needs. They are the WRONG WAY to do many things. If you want to argue that filters and FOR should do query optimization, fine, but recognize that query optimization is still an unsolved problem and is not trivial to do.)
randy@rls.UUCP (Randall L. Smith) (08/15/89)
In article <Jul.18.20.09.45.1989.2100@yes.rutgers.edu>, emuleomo@yes.rutgers.edu (Emuleomo) writes: > In article <3520004@hpindda.HP.COM> Keith Broussard writes, > >DBase IV's addition of the VALID clause to the @ SAY...GET command > >combined with a user-defined function makes my life WORLDS easier! > > BIG DEAL!! > > That was __Stolen__ from CLIPPER and FOXBASE+.!!! Uh, who stole what from whom? Althouh I use Foxbase, it seems turnabout is fair play. While I'm on the subject, doesn't it seem glorious that the various litigants in numerous "look and feel" suits have only benifited by the expanded market that they alone could never have developed? Ah, well. Um, technical type question. How does one retrieve command line switches for Foxbase and Ingres at execution time. I have two applications that have massive front end processing for integrety checks on startup. With command line switches, I'd like to disable that processing for testing purposes. Another for the Foxbase people. Has anyone heard of a case where procedures execute and return nicely in small filtered sets, but large filtered sets hang in the same procedure? That is, they do not return to their calling module. Please respond via e-mail and I will summarize or return mail depending on interest. Cheers! - randy Usenet: randy@rls.uucp Bangpath: ...<backbone>!osu-cis!rls!randy Internet: rls!randy@tut.cis.ohio-state.edu #disclaimer: All flames cheerfully refunded in the denomination of my choice.