3 ms·

The core thesis of this work is "that text is an inappropriate way to model structured program code". I think that is wrong, text is a great way to model struct

The core thesis of this work is "that text is an inappropriate way to model structured program code". I think that is wrong, text is a great way to model structured program code. That doesn't mean that the ways we use text these days for programming couldn't be improved and augmented. For example, the example in Figure 3 is very pretty and readable. But there is no reason why this couldn't be what you see when still editing everything as text. Basically, it could be a more advanced form of syntax highlighting. The reason why this is difficult/impossible to achieve with Java is because of Java's syntax. Therefore I think when approaching programming from a user interface point of view, it is crucial to also work on a better syntax for the programming language itself. Ideally, work like described in this paper should go hand in hand with work to develop better syntaxes.

falcolas 9y ago
IMO, the big problem with text as a representation of (imperative) code is that it only represents the program's execution flow; the visualization of the flow of data must be done in a person's mental model. The side effect of this is that a programmer must build the proper mental model anytime they want to make a change, or they risk mucking up the data. Object orientated programming was an attempt at localizing data changes, at the cost of complicating the overall flow of the program's execution. Representing the flow of data and not the program is one advantage that many functional languages have, at the cost of removing the visualization of the program's flow. Often this doesn't matter, but sometimes it does. When it does matter, you're faced with the same challenge for the programmer. So ultimately, even the best syntax can only help you model one thing - either the flow of the data or the flow of the program - and the other flow must be modeled internally. It would be cool if both could be visualized by our tooling simultaneously.

falcolas 9y ago

IMO, the big problem with text as a representation of (imperative) code is that it only represents the program's execution flow; the visualization of the flow of data must be done in a person's mental model. The side effect of this is that a programmer must build the proper mental model anytime they want to make a change, or they risk mucking up the data. Object orientated programming was an attempt at localizing data changes, at the cost of complicating the overall flow of the program's execution. Representing the flow of data and not the program is one advantage that many functional languages have, at the cost of removing the visualization of the program's flow. Often this doesn't matter, but sometimes it does. When it does matter, you're faced with the same challenge for the programmer. So ultimately, even the best syntax can only help you model one thing - either the flow of the data or the flow of the program - and the other flow must be modeled internally. It would be cool if both could be visualized by our tooling simultaneously.