> requires the user actually to design in terms of nested components rather than in a single flat diagram space The way I picture it, the user would almost be

> requires the user actually to design in terms of nested components rather than in a single flat diagram space The way I picture it, the user would almost be forced to nest components. The flat diagram space would become unmanageable (a very common problem I see in various visual programming systems), and nesting would be extremely simple. If you want to turn something into a component, just draw a box around the various pieces and hit a single button. Boom, it automatically disappears all of the pieces into a single component with the input and output pins aggregated. Given that we've got nice big screens now, I would experiment with not even making the workspace scrollable. The ideal systems would have all 'chunks' (conceptually speaking) visible as single-screen pieces. In my really crazy fantasies, such a system would allow you to 'zoom in' right down to assembly output. I've also been doing a lot of thinking about provably correct programs. People talk a lot about it especially in FP circles, but proving programs correct is very rarely actually done. Integrating a lot of design-by-contract elements would be almost necessary, and that doesn't work terribly well in most languages. You end up with enormous amounts of code checking and asserting everything and even if you omit that stuff from release builds, it seriously detracts from readability. I've considered the idea of coding in "layers" which makes it easy to hide/show different 'layers' where the layers would be things like 'contract code' or 'error handling' and the like, so you could leave your 'primary' view of the code strictly code that actually gets stuff done... but I don't have the UI design chops to do something like that without introducing as many problems as it solves, I don't think. With a visual programming system, however, the contracts could be simply a little 'bubble' over the in/out pins. If you want to investigate the constraints on an input variable, you'd just zoom in on the bubble. With enough constraints, automated reasoning could help prevent you from writing bad code to begin with, along with proving invariants about the code to indicate correctness.