Differences between version 3 and predecessor to the previous major change of RAD.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 3 | Last edited on Friday, September 26, 2003 10:13:26 pm | by AristotlePagaltzis | Revert |
| Older page: | version 1 | Last edited on Wednesday, February 26, 2003 10:06:19 pm | by GlynWebster | Revert |
@@ -1 +1,10 @@
-[Acronym] for __R__apid __A__pplication __D__evelopment. Usually
means an [IDE] with a point-and-click tool for building graphical user interfaces.
+An
[Acronym] for __R__apid __A__pplication __D__evelopment. It usually
means an [IDE] with a point-and-click tool for building graphical user interfaces.
+
+There are at least two schools of thought regarding their use. Depending on which school you follow, [RAD] tools are..
+
+# ... best used for rapid prototyping of an application, as they have high-quality form builders and allow fast development of complex interfaces. However, the code bloat that comes with the abstraction that [RAD] provides is detrimental to the performance, so they are unsuited for final products.
+# ... perfectly fine to use for all tasks.
+
+Regardless of your own opinion, be aware that abstractions cannot replace knowledge of how things work. Sure, you can design [SQL] queries visually, drop a DataBase component onto a form, and have it a grid of values populated automagically. But if you don't understand [SQL] or how DataBase connections are made, chances are you'll create inefficient and/or too inflexible code and run into problems sooner or later. There are probably heaps of better ways of performing a query that you didn't even know existed.
+
+And because the expressive capability of [GUI]s is inherently limited, you may often find yourself unable to create something that fits a complex spec exactly
.
