Because of the incremental and the uncompromising point-and-click style of Lava programming and because of the ease of renaming and rearrangement operations we believe that Lava may also be used already in the early (analysis and design) stages of application development, which seem to be dominated by UML tools presently.
E.g., the typical UML use case "customer opens new bank account" could also be described by three Lava classes Bank, Customer, Account, and a method openAccount of Bank, whose declarations could be established in the twinkling of an eye by just a few point-and-click operations. In this stage, the classes would not yet have any attributes or methods, except for Bank, which would have a method openAccount, but the latter would not yet have any formal parameters.
The main advantage of using Lava from the beginning is that you can fill in ever more details in a quite incremental way just as they come into your mind. For instance, if you recognize that openAccount should have an input parameter of type Customer and an output parameter of type Account then you can add these details easily and immediately in Lava, while in UML you would be forced to first translate your use cases into a class diagram before you can specify method parameters.
Another recognition is that graphical representations would tend to grow very soon beyond the margins of a sheet of paper or a screen, thus compromising ease of understanding and editing.
So our conclusion and our present working hypothesis is that you should have a single, compact, primary language like Lava that supports seamless, consistent, incremental development from analysis over design up to implementation.
Without any doubt, you would like to produce additional graphic representations of selected, particular aspects of your system or application in various ways.
The second part of our working hypothesis now is that these additional graphical (or other) representations should be produced in an automatic or semi-automatic way from the complete and more compact primary representation as a Lava program, just like many existing programming environments are already able to produce class diagrams or call graphs from source code. As a by-product, this would also make it easy to keep these derived secondary, for instance graphic, representations consistent with your primary code at all times.
The AST-nature of the internal representation of Lava programs should greatly facilitate the generation of such derived, secondary representations of Lava programs, and these would be very welcome supplements to the existing Lava programming environment.