When reading source code the developer has to make a mental picture of the concepts. Likewise, when writing source code the developer has to translate her mental picture into text. What if we simplified and enhanced this process by making source code more visual (pictorial)?
There are a number of concepts in modern programming languages that have been shoe-horned into text which may be better portrayed using a pictorial representation. Two such concepts are the ternary operator and block delineators.
Imagine all of the developer time that would be made available if there was no more bickering about brace placement! (Wesner Moise has an entry about graphical source code editors and code blocks.)
It is possible to decorate existing textual components to help emphasize their purpose and scope. The following image combines a number of features: comments, ternary operator and
Graphical Comments, Ternary Operator and
if with Icon
This decoration can be carried another step. In the previous image, the
if keyword and icon appear together. If icons are used to replace keywords,
if can be removed entirely. In a similar fashion, the
final keyword can be replaced with a decoration on each variable reference.
final case demonstrates that the decoration provides benefit over the keyword. When the keyword is used, there is no way to know which variables are final without looking at their declarations. With a decorated variable, each time that the variable is entered into the editor the decoration will appear indicating the constraints on it. One can imagine this decoration idea extended even further by indicating type, scope (local versus class) and access modifiers. If the decorations become too cluttered then the editor can allow decorations to be disabled as needed.
Rather than providing insight some might believe that replacing the
if with an icon obfuscates the code. There are going to be a number of attempts that are made in the upcoming years that seem to bring us backwards rather than forward. We must walk before we run and we are certain to get a few scraped knees along the way.
Daniel O’Connell brings up an interesting situation in this post’s comment: instead of language lock in, you could easily end up with IDE lock in. It is certainly possible that we would end up with IDE lock-in but recent history has shown us that the various IDE’s feed off of one another to create relatively similar products. If Eclipse has a useful feature that IntelliJ does not have then the next version of IntelliJ will likely have it. If on the other hand, Eclipse has a feature that is not useful then it will likely receive less attention and be pulled from the product. In this time of great innovation as long as we steer well clear of “protecting” concepts by legal means (i.e. patents) then the theory of natural selection will cause a relatively level playing field and will eliminate the possibility of lock-in.
I welcome new ideas regardless of their ability to demonstrate immediately clear and attainable results. There are times when it takes two blind steps forward before we can reach our destination. And there are times when we must travel part way down a path before we determine that it is not the correct one.
The ideas that I am proposing are by no means new. (I was surprised to find that Roedy Green has written an extensive list of features that is a superset of mine.) Finding the ideal balance between textual and graphical representations will allow these ideas to flourish where they have withered before.
This entry is continuing the thread on separating the presentation (view) of a programming language from its storage format (model). There are also entries on annotating, internationalizing and adding images to source code as well as simplifying the understanding of code structure.