We go the other way
A lot of interactive application development today starts from the assumption that developers want to use an high-level, object-oriented platform like Java or .NET to program interactive systems. Interaction programming is dominated by the Model-View-Controller paradigm, enforcing a strong separation between how data is described and how it is viewed and changed.
With Makumba we acknowledge that many interactive applications are used most of the time to simply browse and update data from a database, and access to data is governed by rules that are also modeled in the database. While more advanced features exist, which merit the power of advanced object-oriented languages, the bulk of interactive application features -- access-controlled data browsing and updating -- can be easily implemented with database queries which provide data to rendering technologies. Therefore we center our interaction programming technology around database queries described in simple and small query languages (HQL, JPQL), much less complex than the programming languages in fashion today. We also let application developers work with queries from within the view modules of applications (JSP pages, JSF views) and thus access the data model in the view modules.
In fact, Makumba applications mostly consist of view modules. The amount of code needed to describe data and its business rules is very small compared to the code needed for data browsing and updating. Therefore we regard Makumba applications as a case of user-interaction-driven software development. Our flagship application, a large intranet developed since 2002, has shown that it is possible to develop and grow applications in a query-centric interaction-driven manner, in a sustainable way.
We also recognize that the way data is viewed is often very similar with the way data is described in the data model. By allowing for queries in views, and by avoiding the repeating of the data description we advocate a smaller separation between data description and its user interface view, therefore weakening the model-view separation. While we do respect the MVC in general, we believe that it the strong separations it enforces are often not needed in applications dominated by browsing and updating, and we argue for the use of strong separation only when the situation demands it.