4 ms·
The benefit is minimal, the task is hard, there's decades worth of tools that won't work, and it's easy to mess up introducing "impossible bugs" with behind-the
by ajuc 5y ago
The benefit is minimal, the task is hard, there's decades worth of tools that won't work, and it's easy to mess up introducing "impossible bugs" with behind-the-scenes transformations.
Also - AST isn't THAT important when reading the code. Let's say I give you this:
X (X X X X; X X X; X X) {
X (X X X) {
X(X X X X X)
}
}
Do you know what this code does? How about this:
for int i = 0 i < 10 i ++ if i % 2 printf " %d " , i
I've used several graphical languages professionally (not AST-based, graph-based, but the problem remains) and the main problem was - structure wasn't fully describing what happens - the "meat" of the behaviour was still in text form and was hidden behind the pretty graphic form - in case of both of these languages the meat was in the names of the subprocesses called and in the mapping of process variables <-> subprocess parameters.
And there were A LOT of these, so you couldn't show them at once on the same screen as the graphical view of the process. So programming with both of these languages was very frustrating - you had to click on each node and look through long lists of x:y substitutions to track how parameters flow through the system.