Re: Arguably the most successful declarative programming tool is the relational database (RDB). I used to use database systems that were mostly imperative. Whi

Re: Arguably the most successful declarative programming tool is the relational database (RDB). I used to use database systems that were mostly imperative. While they do put more onus on the app developer to manage "machine efficiency", such queries were easier to build and study (debug) incrementally, including the machine run-time profile. Imperative gives you a better chance at fractal divide-and-conquer of tasks and sub-tasks that can be tested and analyzed as independent units. SQL has made that relatively difficult. Views and the newer WITH clause help, but they are still not fractally dissectable within themselves. There are pro's and con's to each, but I'd like to see the world forked around 1982 into SQL-World and Imperative-DB-World and see which actually does better. The theoretical benefits of declarative queries being more machine optimize-able is exaggerated when put to practice. If it were true, we wouldn't need DBA's to rewrite slow SQL. Imperative can also be machine optimized. Declarative can be quite useful for GUI's but only if "events" or equivalent can imperatively tweak the results along the way "between" steps. Declarative may do 80% of the work, but certain operations will need custom tweaking, usually with imperative code. Optional events added to declarative systems to adjust stuff along the way is a good mix of imperative and declarative: yin and yang: declarative for the common "grunt work" patterns and attribute management, and imperative for custom adjustments. (If the system is designed to integrate them well.)