Many programming languages today have a format that is like <tree of files, each containing> <set of items, each containing> <list of expressions>. It would be nice if that <set of items> step was treated as an unordered set instead of an ordered one, with editors having a better understanding of how to bring up relevant elements of the set onto your screen at the same time. Split pane editors, "peeking" in editors at code definitions, etc. hint at how this should work, but I don't feel like they do it as well as possible.
Back in the day, in VisualWorks, with the RefactoringBrowser, you could bring up a browser for a search, say, everyone who implemented
methodNamedFoo:
Then you could rapidly narrow that down (effectively and-ing it) to those methods which also sent
thisOtherMethod:
These were lightning quick operations, just right-click and done! But what's more, you could even compose little queries (think like you would in a SQL query client, but using snippets of Smalltalk code) that would be applied to/and-ed with the contents of each browser window. Done right, this resulted in a few accurate, complete, and highly focused sets of code applied to the exact problem you were working on.
What's more, you could write scripts to pop up such query browsers automatically. They would also be saved in the "image" and just pop up to the same state when you restarted the environment. On top of that, you could write syntactically accurate code transformations against all of the above, even writing ad-hoc code against the meta level or even runtime state from the middle of a runtime debug session.
A small amount of "visual augmentation" might benefit most programming languages
Agreed. Where various visual programming have fallen down over the past 3 decades:
1) Scaling complexity -- If diagrams get too busy, and there's no good way of managing complexity. This especially applies to multiple programmers changing the same diagram.
2) Scaling size/optimization -- Many visual programming systems in past decades could bog down and become marginally responsive or unusual when managing large systems.
If you can handle those two, you will have a huge leg up towards a viable visual programming augmentation.
Back in the day, in VisualWorks, with the RefactoringBrowser, you could bring up a browser for a search, say, everyone who implemented
Then you could rapidly narrow that down (effectively and-ing it) to those methods which also sent These were lightning quick operations, just right-click and done! But what's more, you could even compose little queries (think like you would in a SQL query client, but using snippets of Smalltalk code) that would be applied to/and-ed with the contents of each browser window. Done right, this resulted in a few accurate, complete, and highly focused sets of code applied to the exact problem you were working on.What's more, you could write scripts to pop up such query browsers automatically. They would also be saved in the "image" and just pop up to the same state when you restarted the environment. On top of that, you could write syntactically accurate code transformations against all of the above, even writing ad-hoc code against the meta level or even runtime state from the middle of a runtime debug session.
A small amount of "visual augmentation" might benefit most programming languages
Agreed. Where various visual programming have fallen down over the past 3 decades:
1) Scaling complexity -- If diagrams get too busy, and there's no good way of managing complexity. This especially applies to multiple programmers changing the same diagram.
2) Scaling size/optimization -- Many visual programming systems in past decades could bog down and become marginally responsive or unusual when managing large systems.
If you can handle those two, you will have a huge leg up towards a viable visual programming augmentation.