Rapid Application Development

RAD is an acronym for Rapid Application Development, a style of development made possible by VisualBasic Smalltalk and BorlandDelphi and others, which usually contain all of the following capabilities:

FormBasedDesign lets you draw your GUI using simple click/drag without writing any code
VisualComponents containing many rich graphical widgets
NonvisualComponent?s containing database access layers and other features that can be used without writing very much code
FastCompilation or NoCompilation or ChangeAndContinue? - Waiting more than a few seconds after you change your code, to run your new changed application, is the primary inhibitor for the RAD mode of operation. A build procedure long enough that you have to GoGetACoffee is the antithesis of RAD.

Philosophically RAD has its origins in the Smalltalk language/environment. The RAD philosophy of software development either flies in the face of the old idea of writing a prototype and then throwing it out (PlanToThrowOneAway), or else it breaks PlanToThrowOneAway into smaller, more manageable component-sized chunks. The idea is use a language like SmallTalk or BorlandDelphi or VisualBasic, and then after the prototype, instead of chucking the prototype and starting over in C, you iterate on the prototype until you have a finished high-quality product.

This is criticized by some as encouraging sloppy development, and encouraged by others as being a way to develop programs more quickly and cheaply, without the attendant difficulties of writing GUI applications in the older more traditional ways.

What is an example of sloppy development that it encourages?

Mixing presentation code and business logic code (and sometimes, persistence code) is a primary CodeSmell found in code created with these tools.
This is often an artificial bogyman in my opinion. For one, the boundary between them is often blurry. Second, the "swap fear" probability of changing GUI's or what-not in the future is often exaggerated in my observation such that a cost/risk analysis does not favor heavy isolation. What is really desired is "dynamic aspect grouping", and not really "hard" separation. For more on this is SeparationAndGroupingAreArchaicConcepts. --top

What is there to be said in favour of throwing one away?

If you are using a tool like VisualBasic to write your application, you end up with something that may not be suitable for commercial use. How many million selling applications out there were written in VisualBasic? Not one that I'm aware of. -- CityDesk http://www.fogcreek.com (DmitryChestnykh?)
VisualBasic is geared towards custom in-house apps, not shrink-wrapped apps. See WhatsBeenDoneInVbClassic.

What can be said on each side with regard to learning to use one of these tools?

Compare the Employment figures of programmers using languages and you will see that many companies who employ programmers employ them for developing software.
- "Computer programmers held about 499,000 jobs in 2002. Programmers are employed in almost every industry, but the largest concentrations are in computer systems design and related services and in software publishers, which includes firms that write and sell software. Large numbers of programmers also can be found in management of companies and enterprises, telecommunications companies, manufacturers of computer and electronic equipment, financial institutions, insurance carriers, educational institutions, and government agencies."

This isn't the definition of RAD I'm familiar with. It's nothing to do with tools, it's an approach to development. ExtremeProgramming is a form of RAD to me (and so is DSDM). For me it's the quick delivery of something then successive iterations adding functionality. I would normally expect this to be for custom software development rather than (shrink-wrapped) product development.

I think that most RAD tools are pretty suitable to use a GlueLanguages, but I don't care for the RAD concept that much, maybe.

I am fascinated with the concept of using DataDictionary and/or EntityRelationshipDiagram-like tools to generate the vast majority of CrudScreens and related behavior for business applications. The patterns and behaviors are, or can be, pretty consistent in CrudScreen applications. The trick is making a way to integrate custom stuff into it when the default behavior is not sufficient. I would have to study more exceptions to see when and why such exceptions are made. I suspect that they are usually the capricious whim of somebody rather than a rational requirement. It gets into the highly philosophical area of whether or not TheCustomerIsAlwaysRight?. But, as it stands I believe I could create such a system that can crank out fairly complex applications just by filling in DataDictionarys and maybe adding a few event handlers here and there. It would include fairly sophisticated QueryByExample screens also. It would use a kind of "stack" behavior of unfinished screens so that the user could go and look stuff up without being forced to finish or cancel the current screen. A list of pending screens would be always displayed. It is my attempt to compress the common behaviors and needs of business applications into a fill-in-the-blanks setup. I don't think such a system would be easy for most developers to learn, giving its declarative nature, but once they do learn it they could build many applications rather quickly, I believe. -- top

Link - Emacs + SQLite as RAD platform http://mysite.verizon.net/mbcladwell/sqlite.html

Popular RAD Tool List:

BorlandDelphi
VisualBasic
DotNet
DolphinSmalltalk
SqueakSmalltalk
BoaConstructor (RAD IDE for Python, WxWidgets)
FoxPro