Some thoughts I've had on "graphical based programming" (if UML can be deemed as such): - Don't draw the product. Draw the organization that produces it. As pe

Some thoughts I've had on "graphical based programming" (if UML can be deemed as such): - Don't draw the product. Draw the organization that produces it. As per Conway's law, you'll be drawing the same thing in the end, but contrary to UML you won't face the problem of the representation of the product evolving faster than the ability of the organization to update it. The representation (the diagram) will just evolve as fast as the organization can represent itself. This require that: - The diagram is the organization and the fundamental aspect of code is UI. There is no distinction between the primitives of the UI/UX system (clicking on that, moving this item from here to there, etc ...) and its computational primitives. This is the tipping-point that: - a) makes this system homoiconic - b) makes this system homoschematic. Homoschematicity (same-representation/same-gesture in ancient Greek) is reached when the datastructure that is set in immediate relation to itself (typically lists in Lisp) is also what is directly presented to the end user and can be displayed as such, ie. immediately (lisp code is too ugly and limited for that).