It's possible to get into an extended argument on just what constitutes a 4GL. Is RPG, for example, a 4GL? No? how about Mapper? and if not, where do you draw the line between the 3.X languages and a "true 4GL?" A clear answer exists - and I'll raise it tomorrow - but for now here's my working definition: it's a 4GL if, and only if, all of the following are true:
On this basis Unify's Accell was probably the first true 4GL, with a near clone, Informix 4GL a close second, Progress somewhere near the top of the list for the ninties, and Oracle Forms (with 4GL Developer) somewhere on the list but near the bottom.
By the same token Sybase's APT then, Powersoft's PowerBuilder (now owned by Sybase), and Software AG's Natural, like today's Visual Basic, don't cut it.
Of this group, the most commercially viable today is probably Progress -a language I didn't like at the time because of its resemblance to a Visual Basic Studio style IDE. Nevertheless, nobody denies, then or now, that it's a product that works, a product that meets the conditions I've set up for a 4GL, and therefore a product that can be used to answer the question: how buggy can 4GL prototypes be?
The answer is surprising: because the answer is that it's not easy to introduce bugs into a 4GL prototype.
Let me clarify: it's easy to omit functions, not complete a backend process, or introduce erroneous programming constructs - but it's very hard to take the thing for what it is, build a prototype with it, and then find a bug in what you've actually built.
Tested components and standard, event driven, actions translate directly to predictable application behavior.
If you know how to use a tool, you can use it to do the wrong thing, either explicitly or by omission. You can, for example, omit the residency information check before calculating a sales tax due, thus defaulting to the local rate at the point of system licensing - but you'll never find yourself bitten by a bug that causes the system to print receipts based on New York residency for Alberta residents buying a product in California.
Similarly, if you don't know how to use the tool you can spend time doing the wrong thing in the wrong way - some friends of mine who weren't getting along with their client assigned BASIC programmers to work with Accell for that client - and they spent hundreds of paid hours on projects like getting reports to print in the "right" date based sort order when all the client had to do to achieve this was set DATEFMT in user ~/.cshrc files.
So the real bottom line on testing 4GL prototypes is simple: if the users present during active prototyping told the programmer to do the wrong thing, if they missed something, or if some user assumption about input or output turns out not be universally correct - you have a problem to fix, but you don't have a bug and other users banging on the prototype will identify the problem almost immediately.
Basically, nothing that shouldn't be there or isn't there is invisible to a few hundred users.
On the other hand, if your developer doesn't listen to users or doesn't know how to use the tool, the prototype will not get finished within the window of user enthusiasm and therefore won't be used even if eventually finished.
Beyond that: getting rid of the waterfall process, eschewing redundant messaging interfaces, and by-passing the errors always associated with inter-personal communication as the application development process moves throughs its stages, removes most of the errors, costs, and frustrations associated with data processing style development methodologies.