marwk@levels.sait.edu.au (04/25/91)
I have seen a listing of bugs taking up about 1/2" thick of paper. This is too many to post to the net, so I'll compile a new list once 5.01 fix disks reach me, and we can all eagerly find out which ones are really fixed and which new ones they have introduced. I like CLIPPER, but hell, didn't they actually try it out before boxing it? What happenned to their beta testers? Quality control? Too much pay and not enough workers? Too any chiefs and not enough indians? Or perhaps the indians think they are chiefs? If I wrote a solution to a practical and it had bugs, the students would jump up and down about the quality of the staff here. What if Holdens made afew thousand cars where the left indicator lit when you intended to turn right, some had the steering wheel fall off while turning a corner on the main street, or a wheel seized up on the highway, or perhaps the breaks failed going down a steep hill, or the seat fell through the floor leaving your knees dragging along the ground ... Wh didn't they just send me tha manual, that would have been jmore sensible, rather than send me two sets of disks - I can use them for backup disks when the real ones arrive, I suppose. Ray -- University of South Australia | Plus ca change, plus c'est la meme chose. P.O. Box 1 | Ghing thien me how, ming thien gung me how. Ingle Farm | Knobs, knobs everywhere, South Australia | just vary a knob to think!
tleylan@pegasus.com (Tom Leylan) (04/26/91)
In article <16244.2816c071@levels.sait.edu.au> marwk@levels.sait.edu.au writes: >I have seen a listing of bugs taking up about 1/2" thick of paper. > >This is too many to post to the net, so I'll compile a new list once >5.01 fix disks reach me, and we can all eagerly find out which ones are >really fixed and which new ones they have introduced. > >I like CLIPPER, but hell, didn't they actually try it out before boxing it? > >What happenned to their beta testers? Quality control? > <and more stuff....> Ray, I think you're exaggerating just a bit but in any case your timing isn't too good. The update disk to 5.01 has been shipping for a few days and reports are that people are receiving them. Most of the reported problems were due to the VMM system which by all accounts did not receive enough testing. It isn't an excuse but a buggy VMM system which accounts for 90% of the problems isn't the same as bug riddled software (at least in my book). VMM underlies Clipper 5.0 so if 2 or 3 or 50 (I'll let you decide) bugs in there would show up all over the place. I have seen VMM errors but very few, some people hit them all the time and usually this has been due to their not writing code in 5.0 but merely recompiling S'87 code. Again, no excuse but that has all been fixed in the update. The update is free of course. From a computer language fundamentals standpoint I think Clipper 5.0 is a mile ahead of the rest of the dLanguage pack. Lexical scoping, the pre-processor, code blocks and the pseudo-objects offer more control than anything in it's class. If Clipper can't do it, drop down to C or assembler and link it in. I think you'll be pleasantly surprised with 5.01. BTW, you aren't the only person disappointed with the initial release, lots of us make our living programming in Clipper and it sets everybody back but I could see that the basics were there and trusted that in time the fix would arrive. As for your Holden example... what if they built a space shuttle and it exploded on take off ? Car manufacturing isn't compiler writing and you don't think that Nantucket is the same size as General Motors do you ? It will all get better soon... tom (formerly of Nantucket Corp. (a full disclosure tag line))
tomr@dbase.a-t.com (Tom Rombouts) (04/30/91)
In article <16244.2816c071@levels.sait.edu.au> marwk@levels.sait.edu.au writes: >I have seen a listing of bugs taking up about 1/2" thick of paper. > >This is too many to post to the net, so I'll compile a new list once >5.01 fix disks reach me, and we can all eagerly find out which ones are >really fixed and which new ones they have introduced. > >I like CLIPPER, but hell, didn't they actually try it out before boxing it? > >What happenned to their beta testers? Quality control? >Too much pay and not enough workers? >Too any chiefs and not enough indians? >Or perhaps the indians think they are chiefs? [ rest of post deleted ] IMHO, unless you are writing shareware-type programs as a form of hobby from your garage, there can come a time when you have to ship something, _anything_, just to keep the payroll met and the doors open. One can hardly say Clipper 5.0 was rushed to the market, the date and time stamps on the original 5.0 disks are exactly one year later than the ship date predicted by a highly visible Nantucket executive the year before. (This was a minor joke - the punch line being that if people complained that it was late, one could say that the predicted ship date involved an "off by one" error.) Let's face it - dBASE IV 1.0 hurt Ashton-Tate greatly by being released in a less-than-perfect condition. On the other hand, the amount of changes involved from III+ to IV represented one or two quantum leaps in complexity from any revision of any dBASE or dBASE-like product that had been done before. As we approach the ten year anniversary of the IBM PC this August, the micro software history is littered with many products that were hyped or touted by marketing types that were disappointments when they were released. (Who remembers the $10 million dollar promotion of DayFlo?....) In fact, for those who complain about the primitive combination of the IBM PC architecture and MS-DOS, this, too, can be viewed as an after effect of something being rushed to the market. For those reading this outside the realm of commercial software development, the software buisness involves tradeoffs and monetarily based decisions just like any other. Also, in a volatle industry such as ours, many smaller firms sometimes feel forced to make louder claims to avoid being drowned out by the bigger entities. I'm not saying any of this is "right", or trying to endorse some form of "Software will always have bugs - c'est la vie!" attitude. To the contrary, every developer I know hates glitches in their work and tries as hard as they can to eliminate them. But, this has gotten away from comp.databases, perhaps. Also, it is my own opinion and does not represent any views of any known corporate entity. I now step back and let the product wars continue. Tom Rombouts Torrance 'Tater tomr@ashtate.A-T.com
shevett@mccc.edu (Dave Shevett) (05/03/91)
In article <1991Apr29.170439.10591@dbase.a-t.com> tomr@dbase.UUCP (Tom Rombouts) writes: =In article <16244.2816c071@levels.sait.edu.au> marwk@levels.sait.edu.au writes: = [comments about Clipper 5.0 being released prematurely] = =[...] there can come a time when you have to ship =something, _anything_, just to keep the payroll met and the doors =open. I agree with this 100%, to a certain extent. However, Nantucket planned this release for, what, 2 years before it left the offices? In that time, didn't it dawn on them that they *may* not make the deadline, so let's cut back the final version, and get something out that works? (See Novell's software release system. SFT wasn't working, so they kept bouncing it back revs. They put something out, and it *worked*, even though it was not what was originally announced.) =date and time stamps on the original 5.0 disks are exactly one year =later than the ship date predicted by a highly visible Nantucket =executive the year before. This I think it hitting very close to the mark. Why did Nantucket announce a release date for a product that was, obviously, nowhere *near* ready for release? Was this executive completely blind? =Let's face it - dBASE IV 1.0 hurt Ashton-Tate greatly by being =released in a less-than-perfect condition. On the other hand, =the amount of changes involved from III+ to IV represented one or =two quantum leaps in complexity from any revision of any dBASE or =dBASE-like product that had been done before I'm sorry, but this is where I almost coughed up my coffee. The number of changes from III+ to IV are not relevant. There is little code included in IV that can call it's origins from dBase III. I call your attention to FoxPro. It was released virtually bug free, was a complete re-write of FoxBase, and is about to be supplanted with FoxPro 2.0, another complete overhaul of the core database code. I think what we can derive from this is that it's not the complexity of the code that causes problems, it's how it is managed and marketed from the top. =To the contrary, every developer I know hates glitches in their =work and tries as hard as they can to eliminate them. I agree. This is working from the 'developer's point of view. The problem is, too many corporations let the lawyers and accountants start running the company, and it loses it's shine. Example: Fox vs A-T, Borland vs Lotus, Apple vs everybody. =But, this has gotten away from comp.databases, perhaps. Indeed, but I am curious how others perceive this 'who decides when to release a product' problem. =Tom Rombouts Torrance 'Tater tomr@ashtate.A-T.com ,___, .--------------------------------------------------------------. \o.o/ | Dave Shevett | Unix-PC BOF | The shortest distance between | ( \_/ ) | Lawrenceville,NJ | TCF '91 | two puns is a Straight Line | |_|_| | shevett@mccc.EDU | Apr 20-21st | -- Doc Webster | '--------------------------------------------------------------'