Differences between current version and predecessor to the previous major change of RAD.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 5 | Last edited on Sunday, January 2, 2005 10:58:03 am | by AristotlePagaltzis | |
| Older page: | version 3 | Last edited on Friday, September 26, 2003 10:13:26 pm | by AristotlePagaltzis | Revert |
@@ -1,10 +1,10 @@
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..
+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.
+* …
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
.
+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. You might be missing
heaps of ways to perform
a query, some of which might be better than what you picked, simply because your [RAD] tool limits your world view and keeps
you from educating yourself
.
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.
